The other authors have graciously made that clear. Thanks. (Never write before coffee Šnever)
On 7/17/14 12:00 PM, "Fabio Maino (fmaino)" <[email protected]> wrote: >Ken, >there is no intent to tie SFC to this transport, rather to make this >transport capable to handle those (and possibly other) metadata. > >Fabio > >On 7/17/14, 6:27 AM, Ken Gray (kegray) wrote: >> Where Dino and I agree, and not to pick on Uri - I've seen the statement >> "additional headers/metadata" a few times now and it STILL sounds like >> "work around SFC", particularly in respect to the metadata part (since >> passing metadata was one of SFC's points). >> >> If you want to tilt at that windmill, I don't think that binding the >> solution to a particular transport encap is the optimal way to do it (if >> you can avoid doing so). >> >> On 7/16/14 7:37 PM, "Elzur, Uri" <[email protected]> wrote: >> >>> VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC >>> provides guidance for. I.e. given the anticipated interpretations, with >>> proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow >>>for >>> best backwards interoperability on the existing UDP 4789 and offer best >>> prospects for carrying the additional headers/metadata. This leads to >>>the >>> need for new UDP port for new formats >>> >>> Thx >>> >>> Uri ("Oo-Ree") >>> C: (949)-378-7568 >>> >>> >>> -----Original Message----- >>> From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong >>> Sent: Wednesday, July 16, 2014 4:00 PM >>> To: Fabio Maino; Dino Farinacci >>> Cc: [email protected] >>> Subject: Re: [nvo3] Comments on >>> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>> >>> If GPE is the VXLAN evolution, why it request a new UDP port? If GPE >>>is a >>> new protocol, why it has to align with VXLAN format? >>> >>> Lucy >>> >>> -----Original Message----- >>> From: nvo3 [mailto:[email protected]] On Behalf Of Fabio Maino >>> Sent: Wednesday, July 16, 2014 5:47 PM >>> To: Dino Farinacci >>> Cc: [email protected] >>> Subject: Re: [nvo3] Comments on >>> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >>> >>> 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. >>> >>> 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). >>> >>> 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. >>> >>> 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 >>> >>> _______________________________________________ >>> 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
