> On Aug 4, 2016, at 5:53 PM, Fabio Maino <[email protected]> wrote: > Tom, > it's more than just infeasibility that should be considered as part of the > technical evaluation, but also the cost/complexity associated with > implementations. > > Encapsulations are not implemented in a vacuum, but compete with other > features for resources available in a given platform. VXLAN-GPE was designed > to be a superset of VXLAN. VXLAN happens to exist as a legacy encapsulation > and will likely be around for quite some time. An implementation of VXLAN-GPE > makes a more efficient use of resources on platforms that need also to > support VXLAN (that to my knowledge are a very significant chunk of the > implementations out there). This is particularly true for fixed-functions > ASICs, but I think it stands true for other platforms as well when you > consider the cost/complexity of verification and testing. > > Then there's the cost/complexity associated with the transport of metadata. I > think that a parser for a fixed length portion of a header with an ordered > set of metadata can be implemented with less cost/complexity than a parser > for a variable length header where metadata can appear in any order. This is > particularly evident in fixed-function ASICs. IMO, a mandatory to implement > encapsulation, shouldn't force implementations to deal with variable length > unordered sets of metadata.
The problem is, as you say, this particular encapsulation isn’t implemented in a vacuum. Given the number of variations and extensions that already exist for VXLAN, I think it’s pretty safe to say that things will continue to evolve. Going down the path that you are proposing here would almost certainly mean having several different protocols in the future with different interpretations and possibly lengths. It’s not obvious to me that this is preferable to having a single, extensible protocol from an implementation complexity or testing point of view. In addition, while you are trying to optimize for one particular implementation and architecture, the long term results of these decisions tend to impact many more platforms than the original one. For example, VXLAN was derived from LISP with the same goals as you are describing here. However, I suspect that many of the platforms that now implement VXLAN never had LISP support in the first place. These implementations must now carry the historical baggage so from a global perspective this did not turn out to be an optimization after all. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
