Actually recomposing the VXLAN/LISP splitting was another design goal of
VXLAN-GPE. A VXLAN-GPE implementation can share most of its code with a
LISP implementation, contributing to the reduction of test and
implementation cost.
Fabio
On 8/5/16 9:21 AM, Jesse Gross wrote:
On Aug 5, 2016, at 8:01 AM, Dino Farinacci <farina...@gmail.com> 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
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
