> 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
