RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Reported (1)

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.

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