Eduard,
Lots of thanks for a prompt response.
I doubt "mass withdrawal" in the single-homed scenarios has real added value.
However, even if it has, IMHO advertisement and withdrawal of per-ES EVPN Type
1 routes with zero ESI vale in their NLRI in any case will not help you to
enjoy these (problematic) benefits.
Consider the case when a given EVI in a given PE is attached to two (or more)
single-homed customer sites via different links (and performs local switching
between these sites).
You can, of course, advertise the per-ES EVPN Type 1 route with ESI=0 more than
once (in fact, you sometimes have to do that as per RFC 7432 in any case).
But what shall you do when one (and only one) of these links fails? Even if you
advertise these routes with different RD values for different links, there
would be no way for the remote PEs to maintain this association for the
relevant FDB entries.
My 2c,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@rbbn.com
From: Vasilenko Eduard <vasilenko.edu...@huawei.com>
Sent: Thursday, December 9, 2021 2:24 PM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Vasilenko Eduard
<vasilenko.eduard=40huawei....@dmarc.ietf.org>
Cc: bess@ietf.org
Subject: [EXTERNAL] RE: Contradiction for the RFC 7432 definition of the fast
convergence (withdrawal) for single-homed CEs
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://clicktime.symantec.com/38kGZeKBZ1aHkskoKJxSyYC6Gi?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7432%23section-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<mailto:vasilenko.eduard=40huawei....@dmarc.ietf.org>>
Cc: bess@ietf.org<mailto: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.
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
