On Tue, Oct 4, 2016 at 6:24 PM, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com> 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.
Some points of clarification: The only similarities with Geneve is that they both have variable length headers and have a header length field. GUE does _not_ use TLVs and instead uses flag-fields that are well ordered, compact, and amenable to HW techniques for parsing such as TCAM. As I understand it the answer to extensibility for VXLAN is to use NSH. So then if Geneve and GUE with extensions are compared to VXLAN+NSH then VXLAN+NSH is no less complicated to implement in HW than Geneve and GUE. Conversely, Geneve and GUE be easily used without and extensions so in that mode they are no more complicated to implement in HW than plain VXLAN. I don't think the objection that VXLAN has less complexity in HW implementation than Geneve or GUE has much merit. > - 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. > We can easily extend the the number of flags in GUE the initial 15 bits are allocated (the sixteenth would indicate a field of additional flags). Tom > 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
