On 7/27/16 10:53 AM, Tom Herbert wrote:
On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci <[email protected]> wrote:
On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) <[email protected]> wrote:
On 7/26/16 12:08 PM, Dino Farinacci wrote:
Having VXLAN as an Independent Stream RFC gives a document to be used to
innovate from. I believe that was the intent of VXLAN-GPE - to provide the
ability
for needed extensions.
The only new feature the VXLAN-GPE brings to the table is a way to identify
that NSH is being encapsulated.
or any other shim header, NSH just happens to be one.
Precisely. GPE addresses the limitation associated with VXLAN, namely the lack
of multi-protocol support. As we've seen on the list, other protocols have
come up: MPLS for example.
This is technically not true. As long as you are willing to spend 14 bytes on a
MAC header, then anything with an ethertype can be encapsulated with VXLAN.
And I have working code that encapsulates both IPv4 and IPv6 in VXLAN with
ethertypes 0x0800 and 0x86dd, respectively.
There are some other technical benefits as well: version and OAM.
As do Geneve and GUE. But this thread is not about touting the
features of these protocols, it is about the technical objections to
them. My major objections (from the list I posted) to VXLAN-GPE is
that it has no extensibility and offers no security of the VNI. These
are showstoppers in my deployment.
Tom,
extensibility is achieved via shim header:
- if you want to carry end to end metadata you can define the
appropriate shim header
- If you want to protect the integrity of the VNI, you can include an
HMAC of the VNI in the shim header
IMO NSH is proof that the functionality of VXLAN-GPE can be extended
pretty far.
Fabio
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
