Please see my comments marked w/ [AS] below:
Just so that everyone is aware of the history, I introduced the control plane signaling concept for L2VPN, as well as PW status signaling, capability exchange and PW QoS signaling for throttling the traffic. EVPN utilized that idea and applied in EVPN signaling to offer related benefits. https://tools.ietf.org/html/draft-shah-pwe3-control-protocol-extension-00 [AS] Himanshu, please do not make such unfounded claims as it may undermine your credibility. Making such claims is like saying EVPN is based on VPLS (RFC 4762) because in that RFC, MAC list TLV is defined and can be signaled in control plane for a PW ☺ EVPN was designed to address a specific set of requirements listed in RFC 7209 and you may want to enlighten people in this list on how your above draft addresses any of the requirements specified in that RFC (and please elaborate for everyone’s sake :-) Since this is not a technical discussion anymore and Sami wants to address my concerns in the next rev of the draft, it is not productive to engage in any more discussions and I will wait till the next rev. is published to see how my raised issues with the so called “simple solution” are addressed. -Ali Control plane learning was used in arp-mediation (RFC 6575) and IPLS (RFC 7436). (Just a note on the history). Thanks, Himanshu From: BESS <bess-boun...@ietf.org> on behalf of "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com> Date: Friday, November 20, 2020 at 2:15 AM To: "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net>, "Sami com>" <boutros.s...@gmail.com> Cc: "bess@ietf.org" <bess@ietf.org> Subject: [**EXTERNAL**] Re: [bess] comments on draft-boutros-bess-elan-services-over-sr Hi Sami and Jeffrey, Please see some comments/replies in-line. Thank you! Jorge From: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> Date: Thursday, November 19, 2020 at 7:20 PM To: Sami Boutros <boutros.s...@gmail.com>, Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> Cc: bess@ietf.org <bess@ietf.org> 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. <snip> Jeffrey From: Sami Boutros <boutros.s...@gmail.com> Sent: Thursday, November 19, 2020 12:11 PM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> Cc: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; bess@ietf.org 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) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> 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. 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. 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. 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. I have a few more, but those are enough to start. Thanks, Sami Thank you! Jorge From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> Date: Thursday, November 19, 2020 at 12:46 PM To: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> 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 BESS@ietf.org<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$> _______________________________________________ BESS mailing list BESS@ietf.org<mailto:BESS@ietf.org> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
