Tom, we'll see what the design team comes up with. Dino
> On Oct 20, 2016, at 12:35 PM, Tom Herbert <[email protected]> wrote: > > On Thu, Oct 20, 2016 at 12:10 PM, Dino Farinacci <[email protected]> wrote: >> 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. >> > My $0.02: That's not the way I read Matthew's message. It seems like > the conclusion to the technical objections query is that objections > were raised for all three protocols and so none of them were ready for > standardization. The goal of the design team seems to be to start with > one, presumably the one with the fewest issues, and enhance it to > answer all the technical objections with an effort to maintain > backwards compatibility for that protocol. This might essentially be a > method of picking one as I believe you proposed earlier. > > Tom > >> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
