Re: [nvo3] Update on encapsulation design team

[Joe Touch <[e-mail]>]

FWIW, my position was to let each of the encapsulations be augmented as
needed and develop a control solution that was agnostic.

Each of the proposed encapsulations has a design goal, but there is no
rationale for designing this system using a single encapsulation.

Although I appreciate that a single encap is WG "consensus" (at least as
declared by IETF process for "consensus"), that doesn't mean I am
interested in changing my position and participating in its development.

Thanks, but no thanks.

Joe


On 10/21/2016 9:23 AM, Lucy yong wrote:
> Good suggestion. I support!
> Lucy
>
> -----Original Message-----
> From: nvo3 [mailto:[e-mail]] On Behalf Of Behcet Sarikaya
> Sent: Friday, October 21, 2016 10:55 AM
> To: Bocci, Matthew (Nokia - GB); Joe Touch
> Cc: [e-mail]; Tom Herbert; [e-mail]; [e-mail]; Lizhong Jin
> Subject: Re: [nvo3] Update on encapsulation design team
>
> Hi Matthew,
>
> I suggest Joe Touch to be included in the design team.
> I believe he can do a good job.
>
>
> As I had expressed before, I believe there is little need for a next gen encap while the current ones like VXLAN and ILA are in use and people seem to be happy with them?
>
>
> Regards,
>
> Behcet
>
> On Fri, Oct 21, 2016 at 5:04 AM, Bocci, Matthew (Nokia - GB) <[e-mail]> wrote:
>> Lizhong, Tom
>>
>>
>>
>> That is correct. The idea is to pick one of the existing three 
>> encapsulations and enhance it to address the technical concerns that 
>> have been expressed on the list.
>>
>>
>>
>> Those technical issues have already been documented on the list, but 
>> there may be more that emerge as work progresses. I am not sure we 
>> need to write them all up in a separate draft – that was attempted in 
>> the past in the form of the gap analysis draft that did not progress. 
>> I expect the design team to take the technical issues into account and 
>> it would be useful for their draft to explicitly explain them and show how they are addressed.
>>
>>
>>
>> Regards
>>
>>
>>
>> Matthew
>>
>>
>>
>>
>>
>> From: Dacheng Zhang <[e-mail]> on behalf of Lizhong Jin 
>> <[e-mail]>
>> Date: Friday, 21 October 2016 at 07:04
>> To: NVO3 <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>, Tom Herbert 
>> <[e-mail]>, "[e-mail]" <[e-mail]>
>>
>>
>> Subject: Re: [nvo3] Update on encapsulation design team
>>
>>
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3