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
