You said nothing about making a decision. I propose a decision be announced at Seoul IETF.
Dino > On Oct 4, 2016, at 2:24 AM, Bocci, Matthew (Nokia - GB) > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
