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

["Zhou, Han" <[e-mail]>]

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