> On Jul 16, 2014, at 6:16 PM, Fabio Maino <[email protected]> wrote: > > But since we're respinning HW and SW to add one feature, in 2 different > implementations, why don't we use this chance to converge to a single encap > that can be extended to do that (and more)?
Because users have older products from cisco and other vendors who are deploying overlays now. So the decision is already made about which encapsulation format to use for which type of overlay. Focusing on NSH (only) is a good thing because that is a transport independent service chaining feature that does not already exist. Dino > > Fabio > > On 7/16/14, 6:10 PM, Dino Farinacci wrote: >>> 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
