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

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
>