Re: [bess] [**EXTERNAL**] Re: comments on draft-boutros-bess-elan-services-over-sr

["Shah, Himanshu" <[e-mail]>]

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 <[e-mail]> on behalf of "Ali Sajassi (sajassi)" <sajassi=[e-mail]>
Date: Friday, November 20, 2020 at 4:21 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>, "Jeffrey (Zhaohui) Zhang" <[e-mail]>, "Sami com>" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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)" <[e-mail]>
Date: Friday, November 20, 2020 at 12:26 PM
To: Cisco Employee <[e-mail]>, "Jeffrey (Zhaohui) Zhang" <[e-mail]>, Sami Boutros <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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) <[e-mail]>
Date: Friday, November 20, 2020 at 7:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>, Jeffrey (Zhaohui) Zhang <[e-mail]>, Sami Boutros <[e-mail]>
Cc: [e-mail] <[e-mail]>
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