Search RFCs

RFC Editor

Found 3 records.

Status:Verified (1)

RFC 8287, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", December 2017

Note: This RFC has been updated byRFC 8690, RFC 9214

Errata ID:6389
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Bensley
Date Reported: 2021-01-19
Verifier Name: Deborah Brungard
Date Verified: 2021-02-26

Section 5.2 says:

5.2.  IPv6 IGP-Prefix Segment ID   The IPv6 IGP-Prefix Segment ID is defined in [SR].  The format is as   specified below:      0                   1                   2                   3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                                                               |     |                         IPv6 Prefix                           |     |                                                               |     |                                                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |Prefix Length  |    Protocol   |              Reserved         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   IPv6 Prefix      This field carries the IPv6 prefix to which the Segment ID is      assigned.  In case of an Anycast Segment ID, this field will carry      the IPv4 Anycast address.

It should say:

5.2.  IPv6 IGP-Prefix Segment ID   The IPv6 IGP-Prefix Segment ID is defined in [SR].  The format is as   specified below:      0                   1                   2                   3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                                                               |     |                         IPv6 Prefix                           |     |                                                               |     |                                                               |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |Prefix Length  |    Protocol   |              Reserved         |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   IPv6 Prefix      This field carries the IPv6 prefix to which the Segment ID is      assigned.  In case of an Anycast Segment ID, this field will carry      the IPv6 Anycast address.

Notes:

Copy-pasta reusing the IPv4 IGP-Prefix Segment ID description for the IPv6 IGP-Prefix Segment ID description, and in the case of an IPv6 Anycast Segment ID it states that an IPv4 prefix should be entered into the IPv6 Prefix field.

Status:Held for Document Update (1)

RFC 8287, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", December 2017

Note: This RFC has been updated byRFC 8690, RFC 9214

Errata ID:6101
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2020-04-13
Held for Document Update by: Deborah Brungard
Date Held: 2020-04-30

Section 7.2 says:

   The network node that advertised the Node Segment ID is responsible   for generating a FEC Stack Change sub-TLV with the Post Office   Protocol (POP) operation type for the Node Segment ID, regardless of   whether or not Penultimate Hop Popping (PHP) is enabled.   The network node that is immediately downstream of the node that   advertised the Adjacency Segment ID is responsible for generating the   FEC Stack Change sub-TLV for POP operation for the Adjacency Segment   ID.

It should say:

   The network node that advertised the Node Segment ID is responsible   for generating a FEC Stack Change sub-TLV with the pop operation type for    the Node Segment ID, regardless of whether or not penultimate hop popping    (PHP) is enabled.   The network node that is immediately downstream of the node that   advertised the Adjacency Segment ID is responsible for generating the   FEC Stack Change sub-TLV for pop operation for the Adjacency Segment   ID.

Notes:

Expansion of POP to "Post Office Protocol" in the context of this document is wrong. It should not be capitalized, it is not an abbreviation, simply the verb, pop. In addition, expansion for PHP should not be with caps.

Status:Rejected (1)

RFC 8287, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", December 2017

Note: This RFC has been updated byRFC 8690, RFC 9214

Errata ID:5290
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2018-03-20
Rejected by: Deborah Brungard
Date Rejected: 2018-06-29

Section 5.1 says:

   The IPv4 IGP-Prefix Segment ID is defined in [SR].  The format is as   specified below:      0                   1                   2                   3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                         IPv4 Prefix                           |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |Prefix Length  |    Protocol   |         Reserved              |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   IPv4 Prefix      This field carries the IPv4 Prefix to which the Segment ID is      assigned.  In case of an Anycast Segment ID, this field will carry      the IPv4 Anycast address.  If the prefix is shorter than 32 bits,      trailing bits SHOULD be set to zero.   Prefix Length      The Prefix Length field is one octet.  It gives the length of the      prefix in bits (values can be 1-32).

It should say:

   The IPv4 IGP-Prefix Segment ID is defined in [SR].    The sub-TLV length MUST be set to 8, and its format is    as specified below:      0                   1                   2                   3      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |                         IPv4 Prefix                           |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |Prefix Length  |    Protocol   |         Reserved              |     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   IPv4 Prefix      This field carries the IPv4 Prefix to which the Segment ID is      assigned.  In case of an Anycast Segment ID, this field will carry      the IPv4 Anycast address.  If the prefix is shorter than 32 bits,      trailing bits SHOULD be set to zero.   Prefix Length      The Prefix Length field is one octet.        It gives the length of the      prefix in bits (values can be 1-32).

Notes:

The RFC in its current form does not explicitly specify the length of the sub-TLV for the IPv4 IGP-Prefix Segment ID, while the format includes a reserved (MBZ) field at the end.
the implementers therefore must guess whether the reserved bits are or are not included in the sub-TLV guess. Such guesses have already caused interoperabilty issues with some implementations including these bits and some not including them.

For comparison, RFC 8029 explicitly specifies length of every sub-TLV it defines. It also never includes MBZ fields at the end of sub-TLVs in the sub-TLV length.

The proposed text is aligned with majority of implementations known to me.

Note also that sub-TLV length is also omitted in section 6.1. However, I am not aware of any actual interoperability issues with this sub-TLV.
--VERIFIER NOTES--
This change requires an update to the RFC, requires consensus.

Report New Errata