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

that's kind of what you and russ were saying (and I agreeing): iteration, evolution and refinement have often proven better than revolution.

Tom 

> On Mar 16, 2014, at 15:59, Dino Farinacci <farinacci@gmail.com> wrote:
> 
> Maybe the power struggle should not focus so much on WHAT is delivered but HOW it is developed and delivered. 
> 
> A thought offered to me recently from a close friend. 
> 
> Dino
> 
>> On Mar 16, 2014, at 12:56 PM, David Allan I <david.i.allan@ericsson.com> wrote:
>> 
>> 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:nvo3-bounces@ietf.org] On Behalf Of Thomas D Nadeau
>> Sent: Sunday, March 16, 2014 9:10 AM
>> To: Dino Farinacci
>> Cc: Russ White; <draft-gross-geneve@tools.ietf.org>; <nvo3@ietf.org>; 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 <farinacci@gmail.com> 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" <russw@riw.us> 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
>>>> nvo3@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>> 
>>> _______________________________________________
>>> nvo3 mailing list
>>> nvo3@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nvo3
>> 
>> _______________________________________________
>> nvo3 mailing list
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
> 