Sasha, Andrew will take care of it.
Cheers, Andy On Thu, Jan 11, 2024 at 5:37 AM Alexander Vainshtein < alexander.vainsht...@rbbn.com> 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 <pavel.mykhai...@gmail.com> > *Sent:* Thursday, January 11, 2024 12:33 PM > *To:* Alexander Vainshtein <alexander.vainsht...@rbbn.com> > *Cc:* RFC Errata System <rfc-edi...@rfc-editor.org>; rtg-...@ietf.org; > bess@ietf.org; p...@ietf.org > *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 < > alexander.vainsht...@rbbn.com>: > > 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 <pals-boun...@ietf.org> *On Behalf Of *RFC Errata System > *Sent:* Thursday, January 11, 2024 10:03 AM > *To:* saja...@cisco.com; raggarw...@yahoo.com; nabil.n.bi...@verizon.com; > aisaa...@bloomberg.net; utt...@att.com; jdr...@juniper.net; > wim.henderi...@alcatel-lucent.com; aretana.i...@gmail.com; j...@juniper.net; > andrew-i...@liquid.tech; gihe...@cisco.com; nabil.n.bi...@verizon.com > *Cc:* pavel.mykhai...@gmail.com; p...@ietf.org; rfc-edi...@rfc-editor.org > *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 <pavel.mykhai...@gmail.com> > > 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 > p...@ietf.org > 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 > p...@ietf.org > https://www.ietf.org/mailman/listinfo/pals >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
