Re: [bess] [Pals] [EXTERNAL] [Technical Errata Reported] RFC7432 (7758)

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 <agmalis@gmail.com> wrote:
> 
> Sasha,
> 
> Andrew will take care of it.
> 
> Cheers,
> Andy
> 
> 
> On Thu, Jan 11, 2024 at 5:37 AM Alexander Vainshtein <Alexander.Vainshtein@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.mykhailyk@gmail.com> 
> Sent: Thursday, January 11, 2024 12:33 PM
> To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
> Cc: RFC Errata System <rfc-editor@rfc-editor.org>; rtg-ads@ietf.org; bess@ietf.org; pals@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.Vainshtein@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-bounces@ietf.org> On Behalf Of RFC Errata System
> Sent: Thursday, January 11, 2024 10:03 AM
> To: sajassi@cisco.com; raggarwa_1@yahoo.com; nabil.n.bitar@verizon.com; aisaac71@bloomberg.net; uttaro@att.com; jdrake@juniper.net; wim.henderickx@alcatel-lucent.com; aretana.ietf@gmail.com; jgs@juniper.net; andrew-ietf@liquid.tech; giheron@cisco.com; nabil.n.bitar@verizon.com
> Cc: pavel.mykhailyk@gmail.com; pals@ietf.org; rfc-editor@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.mykhailyk@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
> Pals@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
> Pals@ietf.org
> https://www.ietf.org/mailman/listinfo/pals