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> 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 !!
>  
> 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.
> 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 <https://www.ietf.org/mailman/listinfo/bess>