Re: [nvo3] Update on encapsulation design team

[Alia Atlas <[e-mail]>]

Anoop & Fabiio,

On Mon, Oct 24, 2016 at 2:26 PM, Anoop Ghanwani <[e-mail]>
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 <[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.
>>
>> 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
>>
>
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>