RFC Errata
Found 3 records.
Status: Verified (1)
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.
Status: Reported (1)
RFC 9252, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", July 2022
Source of RFC: bess (rtg)
Errata ID: 7652
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ketan Talaulikar
Date Reported: 2023-09-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.
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).