Re: [nvo3] Update on encapsulation design team

[Lizhong Jin <[e-mail]>]

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 <[e-mail]>
> To: Dino Farinacci <[e-mail]>
> Cc: Fabio Maino <[e-mail]>, "[e-mail]" <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]> 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
> >>>
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/nvo3
> >>
> >>
> >> _______________________________________________
> >> nvo3 mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/nvo3
> >
> > _______________________________________________
> > nvo3 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>