Re: [bess] [Technical Errata Reported] RFC9135 (7686)

[John Scudder <[e-mail]>]

Hi Authors and all,

While we are looking at RFC 9135, please look at this one too. Looks reasonable.

Thanks and happy Friday,

—John

> On Oct 20, 2023, at 10:39 AM, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted for RFC9135,
> "Integrated Routing and Bridging in Ethernet VPN (EVPN)".
> 
> --------------------------------------
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7686__;!!NEt6yMaO-gk!Bv40CvO596tIrUqB8Ny93blSg-Ou7E6QfK7hNtizTCvfc_Dtl8A83hkLnmj8y6nqZy7mVbWMztGjuGmjA0e6QA$
> 
> --------------------------------------
> Type: Technical
> Reported by: Denis Vrkic <[e-mail]>
> 
> Section: 6.1
> 
> Original Text
> -------------
> 6.1.  Control Plane - Advertising PE
> 
>   When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address
>   of an attached TS (e.g., via an ARP request or ND Neighbor
>   Solicitation), it populates its MAC-VRF/BT, IP-VRF, and ARP table or
>   NDP cache just as in the case for symmetric IRB.
> 
> Corrected Text
> --------------
> 6.1.  Control Plane - Advertising PE
> 
>   When a PE (e.g., PE1 in Figure 4 above) learns the MAC and IP address
>   of an attached TS (e.g., via an ARP request or ND Neighbor
>   Solicitation), it populates its MAC-VRF/BT and ARP table or
>   NDP cache.
> 
> Notes
> -----
> - advertising PE  (egress PE)  is not advertising Label2 ("the MPLS Label2 field MUST NOT be included in this route.")
> - so this must be asymmetric egress PE
> - in 4.2 is stated that: "the asymmetric IRB mode simplifies the forwarding model
>   and saves space in the IP-VRF route table, since host routes are not   installed in the route table."
> - so i guess that,  advertising  PE  in asymmetric mode, is NOT leaning/storing local IP to IP-VRF table only ARP (bound to IP-VRF) and MAC into MAC-VRF
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding-15)
> --------------------------------------
> Title               : Integrated Routing and Bridging in Ethernet VPN (EVPN)
> Publication Date    : October 2021
> Author(s)           : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
> Category            : PROPOSED STANDARD
> Source              : BGP Enabled ServiceS
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG