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
