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

Tom

There are 2 drafts that propose changes to VXLAN and NVGRE. Is there any requirements that is not addressed by those drafts? 

Regards,
Shahram

> On Mar 16, 2014, at 3:24 PM, "Tom Herbert" <therbert@google.com> wrote:
> 
> On Sun, Mar 16, 2014 at 2:22 PM, Thomas D Nadeau
> <tnadeau@lucidvision.com> 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 <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
>> 
>> _______________________________________________
>> 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