RFC 9252, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", July 2022

Errata ID: 7357
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaliraj Vairavakkalai
Date Reported: 2023-02-16
Rejected by: James N Guichard
Date Rejected: 2023-05-31

Section 4 says:

   To achieve efficient packing, this document allows either 1) the
   encoding of the SRv6 Service SID as a whole in the SRv6 Services TLVs
   or 2) the encoding of only the common part of the SRv6 SID (e.g.,
   Locator) in the SRv6 Services TLVs and the encoding of the variable
   (e.g., Function or Argument parts) in the existing label fields
   specific to that service encoding.  This later form of encoding is
   referred to as the Transposition Scheme, where the SRv6 SID Structure
   Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID and also
   indicates the offset of the variable part along with its length in
   the SRv6 SID value.  The use of the Transposition Scheme is
   RECOMMENDED for the specific service encodings that allow it, as
   described further in Sections 5 and 6.

It should say:

   To achieve efficient packing, this document allows either 1) the
   encoding of the SRv6 Service SID as a whole in the SRv6 Services TLVs
   or 2) the encoding of only the common part of the SRv6 SID (e.g.,
   Locator) in the SRv6 Services TLVs and the encoding of the variable
   (e.g., Function or Argument parts) in the existing label fields
   specific to that service encoding.  This later form of encoding is
   referred to as the Transposition Scheme, where the SRv6 SID Structure
   Sub-Sub-TLV describes the sizes of the parts of the SRv6 SID and also
   indicates the offset of the variable part along with its length in
   the SRv6 SID value.  The use of the Transposition Scheme is
   NOT RECOMMENDED in brownfield deployments where all participating BGP
   speakers may not support SRv6 forwarding, see Appendix X. 
   Transposition Scheme MAY be used if all speakers support procedures
   described in this document, for the specific service encodings that 
   allow it, and is encoded as described further in Sections 5 and 6.

Appendix X:

   Use of Transposition Scheme procedures may cause incorrect routing 
   in the following scenario:


                         RR1--+
                                \  +-------R2  [MPLS + SRv6]
                                 \ |
                         R1--------P-------R3  [MPLS only]
                   [MPLS + SRv6]   |
                                   +-------R4  [SRv6 only]

                     <---- Bidirectional Traffic ---->

            Figure: BGP L3VPN Interop between MPLS and SRv6 nodes

     This example shows a provider network with a mix of devices with
     different forwarding capabilities.  R1 and R2 support forwarding 
     both MPLS and SRv6 packets. R3 supports forwarding MPLS packets 
     only. R4 supports forwarding SRv6 packets only. All these nodes 
     have BGP session with Route Reflector RR1 which reflects routes 
     between these nodes with nexthop unchanged. BGP L3VPN (SAFI 128) 
     family is negotiated on these sessions.
            
     If SRv6 nodes R2, R1, R4 use Transposition Scheme described in 
     Section 4, it will cause misrouting at R3 because of 
     misinterpretation of the MPLS label field. Because of Transposition
     scheme, RFC 8277 encoded MPLS label field is not containing a valid
     MPLS label.

Notes:

Ref: https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/5
--VERIFIER NOTES--
The errata is a substantive change with new normative language. I am rejecting this errata on the basis that a discussion within the WG on these changes seems appropriate and if necessary an updated RFC is the correct vehicle rather than errata (Please see https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ for guidance on the errata process).

Report New Errata