You don't need more header space for service chaining. An EID can identify a service. And you can assign as many as you want to a physical or virtual system. And EIDs could even be IPv6 addresses where there are plenty of bits to encode all sorts if things.
Dino > On Mar 18, 2014, at 7:41 PM, "Zhou, Han" <[email protected]> wrote: > > 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
