Found 3 records.

Status: Verified (1)

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

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

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.

Report New Errata