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) <saja...@cisco.com> Date: Friday, November 20, 2020 at 7:21 PM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>, Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>, Sami Boutros <boutros.s...@gmail.com> Cc: bess@ietf.org <bess@ietf.org> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
