Several (my) points –
* There is no intent to “knock off” EVPN and replace with this technology.
Instead, it is a lightweight solution that offers a lot of benefits.
* We have several L2VPN solutions; LDP based, BGP based, EVPN – each
solution with benefits of its own. And so is the Sami’s proposal.
* Discussions below is steering towards – “data plane learning is evil and
control plane learning is god sent”.
* This is not true, one has to use the tools available in the chest to
produce the best solution
* “oh if anycast is missing, let us put that in EVPN and punt this
solution” is completely wrong approach
* The offered solution, uniquely leverages the SR technology to greatly
simplify the ELAN services
Thanks,
Himanshu
From: BESS <[email protected]> on behalf of "Ali Sajassi (sajassi)"
<[email protected]>
Date: Friday, November 20, 2020 at 4:21 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected]>,
"Jeffrey (Zhaohui) Zhang" <[email protected]>, "Sami com>"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [**EXTERNAL**] Re: [bess] comments on
draft-boutros-bess-elan-services-over-sr
Hi Jorge,
Yes, EVPN has evolved over many years and that’s why it has such a big traction
in industry (thanks to your contributions and many others) and we have always
been open to improvements (mostly driven by our customers) and evaluated them
objectively. So, if there is any suggestion wrt to Anycast ID, we can
definitely evaluate it based on what use cases it covers, All-active mode (both
equal and unequal LB), failure scenarios, convergence, impact to underlay and
overlay protocols, as well as applicability to different encapsulations to name
a few.
Cheers,
Ali
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected]>
Date: Friday, November 20, 2020 at 12:26 PM
To: Cisco Employee <[email protected]>, "Jeffrey (Zhaohui) Zhang"
<[email protected]>, Sami Boutros <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi Ali,
Yes, I understand it has pros and cons. What I meant is that, if using anycast
SID in EVPN satisfies Sami’s requirements (or most), there is no need to add a
completely new technology that needs to reinvent how to do all services (elan,
eline, etree, L3, mcast, etc) and relies on data-plane mac-learning - we can
apply anycast SIDs to existing EVPN.
Thanks.
Jorge
From: Ali Sajassi (sajassi) <[email protected]>
Date: Friday, November 20, 2020 at 7:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]>,
Jeffrey (Zhaohui) Zhang <[email protected]>, Sami Boutros
<[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi Jorge,
<snip>
Agreed, any technology can use any cast SID.
[jorge] if you want to specify an anycast SID solution for EVPN as an
alternative to aliasing, since it may have its merits, I’ll be glad to
investigate it with you and help. However data plane-learning sounds a step
back to me.
<end of snip>
I looked at this long time ago and it had some issues. For example, if you pass
the anycast ID in underlay, then the load balancing is dictated by your
underlay topology instead of the actual link BW of MCLAG. If you try to get
fancier and distribute link bw info in the underlay (IGP), then you are
burdening the underly protocol with overlay info. And finally if you
distribute it in the overlay (e.g., BGP), it becomes very similar to what we do
currently.
BTW, Aliasing feature in EVPN is not mandatory but rather optional as you know.
Cheers,
Ali
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
