> This is where we disagree Dino: we keep seeing proposals to extend the > capability of network virtualization protocols. Security, as an example, is > one area where even you are proposing extensions. I hope this can become an > opportunity to add to the capabilities of the existing protocols while we go > through the next generation of HW and SW.
Please don't misunderstand: (1) We have no data-plane encryption in LISP, we are adding this. (2) We have L3 overlays with LISP, we don't need another data-plane to do the same thing. (3) We have L2 overlays with VXLAN, we don't need another data-plane to do the same thing. Dino > > Fabio > > On 7/16/14, 5:23 PM, Dino Farinacci wrote: >>> Dino, >>> GPE is not changing VXLAN nor LISP, as today's implementations cannot be >>> changed. GPE is proposing a converged extension of both protocols that add >>> some new features that, I believe, are needed. >> You change header fields, you are changing the protocol. I know you can be >> compatible but you can do L2 and L3 overlays today so there is no point in >> putting a protocol demux in VXLAN to do L3 overlays and a protocol demux in >> LISP-4341 to do L2 overlays. >> >>> All of VXLAN features are supported in GPE. >>> >>> In the case of LISP, unfortunately, two features (nonce and map-versioning) >>> could not be accommodated in GPE. This is not very different than any of >>> today's LISP implementations that may decide to not support those two >>> features (for whatever reason: cost, complexity, use cases addressed by the >>> implementation... independently from GPE). >> But supplying nonces is implemented pervasively. >> >>> What GPE is trying to do is to simplify next generation implementations by >>> keeping GPE as close as possible to the existing encapsulations, adding on >>> top of those. I maintain that an implementation supporting GPE, LISP and >>> VXLAN will be more cost effective than one that supports VXLAN, LISP and a >>> clean slate protocol, and may have better chances of being deployed. >> I know what it is trying to do. You keep saying that but the existing >> protocols already do it with no changes. So I think this change is >> effectively a noop. >> >> Dino >> >>> Fabio >>> >>> >>> On 7/16/14, 1:05 PM, Dino Farinacci wrote: >>>> 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
