Re: [nvo3] Update on encapsulation design team

Good suggestion. I support!
Lucy

-----Original Message-----
From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Friday, October 21, 2016 10:55 AM
To: Bocci, Matthew (Nokia - GB); Joe Touch
Cc: fmaino@cisco.com; Tom Herbert; nvo3@ietf.org; farinacci@gmail.com; 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) <matthew.bocci@nokia.com> 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 <nvo3-bounces@ietf.org> on behalf of Lizhong Jin 
> <lizho.jin@gmail.com>
> Date: Friday, 21 October 2016 at 07:04
> To: NVO3 <nvo3@ietf.org>
> Cc: "fmaino@cisco.com" <fmaino@cisco.com>, Tom Herbert 
> <tom@herbertland.com>, "farinacci@gmail.com" <farinacci@gmail.com>
>
>
> 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 <tom@herbertland.com>
> To: Dino Farinacci <farinacci@gmail.com>
> Cc: Fabio Maino <fmaino@cisco.com>, "nvo3@ietf.org" <nvo3@ietf.org>
> 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 <farinacci@gmail.com>
> 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 <fmaino@cisco.com> 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
>>>>
>>>> nvo3@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
>>>
>>> _______________________________________________
>>> nvo3 mailing list
>>> nvo3@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>> _______________________________________________
>> nvo3 mailing list
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3