Hi Alexander, For sure, multi-homed scenario is the primary beneficiary from "mass-withdraw". Could I argue a little bit that it is valuable for "single-homed" too?
1. If MAC learning is in the data plane, then probably not much additional value from faster signaling. But it is: remote PE would drop the traffic locally till it would cross the network (network resource savings). I agree that it is not a big benefit. Some engineers could consider it more valuable. 2. A reminder that EVPN is open to more clever learning options (see below). Then Remote PE could not just drop traffic locally but additionally signal the source CE that it should look for all alternative paths (like rise expensive 3GPP or Satellite link). Then I believe that RT-1 signaling is useful even for single-homed. Some could say that such a scenario is low probable in the real-life yet. Conclusion: I do not understand why "single-homed" was not optimized if it is possible and easy. It may be needed in the future. IMHO: it is not a big problem because it is possible to cheat that every site is "multi-homed", just many redundant ESIs are not connected yet. We have a workaround. Section 4<https://datatracker.ietf.org/doc/html/rfc7432#section-4>. BGP MPLS-Based EVPN Overview However, learning between PEs and CEs is done by the method best suited to the CE: data-plane learning, IEEE 802.1x, the Link Layer Discovery Protocol (LLDP), IEEE 802.1aq, Address Resolution Protocol (ARP), management plane, or other protocols. Eduard From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Thursday, December 9, 2021 1:06 PM To: Vasilenko Eduard <vasilenko.eduard=40huawei....@dmarc.ietf.org> Cc: bess@ietf.org Subject: Re: [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs Eduard hi! I do not see any contradiction in your scenario. Mass withdrawal provides for (relatively) fast restoration of traffic that originally has been sent to a multi-homed customer site via one of the links comprising a multi-homed Ethernet Segment when this link fails. >From my POV it does not have any other purpose. In particular, it is not >relevant if the link that connects a single-homed customer site to al EVPN PE >fails - because such a link in any case is a single point of failure, and >traffic to the customer site in question cannot be restored. Multi-homed customer sites MUST be attached to EVPN PEs using multi-homed Ethernet Segments with non-zero ESI in order to enable the filtering mechanisms (DF election ESI label-based split horizon filtering) that prevent Ethernet loops. And different multi-homed customer sites MUST be attached to EVPN PEs using multi-homed Ethernet Segments with different non-zero ESI. 7432 is quite clear about that IMHO. Hopefully these notes will be useful. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com> -----Original Message----- From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of Vasilenko Eduard Sent: Tuesday, December 7, 2021 9:25 PM To: bess@ietf.org<mailto:bess@ietf.org> Subject: [EXTERNAL] [bess] Contradiction for the RFC 7432 definition of the fast convergence (withdrawal) for single-homed CEs Hi EVPN guru, It looks like RFC 7432 section 8.2.1 (Constructing Ethernet A-D per Ethernet Segment Route) has an error: "The Ethernet A-D route is not needed when the Segment Identifier is set to 0 (e.g., single-homed scenarios)." Because without "per ES route" it would not be possible to signal "mass withdrawal" If CE-PE connection would fail That plainly promised for single-homed CEs in section 8.2: " If no other PE had advertised an Ethernet A-D route for the same segment, then the PE that received the withdrawal simply invalidates the MAC entries for that segment." Or implied in section 17.3: "The Ethernet A-D per ES routes should be used by an implementation to optimize the withdrawal of MAC/IP Advertisement routes." Have I missed something? Eduard _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> https://clicktime.symantec.com/33TGeg5iE8LuPnyBxVgTtwN6H4?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess Notice: 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. Notice: 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.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess