Subject: [mpls] A question regarding RFC 8287

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Mar 2018 09:36:53 +0000

Nagendra and Carlos hi,
My colleagues and I would like to clarify an interoperability issue with RFC 8287.

In Section 5 this RFC defines three sub-TLVs dealing with Segment IDs:

*         IPv4 IGP-Prefix Segment ID

*         IPv6 IGP-Prefix Segment ID

*         IGP-Adjacency Segment ID

The formats of these sub-TLVs are defined in Section 5.1, 5.2 and 5.3 respectively, and, in the two first cases, these sub-TLVs include 16 reserved bits at the end of sub-TLV value.

These reserved bits MUST be set to 0 on send and MUST be ignored on receipt, i.e., are exact equivalents of MBZ field sin RFC 8029.

However, RFC does not define whether the Length of these sub-TLVs includes the reserved bits or not, leaving place for misinterpretations.

For comparison, RFC 8029 in Section 3.2 explicitly defines the length of each and very sub-TLV for which it is fixed. What's more, in the cases (e.g., for LDP IPv4 Prefix FEC) when these sub-TLVs include MBZ fields, the sub-TLV field does not include these fields.

The misinterpretation mentioned above is not theoretical: we are aware of two groups of implementations of RFC 8287 that use different sub-LV length in IPv4 IGP-Prefix SID  sub-TLV:

*         3 implementations in the first group set length to 8 (i.e., include reserved bits)

*         2 implementations in the second group set length to 6 (i.e., do not include reserved bits)

*         Implementations belonging to different groups have been found non-interoperable due to the difference in the IPv4 IGP-Prefix SID sub-TLV length.

We intend to submit a Technical erratum on this issue, but would like to clarify the intention of the authors (and the WG) first.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________