> Dino, > > On Tue, Oct 4, 2016 at 2:24 PM, Dino Farinacci <[email protected]> wrote: > You said nothing about making a decision. I propose a decision be announced > at Seoul IETF. > > Which decision are you looking for? Flip a coin & pick one?
Pick one. Based on the description text it sounds like one is in favor but the decision has been made explicitly. > Picking an encapsulation despite the technical objections on both sides will > split the market and affect interoperability. No it won’t. There will be a IETF endorsed encapsulation and then the market will decide which way to go if vendors do more than the IETF endorsed mechanism. > Depending on how much you believe the deployment and key features will be in > software or hardware seriously affects > the arguments. Yes, that is true. But having said that, THE WG MUST MAKE A DECISION. > I have been trying to see if there could be agreement for a design team to > get a solution that takes the objections into It’s too late for that. Discussion had been made by many people and nothing new would come out. Way prolong the inevitable. Make a decision and let’s move on to the control plane. > account and produces something. I have heard from some that they "don't > think it is time for a standard and we should > just provide high quality documentation"; since standards is what the IETF > does, I'm not clear on what the proposed goal > would be otherwise. If you don’t decide that VXLAN will remain defacto. And people will think it is the “standard” since its in RFC form. That is how customers think. So if you want the WG to have *some* impact on the industry, decide. > By having a solid and thoughtful conversation about the impact of different > encapsulations (and support for different aspects) > connected to the many cases in the NVO3 architecture, I am hoping to get a > more nuanced and thoughtful understanding > of the issues. We have done that already. We are beating a dead horse, as to speak. Dino > > Regards, > Alia > > 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 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
