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" <[email protected]> wrote: > > On Sun, Mar 16, 2014 at 2:22 PM, Thomas D Nadeau > <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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:[email protected]] On Behalf Of Thomas D Nadeau >>>> Sent: Sunday, March 16, 2014 9:10 AM >>>> To: Dino Farinacci >>>> Cc: Russ White; <[email protected]>; <[email protected]>; 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 <[email protected]> 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" <[email protected]> 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 >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>> >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/nvo3 >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
