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
