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.
2. 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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
