FWIW, my position was to let each of the encapsulations be augmented as needed and develop a control solution that was agnostic.
Each of the proposed encapsulations has a design goal, but there is no rationale for designing this system using a single encapsulation. Although I appreciate that a single encap is WG "consensus" (at least as declared by IETF process for "consensus"), that doesn't mean I am interested in changing my position and participating in its development. Thanks, but no thanks. Joe On 10/21/2016 9:23 AM, Lucy yong wrote: > Good suggestion. I support! > Lucy > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Behcet Sarikaya > Sent: Friday, October 21, 2016 10:55 AM > To: Bocci, Matthew (Nokia - GB); Joe Touch > Cc: [email protected]; Tom Herbert; [email protected]; [email protected]; > Lizhong Jin > Subject: Re: [nvo3] Update on encapsulation design team > > Hi Matthew, > > I suggest Joe Touch to be included in the design team. > I believe he can do a good job. > > > As I had expressed before, I believe there is little need for a next gen > encap while the current ones like VXLAN and ILA are in use and people seem to > be happy with them? > > > Regards, > > Behcet > > On Fri, Oct 21, 2016 at 5:04 AM, Bocci, Matthew (Nokia - GB) > <[email protected]> wrote: >> Lizhong, Tom >> >> >> >> That is correct. The idea is to pick one of the existing three >> encapsulations and enhance it to address the technical concerns that >> have been expressed on the list. >> >> >> >> Those technical issues have already been documented on the list, but >> there may be more that emerge as work progresses. I am not sure we >> need to write them all up in a separate draft – that was attempted in >> the past in the form of the gap analysis draft that did not progress. >> I expect the design team to take the technical issues into account and >> it would be useful for their draft to explicitly explain them and show how >> they are addressed. >> >> >> >> Regards >> >> >> >> Matthew >> >> >> >> >> >> From: Dacheng Zhang <[email protected]> on behalf of Lizhong Jin >> <[email protected]> >> Date: Friday, 21 October 2016 at 07:04 >> To: NVO3 <[email protected]> >> Cc: "[email protected]" <[email protected]>, Tom Herbert >> <[email protected]>, "[email protected]" <[email protected]> >> >> >> Subject: Re: [nvo3] Update on encapsulation design team >> >> >> >> 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 >> > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
