Hi Jorge, Please see few comments inline.
> > From: Jeffrey (Zhaohui) Zhang <[email protected] <mailto:[email protected]>> > Date: Thursday, November 19, 2020 at 7:20 PM > To: Sami Boutros <[email protected] <mailto:[email protected]>>, > Rabadan, Jorge (Nokia - US/Mountain View) <[email protected] > <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> > Subject: RE: [bess] comments on draft-boutros-bess-elan-services-over-sr > > To clarify, when I said “evpn-like solution” I was referring to the fact that > it uses service-SID/label instead of per-PW labels, and it supports split > horizon for multi-homing. > > As for control plane learning vs. data plane learning, I don’t know about > the history, but my impression is that control plane learning is considered > as a feature but not as a fallback solution for not having the PW contexts > for do data plane learning. I could be wrong though. > [jorge] I agree with you Jeffrey, to me is an improvement too. More below. > > > Jeffrey > > From: Sami Boutros <[email protected] <mailto:[email protected]>> > Sent: Thursday, November 19, 2020 12:11 PM > To: Rabadan, Jorge (Nokia - US/Mountain View) <[email protected] > <mailto:[email protected]>> > Cc: Jeffrey (Zhaohui) Zhang <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr > > [External Email. Be cautious of content] > > Hi Jorge, > > > > > On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) > <[email protected] <mailto:[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: > > 1. 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? > [jorge] No, I didn’t make myself clear enough – control plane is needed with > MP2P tunnels, yes, but what I meant is that in your motivation it *sounds* > like control-plane learning was a necessary evil due to the need for MP2P > tunnels to fix the scale issue. I see control-plane learning as an additional > improvement/feature, as Jeffrey was saying. > Our motivation is to simplify control plane for use cases that don’t need control plane MAC learning. > > 1. 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. > > > > > 2. 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. > [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. > Sure, we can consider this option for the control plane Mac learning too. > > > 3. 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. > [jorge] you are assuming that when that MAC moves to another port, it sends > BUM traffic that is flooded and all the nodes can update. That is not always > the case. The host that moves can simply generate known unicast traffic, and > hence most nodes in the network will have stale information for the aging > time. EVPN takes care of the mobility immediately as soon as the MAC that > moves generates *any* type of frame. > I see your point, this should be a good problem to solve for data plane Mac learning, if the node is learning a new Mac on a port should it flood even if the destination is known? > > > 4. 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. > [jorge] yes, that’s ok, just wanted to clarify Sami. > Cool Thanks, Sami > > > > > I have a few more, but those are enough to start. > > Thanks, > > Sami > > > Thank you! > Jorge > > > From: BESS <[email protected] <mailto:[email protected]>> > Date: Thursday, November 19, 2020 at 12:46 PM > To: [email protected] <mailto:[email protected]> <[email protected] > <mailto:[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/bess > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$> > _______________________________________________ > BESS mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/bess > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$> > > > Juniper Business Use Only >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
