RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (1)

RFC 8214, "Virtual Private Wire Service Support in Ethernet VPN", August 2017

Source of RFC: bess (rtg)

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

Reported By: Adrian Farrel
Date Reported: 2021-11-19
Verifier Name: Andrew Alston
Date Verified: 2022-05-26

Section 4 says:

          Ethernet                                          Ethernet
          Native   |<--------- EVPN Instance ----------->|  Native
          Service  |                                     |  Service
          (AC)     |     |<-PSN1->|       |<-PSN2->|     |  (AC)
             |     V     V        V       V        V     V  |
             |     +-----+      +-----+  +-----+   +-----+  |
      +----+ |     | PE1 |======|ASBR1|==|ASBR2|===| PE3 |  |    +----+
      |    |-------+-----+      +-----+  +-----+   +-----+-------|    |
      | CE1| |                                              |    |CE2 |
      |    |-------+-----+      +-----+  +-----+   +-----+-------|    |
      +----+ |     | PE2 |======|ASBR3|==|ASBR4|===| PE4 |  |    +----+
           ^       +-----+      +-----+  +-----+   +-----+          ^
           |   Provider Edge 1        ^        Provider Edge 2      |
           |                          |                             |
           |                          |                             |
           |              EVPN Inter-provider point                 |
           |                                                        |
           |<---------------- Emulated Service -------------------->|

                   Figure 3: EVPN-VPWS Deployment Model

It should say:

          Ethernet                                          Ethernet
          Native   |<--------- EVPN Instance ----------->|  Native
          Service  |                                     |  Service
          (AC)     |     |<-PSN1->|       |<-PSN2->|     |  (AC)
             |     V     V        V       V        V     V  |
             |     +-----+      +-----+  +-----+   +-----+  |
      +----+ |     | PE1 |======|ASBR1|==|ASBR2|===| PE3 |  |    +----+
      |    |-------+-----+      +-----+  +-----+   +-----+-------|    |
      | CE1| |                                              |    |CE2 |
      |    |-------+-----+      +-----+  +-----+   +-----+-------|    |
      +----+ |     | PE2 |======|ASBR3|==|ASBR4|===| PE4 |  |    +----+
           ^       +-----+      +-----+  +-----+   +-----+       ^
           |   Provider Edge 1        ^        Provider Edge 2   |
           |                          |                          |
           |                          |                          |
           |              EVPN Inter-provider point              |
           |                                                     |
           |<---------------- Emulated Service ----------------->|

                   Figure 3: EVPN-VPWS Deployment Model

Notes:

The right-hand end of the Emulated Service should be aligned with the provider-facing AC port on CE2 and not placed in the middle of CE2.
Although this may appear to be a minor editorial issue, the technical consequences are significant.

Status: Reported (2)

RFC 8214, "Virtual Private Wire Service Support in Ethernet VPN", August 2017

Source of RFC: bess (rtg)

Errata ID: 6517
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2021-04-05

Section 5 says:

   Finally, EVPN may employ data-plane egress link protection mechanisms
   not available in VPWS.  This can be done by the primary PE (on local
   AC down) using the label advertised in the per-EVI Ethernet A-D route
   by the backup PE to encapsulate the traffic and direct it to the
   backup PE.

It should say:

   Finally, EVPN may employ data-plane egress link protection mechanisms.
   This can be done by the primary PE (on local AC down) using the label 
   advertised in the per-EVI Ethernet A-D route by the backup PE to
   encapsulate the traffic and direct it to the backup PE.  Similar behavior
   for LDP-signaled PWs can be achieved using LDP extensions defined in RFC 8104, 
   but the EVPN-based solution is simpler to implement (e.g., does not require 
   context-specific label spaces) and operate.




Notes:

RFC 8104 "Pseudowire (PW) Endpoint Fast Failure Protection" defines a solution for egress PW endpoint protection that provides fast local protection against failure of the primary egress PE and failure of the Attachment Circuit of this PE, so that the claim that the data-plane egress link protection mechanisms are not available for LDP-signaled PWs is factually inaccurate. However, the solution defined in RFC 8104is much more complicated both from the POV of implementation and from the operational POV, while the EVPN-based solution is quite straightforward.

Errata ID: 7562
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2023-07-13

Section 3.1 says:

In a multihoming All-Active scenario, there is no Designated Forwarder (DF) election, and all the PEs in the ES that are active and ready to forward traffic to/from the CE will set the P Flag.

It should say:

In a multihoming All-Active scenario, there is no Designated Forwarder (DF) election, and all the PEs in the ES that are active and ready to forward traffic to/from the CE SHOULD set the P Flag.

Notes:

The original text in the RFC does not express any requirement level ("will" is not a recognized IETF term for expressing requirement levels as defined in RFC 2119). The new test replaces "will" with "SHOULD".

SHOULD and not MUST is proposed to avoid potential issues with implementations that did not set P flag in the L2 Attributes Extended Community in All-Active multi-homing scenarios (since this was not required) and would suddenly become non-compliant if the text were changed to from "will" to MUST.

Status: Held for Document Update (1)

RFC 8214, "Virtual Private Wire Service Support in Ethernet VPN", August 2017

Source of RFC: bess (rtg)

