Thanks, Greg, noted. -sam
On Tue, Oct 4, 2016 at 4:04 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > Dear Matthew, Sam, et. al, > I think that concentrating on the proposal to "focus on control plane and > OAM" we can achieve practical results despite differences among data plane > encapsulations. Please count me in. > > Regards, Greg > > On Tue, Oct 4, 2016 at 2:24 AM, 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. >> - 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 > >
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
