Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap

[Dino Farinacci <[e-mail]>]

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" <[e-mail]> 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:[e-mail]] On Behalf Of David Allan I
>> Sent: Sunday, March 16, 2014 3:57 PM
>> To: Thomas D Nadeau; Dino Farinacci
>> Cc: Russ White; <[e-mail]>; <[e-mail]>; 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:[e-mail]] On Behalf Of Thomas D Nadeau
>> Sent: Sunday, March 16, 2014 9:10 AM
>> To: Dino Farinacci
>> Cc: Russ White; <[e-mail]>; <[e-mail]>; 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 <[e-mail]> 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" <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>> 
>>> _______________________________________________
>>> nvo3 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>> 
>> 
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>> 
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>> 
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>