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
-----Original Message-----
From: BESS <bess-boun...@ietf.org> On Behalf Of Vasilenko Eduard
Sent: Tuesday, December 7, 2021 9:25 PM
To: 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
