RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (1)

RFC 7432, "BGP MPLS-Based Ethernet VPN", February 2015

Note: This RFC has been updated by RFC 8584, RFC 9161, RFC 9572, RFC 9573

Source of RFC: l2vpn (rtg)

Errata ID: 5554
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Ali Sajassi
Date Reported: 2018-11-16
Verifier Name: Martin Vigoureux
Date Verified: 2018-11-27

Section 7 says:

Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5

It should say:

Section 7.1:
Add below text to the section 7.1 regarding the encoding
of MPLS label field:

"The value of the 20-bit MPLS label is encoded in the high-order 
20 bits of the 3 octets MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding 
of both the MPLS label fields:

"The value of the 20-bit MPLS label is encoded in the high-order
20 bits of the 3 octets MPLS Label1 and MPLS Label2 fields."

Section 7.5:
Add below text to the section 7.5 regarding the encoding of 
ESI Label field:

"The value of the 20-bit MPLS label is encoded in the high-order
20 bits of the 3 octets ESI Label field."

Notes:

MPLS label is a 20-bit value and is stored in a 3 bytes field in a packet.
The 20-bit MPLS label value is generally stored in higher order 20 bits
of the 3 octet label field. The exact encoding to be followed for storing
MPLS label values are not explicitly mentioned in the RFC 7432 under
section 7.1, 7.2 and 7.5 for different types of EVPN routes. This lead to
ambiguity in different implementations. Hence a clarification is required.

Status: Held for Document Update (3)

RFC 7432, "BGP MPLS-Based Ethernet VPN", February 2015

Note: This RFC has been updated by RFC 8584, RFC 9161, RFC 9572, RFC 9573

Source of RFC: l2vpn (rtg)

Errata ID: 4428
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Wenhu Lu
Date Reported: 2015-07-27
Held for Document Update by: Alvaro Retana
Date Held: 2015-07-27

Section TOC says:

Route Distinguisher Assignment per EVI

It should say:

Route Distinguisher Assignment per MAC-VRF

Notes:

In the Table of Contents, the line for section 7.9. is incorrect and does not reflect the actual section title on page 18.

Errata ID: 5718
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Kazuhiko Mino
Date Reported: 2019-05-03
Held for Document Update by: Martin Vigoureux
Date Held: 2019-06-17

Section 5 says:

5.  Ethernet Segment
   - Type 4 (T=0x04)
     + Local Discriminator value (4 octets).  The Local Discriminator
       value MUST be encoded in the 4 octets next to the IP address.

It should say:

     + Local Discriminator value (4 octets).  The Local Discriminator
       value MUST be encoded in the 4 octets next to the Router ID.

Notes:

Since the field before that is defined as "Router ID", the notation of "IP address" is not correct.

Errata ID: 6286
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Luc Andre Burdet
Date Reported: 2020-09-11
Held for Document Update by: Alvaro Retana
Date Held: 2020-09-11

Section 8.3 says:

   route.  As described in Section 8.1.1, the route MUST carry an ESI
   Label extended community with a valid ESI label.  The disposition PE

It should say:

   route.  As described in Section 8.2.1, the route MUST carry an ESI
   Label extended community with a valid ESI label.  The disposition PE

Notes:

8.1.1 is ES route construction, 8.2.1 is the correct cross-ref for ES/EAD route construction.

Status: Rejected (2)

RFC 7432, "BGP MPLS-Based Ethernet VPN", February 2015

Note: This RFC has been updated by RFC 8584, RFC 9161, RFC 9572, RFC 9573

Source of RFC: l2vpn (rtg)

Errata ID: 5523
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Krishnamoorthy Arumugham
Date Reported: 2018-10-12
Rejected by: Deborah Brungard
Date Rejected: 2018-10-25

Section 7 says:

Clarifications to following sub-sections:
Section 7.1
Section 7.2
Section 7.5

It should say:

Section 7.1:
Add below text to the section 7.1 regarding the encoding 
of MPLS label:

"The value of the 20-bit MPLS label is encoded in the 
high-order 20 bits of the 3 bytes MPLS Label field."

Section 7.2:
Add below text to the section 7.2 regarding the encoding
of both the MPLS label fields:

"The value of the 20-bit MPLS label is encoded in the 
high-order 20 bits of the 3 bytes MPLS Label field for
both MPLS Label1 and MPLS Label2."

Section 7.5:
Add below text to the section 7.5 regarding the encoding
of ESI Label fields:

"The value of the 20-bit MPLS label is encoded in the 
high-order 20 bits of the ESI Label field."

Notes:

MPLS label is a 20-bit value and is stored in a 3 bytes field in a packet. The 20-bit MPLS label value is generally stored in higher order 20 bits of the 3 byte label field. The exact encoding to be followed for storing MPLS label values are not explicitly mentioned in the RFC 7432 under section 7.1, 7.2 and 7.5 for different types of EVPN routes. This lead to ambiguity in different implementations. Hence a clarification is required.
--VERIFIER NOTES--
The ESI label is required to be a "valid MPLS label value", there is no reason to interpret that it should be different from Label 1 and Label 2. There is nothing technically wrong with what is currently in the RFC.

Errata ID: 5746
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Yang Huang
Date Reported: 2019-06-05
Rejected by: Martin Vigoureux
Date Rejected: 2019-06-17

Section 11.2 says:

11.2.  P-Tunnel Identification
"...+ If the PE that originates the advertisement uses ingress 
replication for the P-tunnel for EVPN, the route MUST include the
PMSI Tunnel attribute with the Tunnel Type set to Ingress
Replication and the Tunnel Identifier set to a routable address of
the PE."


It should say:

a routable address of the PE is not so strict. And does this mean 
we use the Tunnel Identifier to construct P2P tunnel for ingress 
replication, or we use the Originating Router's IP Address in the 
IMET route key, or they are equivalent meaning?
This may cause interact problems when it implements differently. 
Could you clarify this? Thanks.

Notes:


--VERIFIER NOTES--
Errata is not the place to ask questions for clarifications

Report New Errata



Advanced Search