FYI - I deleted this errata report at the request of the submitter. Thank you, RFC Editor/rv
> On Jan 11, 2024, at 5:04 AM, Andrew G. Malis <agma...@gmail.com> wrote: > > 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
