I agree enhancing rather than inventing new is a good idea. For example CR-LDP did not create a new encapsulation (it is normal MPLS) nor did it create a new control protocol (its LDP) although it did add some TLV's to LDP of course for the ERO and QOS. It was a simple idea with very small code delta over LPD ... ..oh wait .. I guess that's a bad example ;)
As Dave points out politics is far from impotent here, let's not kid ourselves. Peter -----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of David Allan I Sent: Sunday, March 16, 2014 3:57 PM To: Thomas D Nadeau; Dino Farinacci Cc: Russ White; <[email protected]>; <[email protected]>; Lucy yong; Eric Gray Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap 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