Errata ID: 7837
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander ("Sasha") Vainshtein
Date Reported: 2024-03-05
Held for Document Update by: John Scudder
Date Held: 2024-03-07

Section 3.1 says:

This document defines a new extended community [RFC4360], to be included with per-EVI Ethernet A-D routes.  This attribute is mandatory if multihoming is enabled.

It should say:

This document defines a new extended community [RFC4360], to be included with per-EVI Ethernet A-D routes.  

If multihoming is enabled, this attribute is MANDATORY regardless of whether the per-EVI Ethernet A-D route is advertised by an EVPN-VPWS instance or by a "bridging" EVPN instance.


Notes:

The lower-case "mandatory" used in the original text does not represent any form of requirement in IETF documents, therefore replacing with upper-case "MANDATORY" is needed.

The reference to per-EVI Ethernet A-D routes advertised by both "bridging" EVPN and EVPN-VPWS is needed to remove possible doubts about the scope of this requirement since the standard is about EVPN-VPWS.

--
Verifier note: see also https://mailarchive.ietf.org/arch/msg/bess/vBYU98CJkLvHfvnX_6wIsV2cCFM/

Status: Rejected (2)

RFC 8214, "Virtual Private Wire Service Support in Ethernet VPN", August 2017

Source of RFC: bess (rtg)

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

Reported By: gangadhara reddy chavva; SatishKumar N Rodd
Date Reported: 2018-12-10
Rejected by: Martin Vigoureux
Date Rejected: 2019-06-17

Section 3.1 says:

C If set to 1, a control word [RFC4448] MUST be present
when sending EVPN packets to this PE. It is
recommended that the control word be included in the
absence of an entropy label [RFC6790].

It should say:

C If set to 1, a control word [RFC4448] MUST be present
when sending EVPN packets to this PE. It is
recommended that the control word be included in the
absence of an entropy label [RFC6790]. 

For detailed explanation of the behavior of EVPN VPWS 
session based on control word bit can be referred link: 
https://tools.ietf.org/html/rfc4447#section-6.2

which explains all combinations of control word 
configurations in detailed way whic was missing in RFC8214.

Notes:

RFC8214 doesn't mention the cases where control word configuration between the PE's can mismatch, disabled, enabled. which will lead to ambiguity in protocol implementation.
--VERIFIER NOTES--
This could change the specification in a way which in fact would likely require consensus. Authors of this errata are encouraged to follow the normal process and start with having a discussion in BESS WG.

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

Reported By: Luc Andre Burdet
Date Reported: 2020-04-22
Rejected by: Martin Vigourex
Date Rejected: 2021-02-08

Section 3.1, 8 says:

3.1.  EVPN Layer 2 Attributes Extended Community
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   MBZ                   |C|P|B|  (MBZ = MUST Be Zero)
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Name     Meaning
         ---------------------------------------------------------------
         P        If set to 1 in multihoming Single-Active scenarios, ...
         B        If set to 1 in multihoming Single-Active scenarios, ...
         C        If set to 1, a control word [RFC4448] MUST be present ...

8.  IANA Considerations
   Initial registrations are as follows:

        P      Advertising PE is the primary PE.
        B      Advertising PE is the backup PE.
        C      Control word [RFC4448] MUST be present.


It should say:

Option 1 : change explicit bitfield
==========
3.1.  EVPN Layer 2 Attributes Extended Community
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
##<swap>   |   MBZ                   |C|B|P|  (MBZ = MUST Be Zero)
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Name     Meaning
         ---------------------------------------------------------------
         P        If set to 1 in multihoming Single-Active scenarios, ...
         B        If set to 1 in multihoming Single-Active scenarios, ...
         C        If set to 1, a control word [RFC4448] MUST be present ...

8.  IANA Considerations
   Initial registrations are as follows:

        P      Advertising PE is the primary PE.
        B      Advertising PE is the backup PE.
        C      Control word [RFC4448] MUST be present.


Option 2 : change implicit order
==========
3.1.  EVPN Layer 2 Attributes Extended Community
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   MBZ                   |C|P|B|  (MBZ = MUST Be Zero)
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Name     Meaning
         ---------------------------------------------------------------
##       B        If set to 1 in multihoming Single-Active scenarios, ...
##<swap 'implicit' list order B,P to match bitfield>
##       P        If set to 1 in multihoming Single-Active scenarios, ...
         C        If set to 1, a control word [RFC4448] MUST be present ...

8.  IANA Considerations
   Initial registrations are as follows:

##      B      Advertising PE is the backup PE.
##<swap 'implicit' list order B,P to match bitfield>
##      P      Advertising PE is the primary PE.
        C      Control word [RFC4448] MUST be present.




Notes:

While technically section 8 is not requesting any bit-position from IANA registry, the ordering of requests P-B-C vs. the field definition B-P-C is confusing, or at least inconsistent.

A clarifying statement is required:
- the field definition is should be swapped; or
- the field definition shall prime over all the places implying order when listing P-B-C
--VERIFIER NOTES--
This is not a technical errata or at least the reasonable solution to it seems to be editorial (shifting text around) rather than modifying the order of bits on the wire.

Report New Errata



Advanced Search