Dino,
I believe that using a format that can share as much as possible with
the two protocols deployed today will give a better chance to GPE to be
implemented, as vendors may want a cost effective way to migrate to the
new protocol while preserving compatibility with legacy implementations.
The fact that GPE provides a way to be extended, either with a shim a-la
NSH or making availabe more bits in the header for future features, I
think opens up to the addition of new features (explicit service
tagging, as an example) in a more organic way than trying to use the few
bits left in VXLAN or LISP.
Unfortunately, in the LISP case, this comes to the expense of some
features that are in the current specification, but I believe those same
features can be mapped on a GPE+shim header, so a new implementation
would be able to provide the equivalent of those features (e.g. nonce).
It's hard to find the right balance between backward compatibility and
evolution of the encapsulation, but I believe GPE gets to a decent
compromise.
Thanks,
Fabio
On 7/15/14, 4:47 PM, Dino Farinacci wrote:
Hi VXLAN-gpe authors,
Abstract: technically this is not extending a VXLAN but defines a new
protocol that looks similar to VXLAN (demonstrated by need for new UDP
port assignment).
We are trying to balance re-use of the VXLAN format and the need to support
existing non-GPE hardware that might already be deployed. We looked at using
the same port, and the new one, and decided, at this point that a new port is
easier for migration but since the packet format is essentially VXLAN to keep
the VXLAN name.
Paul, this design seems to be going in circles. If a new port is used, why not
make the new port for VXLAN mean layer-3 protocols follow? Or better yet, have
a demux field after the VXLAN header so you don't have to use VXLAN header
bits. Because the P-bit is using a precious bit in the VXLAN/LISP header and
the nonce field that can be used for other things (we have history that shows a
nonce in the header is a cheap form of obscure security).
If you do this then you have no compatibility problems with initial VXLAN and
LISP implementations.
And, most importantly, there will be less confusion in the marketplace.
Dino
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
