RFC Errata
Found 4 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 (2)
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.
Errata ID: 7817
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ketan Talaulikar
Date Reported: 2024-02-20
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).