Hi, So let's face the reality: how to enhance VXLAN with the scarce space left in the header? Extend it with optional fields following the original header? Would it create similar problems of introducing a new protocol?
If the fixed 8 bytes size is still preferred, would it be better that the extension proposals co-work together to make the best use of the header space? E.g. VXLAN-GPE protocol type doesn't really needs 16 bits for the possible 3 (or more in the future, but not that huge) values. Best regards, Han On Tue, 2014-03-18 at 20:32 +0000, AshwoodsmithPeter wrote: > I agree enhancing rather than inventing new is a good idea. For example > CR-LDP did not create a new encapsulation (it is normal MPLS) nor did it > create a new control protocol (its LDP) although it did add some TLV's to LDP > of course for the ERO and QOS. It was a simple idea with very small code > delta over LPD ... ..oh wait .. I guess that's a bad example ;) > > As Dave points out politics is far from impotent here, let's not kid > ourselves. > > Peter > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of David Allan I > Sent: Sunday, March 16, 2014 3:57 PM > To: Thomas D Nadeau; Dino Farinacci > Cc: Russ White; <[email protected]>; <[email protected]>; Lucy > yong; Eric Gray > Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap > > The actual examples cited are artifacts of an industry power structure that > may not apply in this case, as far as past performance predicting future > outcomes.... > > D > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Thomas D Nadeau > Sent: Sunday, March 16, 2014 9:10 AM > To: Dino Farinacci > Cc: Russ White; <[email protected]>; <[email protected]>; Lucy > yong; Eric Gray > Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap > > This road is littered with many examples in recent history of new > alternatives presenting the dream of "a new encap/protocol will fix > everything" such as crldp, PBT and PBB-TE. let's not make this mistake if we > can help it... > > Tom > > > > On Mar 16, 2014, at 11:48, Dino Farinacci <[email protected]> wrote: > > > > Decades of experience tells us what Russ says below. Those who choose to > > ignore are bound to repeat ... > > > > Dino > > > >> On Mar 16, 2014, at 4:12 AM, "Russ White" <[email protected]> wrote: > >> > >> > >>> 3) create a new encapsulation that meets requirements - and find out > >>> that the > >>> industry doesn't entirely switch over to the new (read untried > >>> and > >> possibly > >>> immature) encapsulation, existing deployed alternatives are > >> documented > >>> in > >>> some (possibly non-standard) way and we incur the costs > >>> associated > >> with > >>> living with three alternatives additional encapsulations until > >>> such > >> time (if > >>> ever) > >>> when the DCN industry settles on fewer (possibly as few as one) > >> choices, > >>> and > >>> we move on. > >> > >> This is, in fact, the most likely result... Vendors would need to > >> remove support for the old encaps over time, which isn't going to > >> happen so long as someone is actually using them, which means support > >> will still be in code, which means new people will start using them, which > >> means... > >> > >> There is also a cost in security when it comes to defining new encap > >> types we often don't consider -- it's one more tunnel type that needs > >> to be accounted for by middle boxes, network hardening routines, etc. > >> For every new encap we create, we also create a lot of work in the > >> security world in tracking vulnerabilities, understanding the semantics of > >> the protocol, etc. > >> > >> The right answer, IMHO, is to modify, rather than creating a new encap. > >> > >> :-) > >> > >> Russ > >> > >> _______________________________________________ > >> 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
