Matthew, Sam,
as it was mentioned in other posts some of the encapsulations you list
below are implemented and being deployed as we speak.
We have an opportunity to learn, from those real life deployments, what
are the requirements that needs to be addressed, especially with regard
to how much extensibility is necessary and what kind of metadata might
be needed.
I think we should take advantage of that opportunity, and I don't see as
detrimental that the WG is not going to select or, worst, start afresh
the design of a single encapsulation. Control planes will eventually
"adapt" the data path differences.
Given that we are seeing those encaps in various implementation, it
would make sense to document them as informational RFC. As an author of
VXLAN-GPE, I would certainly be happy to work toward that end.
Is there an action that the WG should take to make that happen? Or is it
left to the initiative of the authors?
Thanks,
Fabio
On 10/4/16 2:24 AM, Bocci, Matthew (Nokia - GB) wrote:
Folks,
Following the lengthy discussion on this list about the pros and cons of the
three encapsulation formats, we would like to summarise where the main points
of the discussion and to provide some thoughts on next steps.
As a reminder, the question that we asked was: For a given encap, do you have
significant technical objections?
Thank you for the lively discussion. We have summarised the key points for each
draft as follows:
Geneve
----------
- Can’t be implemented cost-effectively in all use cases because variable
length header and order of the TLVs makes is costly (in terms of number of
gates) to implement in hardware
- Fork-lift upgrade from widely deployed VXLAN (no backwards compatibility
mechanisms)
- Header doesn’t fit into largest commonly available parse buffer (256 bytes in
NIC). Cannot justify doubling buffer size unless it is mandatory for hardware
to process additional option fields.
GUE
----------
- There were a significant number of objections related to the complexity of
implementation in hardware, similar to those noted for Geneve above.
- In addition, there were concerns raised that GUE does not support a
sufficient number of extensions due to its reliance on a limited flags field,
which is already almost 45% allocated.
VXLAN-GPE
----------
- GPE is not day-1 backwards compatible with VXLAN. Although the frame format
is similar, it uses a different UDP port, so would require changes to existing
implementations even if the rest of the GPE frame is the same.
- GPE is insufficiently extensible. Numerous extensions and options have been
designed for GUE and Geneve. Note that these have not yet been validated by the
WG.
- Security e.g. of the VNI has not been addressed by GPE. Although a shim
header could be used for security and other extensions, this has not been
defined yet and its implications on offloading in NICs are not understood.
Unfortunately, no rough consensus emerged from the list discussion.
The chairs and our AD have also been trying to form a design team to take
forward the encapsulation discussion and see if there is potential to design a
common encapsulation. However, there has been insufficient interest in this
initiative. We would like to hear opinions and confirmation or disagreement on
interest in creating a DP encapsulation that addresses the various technical
concerns.
For the upcoming Seoul IETF, we propose that we will put aside the discussion
of specific encapsulations and focus on control plane and OAM. In particular,
the chairs feel there was insufficient discussion of the impact of a software
solution that implements some or all of the potential options/extensions
allowed by e.g. Geneve on all elements of the NVO3 architecture. We would like
the working group to consider more carefully the implications of different
encapsulations in real environments consisting of both software and hardware
implementations and spanning multiple data centers. For example, OAM functions
such as path MTU discovery become challenging with multiple encapsulations
along the data path. We would like to encourage solid reviews of the three
proposals on the list, particularly how they would work in the general
architecture.
With this in mind, we are also considering holding a virtual interim meeting
the week of 24th October. More details will follow.
We would like to start a conversation within the WG about what functionality the WG
should focus on and standardize. What do you think should be easy to do? What
would be incredibly useful? What, if not done, risks causing harm to the industry?
The start of this discussion of WG direction will occur on the mailing list and in
the virtual interim."
Best regards
Matthew and Sam
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
