> On Aug 5, 2016, at 8:01 AM, Dino Farinacci <[email protected]> wrote: > >> 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. > > In practice, there really isn’t historical baggage. And if you build > something to last 10 years and think it won’t change, having options in the > header is good.
I think that if you look at the header layout for VXLAN-GPE (as a further evolution from LISP->VXLAN->VXLAN-GPE) without knowing the historical context, most people would find it a bit odd. In particular, I’ve heard numerous people ask why the ‘I’ bit must be set in VXLAN. These types of issues cause confusion, introduce undefined error states into the protocol, and waste bits in the header. You can argue about whether carrying this legacy forward was a worthwhile tradeoff but it’s clear that there is historical baggage. > But changing to a different protocol all together and having different > options in one protocol IS exactly the same result. THERE ARE CHANGES for the > vendor and the deployer. I don’t agree that the impact from all changes is the same. After all, the stated reason for extending existing header formats is to reduce test and implementation cost. To me, the best way to achieve this is to have a protocol that has a well defined structure that enables incremental extensions while sharing core functionality. In the immediate term this might be a bigger change but over the long term, I believe that it will result in less complexity, and yes, less cost. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
