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....@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>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
