Well, if you want to really care about customers, creating all these variations is not doing justice to them. If you want less combinations, you keep VXLAN the way it is right now, with no changes. You keep LISP the way it is right now with no changes. You get L2 and L3 overlays with a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to the author ;-) or use BGP as an alternative push control-plane.
As for NSH, you create a new header because it is completely new requirement and has not be deployed anywhere. Since it is brand new, you need new hardware and code to be developed to support it. So changing VXLAN and LISP to support NSH doesn't make sense because you inject change in 3 places rather than in 1 new place, creating more protocol machinery, complexity, and combinations that will frustrate customers (not to mention vendor call centers). Less entropy please, Dino On Jul 15, 2014, at 10:51 PM, Fabio Maino <[email protected]> wrote: > Dino, > I believe that using a format that can share as much as possible with the two > protocols deployed today will give a better chance to GPE to be implemented, > as vendors may want a cost effective way to migrate to the new protocol while > preserving compatibility with legacy implementations. > > The fact that GPE provides a way to be extended, either with a shim a-la NSH > or making availabe more bits in the header for future features, I think opens > up to the addition of new features (explicit service tagging, as an example) > in a more organic way than trying to use the few bits left in VXLAN or LISP. > > Unfortunately, in the LISP case, this comes to the expense of some features > that are in the current specification, but I believe those same features can > be mapped on a GPE+shim header, so a new implementation would be able to > provide the equivalent of those features (e.g. nonce). > > It's hard to find the right balance between backward compatibility and > evolution of the encapsulation, but I believe GPE gets to a decent compromise. > > Thanks, > Fabio > > > > On 7/15/14, 4:47 PM, Dino Farinacci wrote: >>>> Hi VXLAN-gpe authors, >>>> >>>> Abstract: technically this is not extending a VXLAN but defines a new >>>> protocol that looks similar to VXLAN (demonstrated by need for new UDP >>>> port assignment). >>> We are trying to balance re-use of the VXLAN format and the need to support >>> existing non-GPE hardware that might already be deployed. We looked at >>> using the same port, and the new one, and decided, at this point that a new >>> port is easier for migration but since the packet format is essentially >>> VXLAN to keep the VXLAN name. >> Paul, this design seems to be going in circles. If a new port is used, why >> not make the new port for VXLAN mean layer-3 protocols follow? Or better >> yet, have a demux field after the VXLAN header so you don't have to use >> VXLAN header bits. Because the P-bit is using a precious bit in the >> VXLAN/LISP header and the nonce field that can be used for other things (we >> have history that shows a nonce in the header is a cheap form of obscure >> security). >> >> If you do this then you have no compatibility problems with initial VXLAN >> and LISP implementations. >> >> And, most importantly, there will be less confusion in the marketplace. >> >> Dino >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
