Sasha, Andrew will take care of it.
Cheers, Andy On Thu, Jan 11, 2024 at 5:37 AM Alexander Vainshtein < [email protected]> wrote: > Pavel, > > Lots of thanks for your email. > > Looks as we are aligned😊. I am not sure if the reporter of an Erratum > can revoke it (never tried this). > > > > > > Regards, > > Sasha > > > > *From:* Pavel Mykhailyk <[email protected]> > *Sent:* Thursday, January 11, 2024 12:33 PM > *To:* Alexander Vainshtein <[email protected]> > *Cc:* RFC Errata System <[email protected]>; [email protected]; > [email protected]; [email protected] > *Subject:* Re: [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 > (7758) > > > > Hi > > Sorry, looks like i just misunderstood some terms, so ES route means EVPN > Type 4 (not 1) - you are absolutely right, it is used for DF and limited > to PEs that are connected to MH Po. > > > > Thanks for clarification > > With Regards > > > > чт, 11 янв. 2024 г. в 11:56, Alexander Vainshtein < > [email protected]>: > > Hi all, > > > > IMHO and FWIW the corrected text proposed in this Erratum is *technically > incorrect*, and. Therefore, the Erratum must be *rejected*. > > > > Ethernet Segment (EVPN Type 4) routes are used solely for discovery of all > PEs that participate in the process of election of the Designated Forwarder > (DF)for the specific MH ES, and their parameters that affect the election > process (e.g., DF Election algorithm and its parameters). This includes > all the PEs that are attached to the MH ES in question, and none other. > > > > The PEs that are not attached to the MH ES in question do not participate > in the DF election and, *by design*, *are not aware of the DF election > results*. > > In the case of All-Active multi-homing, there is no need for such PEs to > be aware of these results. > > The case of Single-Active multi-homing is addressed by the following > statement from Section 8.4 of RFC 7432 (the relevant text is highlighted): > > > > The backup path is a closely related function, but it is used in > > Single-Active redundancy mode. In this case, a PE also advertises > > that it has reachability to a given EVI/ES using the same combination > > of Ethernet A-D per EVI route and Ethernet A-D per ES route as > > discussed above, but with the "Single-Active" bit in the flags of the > > ESI Label extended community set to 1. A remote PE that receives a > > MAC/IP Advertisement route with a non-reserved ESI SHOULD consider > > the advertised MAC address to be reachable via any PE that has > > advertised this combination of Ethernet A-D routes, and it SHOULD > > install a backup path for that MAC address. > > > > AFAIK, EVPN implementation that follow the design defined in 7432 have > been widely deployed for years. > > > > My 2c, > > Sasha > > > > *From:* Pals <[email protected]> *On Behalf Of *RFC Errata System > *Sent:* Thursday, January 11, 2024 10:03 AM > *To:* [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > *Cc:* [email protected]; [email protected]; [email protected] > *Subject:* [EXTERNAL] [Pals] [Technical Errata Reported] RFC7432 (7758) > > > > The following errata report has been submitted for RFC7432, > "BGP MPLS-Based Ethernet VPN". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7758 > > -------------------------------------- > Type: Technical > Reported by: Pavel Mykhailyk <[email protected]> > > Section: 8.1.1 > > Original Text > ------------- > The Ethernet Segment route filtering MUST be done such that the > Ethernet Segment route is imported only by the PEs that are > multihomed to the same Ethernet segment > > Corrected Text > -------------- > The Ethernet Segment route filtering MUST be done such that the > Ethernet Segment route is imported only by the PEs that are > connected to same EVI > > Notes > ----- > In all text in context of evpn-multihoming term ES used for logical set of > links - distributed PortChannel when CE use several links to different PEs > as single aggregate link. But in section 8.1.1 term ES can't be used in > same way, becouse ES routes must be distributed for all PE that hold same > VLAN. For example PE1 and PE2 connected to CE1 with EVPN-MH PortChannel > (ESI-1) and use VLAN 10, CE2 connected to PE3 and use VLAN 10 but not use > any aggregation - not included to any ES. PE3 build mac table for CE1 mac > and must use ESI-1 as next-hop, so it must apply ES route and not filter > it, regardles of local connection to ES in terms of EVPN-MH PortChannel. So > each PE connected to EVI import this route > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7432 (draft-ietf-l2vpn-evpn-11) > -------------------------------------- > Title : BGP MPLS-Based Ethernet VPN > Publication Date : February 2015 > Author(s) : A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, > J. Drake, W. Henderickx > Category : PROPOSED STANDARD > Source : Layer 2 Virtual Private Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > Pals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pals > > > > *Disclaimer* > > This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all copies, > including any attachments. > > _______________________________________________ > Pals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pals >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
