Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 19 Nov 2020 11:46:03 +0000

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

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 19 Nov 2020 13:09:15 +0000

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.

@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. 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.

  1.  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?

  1.  The document seems to claim fast mac move. How can that be guaranteed if the mac learning is data plane based?

  1.  ARP suppression is not a merit of this solution. It could work even in RFC4761/74762 VPLS networks.

I have a few more, but those are enough to start.
Thank you!
Jorge

From: BESS <[email-masked]>
Date: Thursday, November 19, 2020 at 12:46 PM
To: [email-masked] <[email-masked]>
Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi,

Jeffrey

_______________________________________________
BESS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bess

---

From: Sami Boutros <[email-masked]>
Date: Thu, 19 Nov 2020 08:52:23 -0800

Hi Jeff,

> On Nov 19, 2020, at 3:46 AM, Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> wrote:
> 
> Hi,
> 
> It seems that the draft is about using data-plane mac learning in an EVPN-like solution.

Actually the draft explicitly mention that we don’t need any EVPN routes, and not sure what EVPN-like solution you are referring too.

> 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.
> 

It will be good that you point out those specific consequences/problems.

> 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.

Agreed, but SR enabled the concept, via the ability to define SRGB for services across the network.

> 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.
> 

As I mentioned this is still about BGP enabled services, however we can still present this in SPRING.

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Thu, 19 Nov 2020 09:10:53 -0800

Hi Jorge,

> On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]> wrote:
> 
> Hi everyone,
>  

Agreed, source identification is not SR specific.

> 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.

Thanks,

Sami
> https://www.ietf.org/mailman/listinfo/bess <https://www.ietf.org/mailman/listinfo/bess>_______________________________________________
> BESS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/bess <https://www.ietf.org/mailman/listinfo/bess>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 19 Nov 2020 18:20:04 +0000

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.

Jeffrey

From: Sami Boutros <[email-masked]>
Sent: Thursday, November 19, 2020 12:11 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:

Hi everyone,

@Sami,

  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.

  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.

  1.

Thanks,

Sami

Thank you!
Jorge

From: BESS <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 19, 2020 at 12:46 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi,

Jeffrey

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$>

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 20 Nov 2020 07:14:48 +0000

Hi Sami and Jeffrey,

Please see some comments/replies in-line.

Thank you!
Jorge

From: Jeffrey (Zhaohui) Zhang <[email-masked]>
Date: Thursday, November 19, 2020 at 7:20 PM
To: Sami Boutros <[email-masked]>, Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: [email-masked] <[email-masked]>
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

Hi Jorge,

Hi everyone,

@Sami,

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.

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.

Thanks,

Sami

Thank you!
Jorge

Jeffrey

---

From: Sami Boutros <[email-masked]>
Date: Fri, 20 Nov 2020 09:46:57 -0800

Hi Jorge,

Please see few comments inline.

>  
> From: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>>
> To: Sami Boutros <[email-masked] <mailto:[email-masked]>>, Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> From: Sami Boutros <[email-masked] <mailto:[email-masked]>> 
> To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked] <mailto:[email-masked]>>
> Cc: Jeffrey (Zhaohui) Zhang <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Nov 19, 2020, at 5:09 AM, Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi everyone,
>  

Our motivation is to simplify control plane for use cases that don’t need control plane MAC learning. 

> [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-lea…

Sure, we can consider this option for the control plane Mac learning too.

> [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 gen…

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?

> [jorge] yes, that’s ok, just wanted to clarify Sami.

Cool

Thanks,

Sami
> From: BESS <[email-masked] <mailto:[email-masked]>>
> To: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> https://www.ietf.org/mailman/listinfo/bess <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$>
> https://www.ietf.org/mailman/listinfo/bess <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!VxGsf2muy1oOc43yyMHygNmGkHp0T1soQk5peu2Fy52TPBZCmPstnw7sc4NEkzej$>
>  
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 20 Nov 2020 18:21:33 +0000

Hi Jorge,

<snip>
<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

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 20 Nov 2020 20:25:56 +0000

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) <[email-masked]>
Date: Friday, November 20, 2020 at 7:21 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>, Jeffrey (Zhaohui) Zhang <[email-masked]>, Sami Boutros <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr
Hi Jorge,

<snip>

Cheers,
Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 20 Nov 2020 21:21:08 +0000

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)" <[email-masked]>
Date: Friday, November 20, 2020 at 12:26 PM
To: Cisco Employee <[email-masked]>, "Jeffrey (Zhaohui) Zhang" <[email-masked]>, Sami Boutros <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [bess] comments on draft-boutros-bess-elan-services-over-sr

Hi Ali,

Thanks.
Jorge

<snip>

Cheers,
Ali