Requested revision
| Standard: | 802.1AX-2020 | Clause: | 6.6.3.1 |
| Clause title: | Per-Aggregator variables [for Conversation-sensitive LACP] | ||
Rationale for revision
The specific descriptions of how to calculate the MD5 digest for the
Admin_Conv_Service_Map and Admin_Conv_Link_Map that 16 bit and 32-bit
binary numbers have the most significant byte first. Although this
might be obvious since all 802.1 standards present the
most-significant byte first when representing multiple byte values
(e.g. MAC Addresses, OUIs, etc.) and when putting such values into a
PDU, it should be made explicit in the calculation of a MD5 digest.
An example MD5 calculation can be found in 802.1Q: "To calculate the
digest, the table is considered to contain 4096 consecutive two octet
elements, where each element of the table (with the exception of the
first and last) contains an MSTID value encoded as a binary number,
with the first octet being most significant." (802.1Q-2022 page 516).
Proposed text
In the description of the Actor_Conv_Service_DIgest replace:
"To calculate the digest, Admin_Conv_Service_Map is considered to
contain 4096 consecutive elements, where each element contains a list
of zero or more Service IDs (8.2), encoded as binary numbers in
increasing order, followed by the Port Conversation ID to which they
are mapped."
with:
"To calculate the digest, Admin_Conv_Service_Map is considered to
contain 4096 consecutive elements, where each element contains a list
of zero or more 4-octet Service IDs (8.2), followed by the 2-octet
Port Conversation ID to which they are mapped. Binary numbers with
multiple octets are encoded with the most significant octet first."
And in the description of the Actor_Conv_Link_Digest replace:
"To calculate the digest, Admin_Conv_Link_Map is considered to contain
4096 consecutive elements, where each element contains a list of
Link_Numbers, encoded as binary numbers in the order of preference,
highest to lowest, followed by the Port Conversation ID."
with:
"To calculate the digest, Admin_Conv_Link_Map is considered to contain
4096 consecutive elements, where each element contains a list of
2-octet Link_Numbers, highest to lowest, followed by the 2 octet Port
Conversation ID. Binary numbers with multiple octets are encoded with
the most significant octet first."
Impact on existing networks
implementations that calulate the digest(s) with the least significant byte
first, and others that calculate the digest(s) with the most significant
byte first. If two differing implementations were connected via a LAG
supporting CSCD, the digests would not match even if both implementations
had identical configurations of the respective map(s). In this case the
protocol would revert to the behavior where each actor does not know what
distribution algorithm the partner is using, just as in Link Aggregation
without CSCD.
Originator
| Name: | Stephen Haddock | Email: | shaddock@stanfordsalumni.org |
| Affiliation: | Stephen Haddock Consulting LLC | ||
| Submitted: | 2025-05-25 | ||