VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC
provides guidance for. I.e. given the anticipated interpretations, with
proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow for
best backwards interoperability on the existing UDP 4789 and offer best
prospects for carrying the additional headers/metadata. This leads to the
need for new UDP port for new formats
Thx
Uri ("Oo-Ree")
C: (949)-378-7568
-----Original Message-----
From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong
Sent: Wednesday, July 16, 2014 4:00 PM
To: Fabio Maino; Dino Farinacci
Cc: [email protected]
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is a
new protocol, why it has to align with VXLAN format?
Lucy
-----Original Message-----
From: nvo3 [mailto:[email protected]] On Behalf Of Fabio Maino
Sent: Wednesday, July 16, 2014 5:47 PM
To: Dino Farinacci
Cc: [email protected]
Subject: Re: [nvo3] Comments on
http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
Dino,
GPE is not changing VXLAN nor LISP, as today's implementations cannot be
changed. GPE is proposing a converged extension of both protocols that
add some new features that, I believe, are needed.
All of VXLAN features are supported in GPE.
In the case of LISP, unfortunately, two features (nonce and
map-versioning) could not be accommodated in GPE. This is not very
different than any of today's LISP implementations that may decide to not
support those two features (for whatever reason: cost, complexity, use
cases addressed by the implementation... independently from GPE).
What GPE is trying to do is to simplify next generation implementations
by keeping GPE as close as possible to the existing encapsulations,
adding on top of those. I maintain that an implementation supporting GPE,
LISP and VXLAN will be more cost effective than one that supports VXLAN,
LISP and a clean slate protocol, and may have better chances of being
deployed.
Fabio
On 7/16/14, 1:05 PM, Dino Farinacci wrote:
Well, if you want to really care about customers, creating all these
variations is not doing justice to them. If you want less combinations,
you keep VXLAN the way it is right now, with no changes. You keep LISP
the way it is right now with no changes. You get L2 and L3 overlays with
a unified pull control-plane in draft-maino-nv03-lisp-cp (preaching to
the author ;-) or use BGP as an alternative push control-plane.
As for NSH, you create a new header because it is completely new
requirement and has not be deployed anywhere. Since it is brand new, you
need new hardware and code to be developed to support it. So changing
VXLAN and LISP to support NSH doesn't make sense because you inject
change in 3 places rather than in 1 new place, creating more protocol
machinery, complexity, and combinations that will frustrate customers
(not to mention vendor call centers).
Less entropy please,
Dino
On Jul 15, 2014, at 10:51 PM, Fabio Maino <[email protected]> wrote:
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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
