Re: [nvo3] Update on encapsulation design team

[Tom Herbert <[e-mail]>]

On Mon, Oct 24, 2016 at 12:54 PM, Fabio Maino <[e-mail]> wrote:
>
> I think it will be useful for the design team to articulate clearly and
> motivate those objections, and present it to the WG for formal discussion
> BEFORE starting the new design. That should help consolidate the
> requirements for the design of the new encap.
>
> A separate technical document will help  evaluate in depth the objections
> raised, rather than rely on hundreds of emails and their different
> interpretation.
>
> I think I have seen quite a lot of disagreement around the objection
> themselves.
>
> For example, wrt GPE extensibility the summary reported that
>
> "- GPE is insufficiently extensible. Numerous extensions and options have
> been designed for GUE and Geneve. Note that these have not yet been
> validated by the WG."
>
> That assertion seems to ignore (as it has been pointed out multiple time in
> the mailing list) what has been done with NSH, or other proposed  encodings
> for carrying metadata with VXLAN-GPE such as:
> https://tools.ietf.org/html/draft-ietf-sfc-nsh-10
> https://tools.ietf.org/html/draft-brockners-inband-oam-data
>
> I would like the WG to articulate why, from a technical point of view,
> proper layering can't be used to extend GPE (as recommended by the GPE draft
> itself), as it is certainly possible (and done) in the two drafts indicated
> above.
>
> Same goes for the security objection to GPE.
>
Fabio,

I disagree that the question of extensibility is adequately answered
in VXLAN-GPE by just referring to NSH. Reasons are:

1) There is no proposal or real example of what an extension for nvo3
encapsulation would actually look like. I have asked many times that
VXLAN-GPE authors provide something, for instance an example of a
security token, but to date nothing specific has been produced. I have
a similar issue with Geneve since they have not formally proposed any
extensions, but at list it is clear in Geneve what the format and
general processing of extensions would be.

2) If we accept that NSH is the answer to extensibility in VXLAN-GPE
then we need to amend the technical objections. in particular, there
were technical objections raised for Geneve and GUE that they were
more complex than VXLAN-GPE because of the extensibility mechanism. If
NSH is considered part of VLXAN-GPE then we also need to consider the
feasibility of using NSH in an NV environment and answer questions
around hardware friendliness, susceptibility to DDOS, etc. Again,
without any sample extensions or specification of how this works with
VXLAN_GPE the merits of extensibility seem really hard to evaluate.

Thanks,
Tom

> I'm quite sure the authors of the other two proposals have similar view on
> the objections raised to their proposals.
>
> A separate document, in my opinion, would help understanding what needs to
> be addressed before we start with the new design.
>
>
> Thanks,
> Fabio
>
>
> On 10/24/16 12:51 PM, Anoop Ghanwani wrote:
>
> 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
>>>>>
>>>>
>>>
>>
>
>
>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3
>