Hi Jorge,
> On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) > <[email protected]> wrote: > > Hi everyone, > > Jeffrey, not sure how much of EVPN this solution is, since there are no > ‘overlay’ routes advertised. In fact the draft says that no routes type 1..4 > are needed at all. > But I see your point Jeffrey, and I agree the concept of the source > identification is not SR specific. Agreed, source identification is not SR specific. > > @Sami, > > I couldn’t speak during the meeting so I’ll throw a couple of general > comments/questions: > > While I see the anycast-SID as an interesting point, I disagree with the > document’s motivation that EVPN needed to introduce control-plane learning > due to the MP2P tunnels. What I said is with MP2P tunnels EVPN was forced to only control plane Mac learning. Are you saying this is incorrect? If so, Why? > Control plane learning has a lot of advantages and data-plane learning/aging > has tons of issues. So this should be debated in the WG. Sure, will be good to get Service providers input on that too. One thing to note here, our proposal is by no mean don’t use EVPN, it is simply another option that greatly simplify the control plane and remove tons of control plane overhead, as well simplify the data plane and remove need for any overlay convergence. > > Irrespective, the anycast-SID idea could work in regular EVPN as an optional > alternative to aliasing. You don’t need to do data-plane learning for that, > right? Agreed, any technology can use any cast SID. > The document seems to claim fast mac move. How can that be guaranteed if the > mac learning is data plane based? In data plane when a MAC move from one port to another, or one PW to another, routers simply adjust no need for any EVPN procedure for MAC move. > > ARP suppression is not a merit of this solution. It could work even in > RFC4761/74762 VPLS networks. > Agreed, we don’t claim any of that, the proposal doesn’t claim that it invented ARP suppression, or invented SR, it simply say it will use it this way, I hope this is OK. > > I have a few more, but those are enough to start. Thanks, Sami > Thank you! > Jorge > > > From: BESS <[email protected]> > Date: Thursday, November 19, 2020 at 12:46 PM > To: [email protected] <[email protected]> > Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr > > Hi, > > It seems that the draft is about using data-plane mac learning in an > EVPN-like solution. That retains other properties of EVPN, but removes the > need for advertising MAC addresses, with the consequences/problems that Ali > was trying to point out. > > Leaving the pros and cons of data plane mac learning out, I want to point out > that the idea is actually orthogonal with SR - even if SR were not invented > this concept still applies. With VXLAN the source address corresponds to the > "source node SID", and with MPLS the "PE Distinguisher Label" in MVPN (and > extended to other use cases) serves the same purpose. That same "PE > Distinguisher Label" concept is also used in my Generic Fragmentation > proposal. > > With that, the discussion for this draft should be in BESS, not in SPRING. > > Jeffrey > > Juniper Business Use Only > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > <https://www.ietf.org/mailman/listinfo/bess>_______________________________________________ > BESS mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/bess > <https://www.ietf.org/mailman/listinfo/bess>
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
