Requested revision
Standard: | IEEE Std 802.1CS-2020 | Clause: | C2.2 |
Clause title: | LRP TCP Discovery TLV |
Rationale for revision
There is a problem with decoding the LRP TCP Discovery TLV exchanged via LLDP.
In C2.2 it is described that this TLV may contain one or multiple Application descriptors.
The structure of an Application descriptor is defined in C2.2.6.
The Application descriptor has a variable length but does not contain an explicit length field.
Table C-2 shows possible structures and lengths and defines the "Address info 2"-field to be optional (not present).
With that it is impossible to tell if a byte following the first address is to be interpreted as "Address Info 2" or as first byte of the "OUI/CID" of the following Application descriptor.
Additionally C.2.2.5 explicitly states that a tlv may contain extra bytes which are supposed to be ignored.
So even if there is only a single Application descriptor in a tlv it is not known if a byte following the first address contains "Address Info 2", it could also be extra information.
There is no problem if the sender encodes a 2nd address with IPv4, IPv6 or noAddress encoding.
But in Table C-2 of normative Annex C the combination of 1st address IPv4/IPv6 and 2nd address "not present" is explicitly allowed.
And these combinations cannot be decoded by the Reader.
Example: 2 Applications - 3 IPv4 addresses
OUI-1 | AppId 1 | TCPport 1 | AddrInfo | IPv4 Addr 1-1 | AddrInfo | IPv4 Addr 1-2 | OUI-2 | AppId 2 | TCPport 2 | AddrInfo | IPv4 Addr 2-1 |
OUI-1 | AppId 1 | TCPport 1 | AddrInfo | IPv4 Addr 1-1 | OUI-2 | AppId 2 | TCPport 2 | AddrInfo | IPv4 Addr 2-1 | AddrInfo | IPv4 Addr 2-2 |
The usage and description of "not present" address info in the LRP MIB is also confusing:
In the LRP-TC-MIB the LrpInetAddressInfo is defined.
It includes the value notPresent(256), as a kind of meta-value outside the value range in the TLV [0..255].
However, the referenced subclause in .1CS (REFERENCE "C.2.2.6.2") does not include or describe the value 256.
Furthermore for lldpV2LocLrpTcpAddressInfo1 it is stated: "... SHALL NOT contain the value, notPresent(256)."
But for lldpV2LocLrpTcpAddress1 it is stated: "If lldpV2LocLrpTcpAddressInfo1 has the value notPresent(256) or noAddress(0), lldpV2LocLrpTcpAddress1 SHALL contain a zero-length octet string."
Similar statements are given for the lldp remote info.
Proposed text
A possible solution to the problem would be to make the "Address Info 2" field mandatory,
and remove the option of "not present" in the standard and in the MIB.
Impact on existing networks
A compatibility issue could arise with implementations, which support only 1 application with 1 address info and without noAddress encoding and without extra bytes.
Originator
Name: | Josef Dorr | Email: | josef.dorr@siemens.com |
Affiliation: | Siemens | ||
Submitted: | 2023-01-10 |