> 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
