I agree with Fabio. Choosing a single encapsulation that is not 1 of the 3, creates a 4th one that no one wants.
And guess what, you make all 3 authors unhappy where none of them will endorse (or implement) the 4th one. Dino > On Oct 20, 2016, at 12:02 PM, Fabio Maino <[email protected]> wrote: > > (for full disclosure I'm one of the authors of VXLAN-GPE) > > Matt, Sam, Alia, > I've expressed multiple times and in multiple venues my adversity (and the > motivations) to set this group to design yet another encapsulation. I won't > repeat it here once again, but I want to re-assert that it's still were I > stand. > > I've seen quite a few people in the mailing list here expressing similar > concerns, but I see that it has not changed the opinion of the chairs and the > AD on what they believe is the best way to move forward. > > That said, here are my comments to the charter. > > I think the design team first goal should be to clearly articulate the > shortcomings of the current encapsulations proposed to the WG. This should be > the very first deliverable of the design team. The actual design work should > start only once the WG has reached consensus on that document. Especially > considering that some of the encapsulations proposed are being deployed, I > think articulating the shortcomings will help to make the best choice in term > of (1) selecting which one will need to be extended, and (2) designing the > actual extensions. > > Below are my proposals on how to modify the wording of the charter. > > > > On 10/20/16 1:37 AM, Bocci, Matthew (Nokia - GB) wrote: >> WG, >> >> We would like to give you an update on the process in the WG for progressing >> the issue of a data plane encapsulation. The chairs and Alia believe that >> the best way forward is to progress a single encapsulation format that >> addresses the technical concerns raised on the list in the recent >> discussions. This would address the clear overall consensus of the Berlin >> meeting and list for a single encapsulation. >> >> The strategy should be to take one of the three existing encapsulations and >> enhance it to address these concerns. This would become the standards track >> output of the WG. The existing three drafts (GENEVE, GUE and VXLAN-GPE) >> should be forwarded to the IESG as informational after the standards track >> draft specifying the single encapsulation. This provides an opportunity for >> those encapsulations to be documented and maintained. >> >> The single encapsulation should be viewed as one that the WG and industry >> can converge around for the future. >> >> We have created a design team to progress work on a single encapsulation >> that can form the basis or work going forward. The design team members are: >> Michael Schmidt, Uri Elzur, Ilango Ganga, Erik Nordmark, Rajeev Manur, >> Prankaj Garg. Many thanks to these individuals for their help. >> >> Please see below for a draft charter for the design team. Please review the >> charter and send comments to the list by 2nd November 2016. >> >> Regards, >> >> Matthew and Sam >> >> >> ==== >> NVO3 Encapsulation Design team 2016 >> >> Problem Statement >> The NVO3 WG charter states that it may produce requirements for network >> virtualization data planes based on encapsulation of virtual network traffic >> over an IP-based underlay data plane. Such requirements should consider OAM >> and security. Based on these requirements the WG will select, extend, and/or >> develop one or more data plane encapsulation format(s). >> >> This has led to drafts describing three encapsulations being adopted by the >> working group: >> - draft-ietf-nvo3-geneve-03 >> - draft-ietf-nvo3-gue-04 >> - draft-ietf-nvo3-vxlan-gpe-02 >> >> Discussion on the list and in face-to-face meetings has identified a number >> of technical problems with each of these encapsulations. Furthermore, there >> was clear consensus at the IETF meeting in Berlin that it is undesirable for >> the working group to progress more than one data plane encapsulation. >> Although consensus could not be reached on the list, the overall consensus >> was for a single encapsulation (RFC2418, Section 3.3). Nonetheless there has >> been resistance to converging on a single encapsulation format, although >> doing so would provide the best benefit to the industry. > > The portion of the last sentence that follows the comma ("although doing so > would provide the best benefit to the industry") doesn't seem to be adding > anything to the charter. I'd suggest it could be removed. > >> >> Design Team Goals > The design team should clearly articulate in a draft which are the > shortcomings of the proposed encapsulations, and where they fall short in > addressing the NVO3 architectural requirements. > > Once the 'shortcomings' draft has reached consensus of the WG, >> The design team should take one of the proposed encapsulations and enhance >> it to address the technical concerns. >> Backwards compatibility with the chosen encapsulation and the simple >> evolution of deployed networks as well as applicability to all locations in >> the NVO3 architecture > , together with the design goals articulated in the 'shortcoming' draft, > >> are goals. The DT should specifically avoid a design that is burdensome on >> hardware implementations, but should allow future extensibility. The chosen >> design should also operate well with ICMP and in ECMP environments. If >> further extensibility is required, then it should be done in such a manner >> that it does not require the consent of an entity outside of the IETF. >> >> Timeline >> The design team should > first produce the 'shortcomings' draft, get it adopted by the WG, and then > >> produce a first draft describing the proposal by end of January 2017. Target >> adoption by the WG by March 2017 IETF. >> > (those two dates may need to be adjusted accordingly) > > > Thanks, > Fabio > >> >> >> >> >> >> >> _______________________________________________ >> 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
