I get the similar understanding from Tom. But I am not confident with the timeline, hope will not be delayed.
Regards Lizhong ---------- Forwarded message ---------- > From: Tom Herbert <[email protected]> > To: Dino Farinacci <[email protected]> > Cc: Fabio Maino <[email protected]>, "[email protected]" <[email protected]> > Date: Thu, 20 Oct 2016 12:35:40 -0700 > Subject: Re: [nvo3] Update on encapsulation design team > 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
