Re: [nvo3] Update on encapsulation design team

[Anoop Ghanwani <[e-mail]>]

Hi Alia,

Ideally I would rather not go there at all as expressed in the first part
of Fabio's note.  Assuming we must go there, having a section that
documents why the WG thought we needed a new one would be good enough for
me.

Anoop

On Mon, Oct 24, 2016 at 11:46 AM, Alia Atlas <[e-mail]> wrote:

> Hi Anoop,
>
> On Mon, Oct 24, 2016 at 2:43 PM, Anoop Ghanwani <[e-mail]>
> 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 <[e-mail]> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>
>