Re: [bess] Issues w/ draft-boutros-bess-elan-services-over-sr

Hi Sami,

Sighhh! The first section of your draft (section 1) and the first two paragraphs of that section talks about (1) and (2) that I mentioned in my email. Basically, Introduction section states these two reasons as the underlying reasons for your draft. As I explained in details in my response, we have been there and done that long time ago; however, I don’t see any mention of the previous work and RFCs in your draft, so maybe you don’t know about them (History is the best teacher one can have).

Also, you didn’t address any of them issues that I raise and instead. I will list them again here and please respond  clearly to each of them:

  1.  If you want to do data-plane learning over SR, why not use PBB-EVPN over SR. As I mentioned PBB-EVPN is agnostic of underlay tunnel and it can work with SR, MPLS, TE, etc.
  2.  How does your solution take care of VxLAN encoding which is prevalent in DC and EN? For VxLAN w/ data-plane learning, can you tell me why RFC 7348 (done 10 years ago) is not applicable? Needless to say that both data-plane and control-plane solutions for VxLAN was introduced at the same time about 10 years ago and industry decided in favor of control-plane!!
  3.  How do you want to address IRB in your proposal? Will IRB be never be used in your proposal?
  4.  How do you want to address unequal LB for All-Active MH?
  5.  How do you want to address host mobility where a MAC is associated with multiple IP address?

Now, with respect to your two claims:

  1.  Simplification: A solution can be simplified if it doesn’t need to address much of anything ☺ I.e., if it doesn’t need to address IRB, to address unequal LB, to address multiple IP address for a MAC, to address optimum mcast for L2&L3 simultaneously (IRB), etc.
  2.  Anycast SID: the notion of anycast SID and anycast IP address for All-Active multi-homing is not new and again has been done for ages. Cisco proprietary solution for All-Active multi-homing (called VPC) before EVPN was based on anycast IP address. However, there are drawback for it – one of which is underlay topology decides LB instead of the actual link BW of MCLAG!!
Cheers,
Ali

From: Sami Boutros <boutros.sami@gmail.com>
Date: Thursday, November 19, 2020 at 6:32 PM
To: "Ali Sajassi (sajassi)" <sajassi=40cisco.com@dmarc.ietf.org>
Cc: "bess@ietf.org" <bess@ietf.org>, Cisco Employee <sajassi@cisco.com>, Sami Boutros <sboutros@ciena.com>
Subject: Re: [bess] Issues w/ draft-boutros-bess-elan-services-over-sr

Hi Ali,

The draft doesn’t state neither 1 or 2 below. I’m not sure if we are looking at the same draft.

Here is the text in the draft introduction

   The goal of the proposed approach is to greatly simplify control

   plane functions and minimize the amount of control plane messages PE

   nodes have to process.  In this version of the document, we assume

   Segment Routing (SR) underlay network.  A future version of this

   document will generalize the underlay network to both classical MPLS

   and SR technologies.

   The proposed approach does not require PW, and hence the control

   plane complexity and message overhead associated with signaling and

   maintaining PWs are eliminated.

Our goal is to simplify:

1- The control plane by signaling very few messages possibly 1 message per node to signal all ELAN services configured on that node, presenting each ELAN service as 1 bit in the control plane message.

2- The data plane by setting up much less control plane elements like PWs, tunnels etc., and more importantly leveraging SR redundancy mechanisms of any cast SID to remove the need of any overlay convergence or redundancy mechanisms.

Not sure if any the stuff u listed below can address any of the above!

Thanks,

Sami

On Nov 19, 2020, at 12:21 PM, Ali Sajassi (sajassi) <sajassi=40cisco.com@dmarc.ietf.org<mailto:sajassi=40cisco.com@dmarc.ietf.org>> wrote:

Sami,

Since we didn’t have time to discuss the issues during the BESS meeting, let me explain and elaborate them here:

The draft states the following two main objectives for its purpose but both have been addressed already !!

  1.  Reducing # of PWs in VPLS:

     *   VPLS (both BGP and LDP) is a 20-year old technology which is getting deprecated and many providers (SP, DC, and EN) are moving toward EVPN. However, a few years after VPLS (about 15 years ago) we introduced PBB-VPLS (RFCs 7041 and 7080) to address the PW scale issues along with few other things.

  1.  Reducing # of EVPN MAC route advertisements:

     *   This may have been an issue 10 years ago and that’s why we introduced simultaneously both EVPN and PBB-EVPN (RFC 7623) but not anymore. PBB-EVPN uses data-plane learning and it uses concepts of service-id, source B-MAC (for MAC learning) and destination B-MAC (for BUM ID), and same concepts are used in your draft. Furthermore RFC 7623 supports All-Active multi-homing as well as Single-Active with all the improvements that came later including per-ISID c-mac flushing that Jorge presented during the call. Needless to say that PBB-EVPN is transport agnostic and can work with SR, MPLS, TE, etc.

So,  my question is that: what is the point of this draft? Are you trying to have a bit more compressed header over what we currently have in PBB-EVPN because in terms of functionality, I don’t see much difference. However, I see even more issues than PBB-EVPN such as IRB handling  and Unequal load-balancing  for an ES.

The idea of breaking a PW in to three components of service-id, source-id, and dest-id has been around for almost twenty years. I introduced mvpls draft in 2002, followed by PBB-VPLS. VxLAN RFC (which also talks about data-plane learning) is along the same idea introduced in 2010. And finally PBB-EVPN in 2012. So, why do we need to re-invent the wheel again?

-Ali
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess