RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (3)

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

Source of RFC: bess (rtg)

Errata ID: 7134
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Ketan Talaulikar
Date Reported: 2022-09-15
Verifier Name: James N Guichard
Date Verified: 2023-05-31

Section 6.4 says:

                  +---------------------------------------+
                  |  RD (8 octets)                        |
                  +---------------------------------------+
                  |  Ethernet Tag ID (4 octets)           |
                  +---------------------------------------+
                  |  IP Address Length (1 octet)          |
                  +---------------------------------------+
                  |  Originating Router's IP Address      |
                  |          (4 or 16 octets)             |
                  +---------------------------------------+

                        Figure 10: EVPN Route Type 4

It should say:

                  +---------------------------------------+
                  |  RD (8 octets)                        |
                  +---------------------------------------+
                  |Ethernet Segment Identifier (10 octets)|
                  +---------------------------------------+
                  |  IP Address Length (1 octet)          |
                  +---------------------------------------+
                  |  Originating Router's IP Address      |
                  |          (4 or 16 octets)             |
                  +---------------------------------------+

                        Figure 10: EVPN Route Type 4

Notes:

The 2nd field in the figure should be "Ethernet Segment Identifier" of size 10 octets instead of the "Ethernet Tag ID" of size 4 octets.

RFC7432 is the EVPN specification for Ethernet Segment Route (Type 4) and hence the format in section 7.4 of RFC7432 is the correct one.
RFC9252 has an error when showing the encoding format of this EVPN Route Type 4 as a reminder in Figure 10 in section 6.4.

This is an editorial error.

Errata ID: 7652
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Ketan Talaulikar
Date Reported: 2023-09-22
Verifier Name: Gunter Van de Velde
Date Verified: 2024-05-22

Section 3.2.1 says:

   Transposition Offset indicates the bit position, and Transposition
   Length indicates the number of bits that are being taken out of the
   SRv6 SID value and encoded in the MPLS Label field.  The bits that
   have been shifted out MUST be set to 0 in the SID value.

It should say:

   Transposition Offset indicates the bit position and Transposition
   Length indicates the number of bits that are being taken out of the
   SRv6 SID value and put into high order bits of MPLS label field. The
   bits that have been shifted out MUST be set to 0 in the SID value.

Notes:

This errata reverses an editorial change that was made during the AUTH48 phase and restores the text that came from the WG and IESG review. Refer https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-15#page-10

This change was made during the AUTH48 since the "high order bits" was already covered under various subsections of Sec 6. However, readers have reported that there are other places in Sec 6 and Sec 5 where transposition also occurs and that the original text was still required.

Errata ID: 7817
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Ketan Talaulikar
Date Reported: 2024-02-20
Verifier Name: Gunter Van de Velde
Date Verified: 2024-05-22

Section 3.2.1 says:

   As defined in [RFC8986], the sum of the Locator Block Length (LBL),
   Locator Node Length (LNL), Function Length (FL), and Argument Length
   (AL) fields MUST be less than or equal to 128 and greater than the
   sum of Transposition Offset and Transposition Length.

It should say:

   As defined in [RFC8986], the sum of the Locator Block Length (LBL),
   Locator Node Length (LNL), Function Length (FL), and Argument Length
   (AL) fields MUST be less than or equal to 128 and greater than or
   equal to the sum of Transposition Offset and Transposition Length.

Notes:

The sum of Trans Off and Trans Length can be equal to the LBL+LNL+FL+AL when the last part of the SID (function or argument) is getting transposed.

This is clear also from the example below in the next paragraph of the same section:

As an example, consider that the sum of the Locator Block and the
Locator Node parts is 64. For an SRv6 SID where the entire Function
part of size 16 bits is transposed, the transposition offset is set
to 64 and the transposition length is set to 16. While for an SRv6
SID for which the FL is 24 bits and only the lower order 20 bits are
transposed (e.g., due to the limit of the MPLS Label field size), the
transposition offset is set to 68 and the transposition length is set
to 20.

Status: Rejected (1)

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

Source of RFC: bess (rtg)

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



Advanced Search