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

[Tom Herbert <[e-mail]>]

On Sun, Mar 16, 2014 at 2:22 PM, Thomas D Nadeau
<[e-mail]> wrote:
> that's kind of what you and russ were saying (and I agreeing): iteration, evolution and refinement have often proven better than revolution.
>
Iteration, evolution, and refinement are key and in fact this is
precisely a core rationale in GUE and geneve. We need the ability to
scale and adapt the data center to changing needs and threats, this is
the requirement. This translates into a requirement for extensible
protocols that we can modify and evolve as needed and in short
turnaround time.

The example that I give in security: what if next week the latest
Snowden revelations expose some security hole in our data center-- if
this hole can be addressed by adding a token to my packets, then I
want to guarantee I retain the capability to do this. It's not
acceptable that I'd have to go back to standards to change this, and
neither is swapping out new hardware just because I extended a
protocol.

I agree that modifying existing protocols would be the best direction
but that is going to require a real proposal which we can measure
against (no one has suggested a reasonable alternative). In lieu of
modifying an existing protocol, developing a a new one based on known
techniques and mechanisms is prudent.

Tom

> Tom
>
>
>> On Mar 16, 2014, at 15:59, Dino Farinacci <[e-mail]> 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 <[e-mail]> 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:[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