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

On Mar 16, 2014 6:12 PM, "Shahram Davari" <davari@broadcom.com> wrote:
>
> Tom
>
> There are 2 drafts that propose changes to VXLAN and NVGRE. Is there any
requirements that is not addressed by those drafts?
>

Which drafts are you referring to?

> 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