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 <rfc-edi...@rfc-editor.org> > 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 <vrkic.de...@gmail.com> > > 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 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
