Dino & WG, Please take a read through RFC3929. Officially, there needs to be a consensus call by the WG asking the AD to make a decision.
Regards, Alia On Tue, Oct 4, 2016 at 3:29 PM, Dino Farinacci <[email protected]> wrote: > > 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
