Hi Anoop, On Mon, Oct 24, 2016 at 2:43 PM, Anoop Ghanwani <[email protected]> wrote:
> Alia, > > I think it will provide an official reference which will be helpful since > all the encaps will be around a long time and we can point people to that > document when we are asked the question "why did they develop yet another > encap?". > So what you are asking for is a section in the overall draft that talks about the motivations and improvements? There's a trade-off of speed and getting a solution done versus doing process work for a theoretical future that won't happen if we don't get the technical work finished. Regards, Alia > Thanks, > Anoop > > On Mon, Oct 24, 2016 at 11:30 AM, Alia Atlas <[email protected]> wrote: > >> Anoop & Fabiio, >> >> On Mon, Oct 24, 2016 at 2:26 PM, Anoop Ghanwani <[email protected]> >> wrote: >> >>> Agree with Fabio (including the suggestion for an interim deliverable on >>> shortcomings). If the WG doesn't agree on the shortcomings, chances are >>> they may not like the 4th encap. >>> >> >> What do you expect to be different from the summary of technical >> objections that came out of the last discussion? Are you looking for more >> detail? >> >> I didn't see disagreement about the accuracy of the technical objections. >> >> Regards, >> Alia >> >> >>> Anoop >>> >>> 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. >>>> >>>> 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
