Subject: Re: [nvo3] Update on encapsulation design team

From: Lizhong Jin <[email-masked]>
Date: Fri, 21 Oct 2016 14:04:21 +0800

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 <[email-masked]>
> To: Dino Farinacci <[email-masked]>
> Cc: Fabio Maino <[email-masked]>, "[email-masked]" <[email-masked]>
> 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 <[email-masked]>
> 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 <[email-masked]> 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
> >>>
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/nvo3
> >>
> >>
> >> _______________________________________________
> >> nvo3 mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/nvo3
> >
> > _______________________________________________
> > nvo3 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Fri, 21 Oct 2016 10:04:16 +0000

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 <[email-masked]> on behalf of Lizhong Jin <[email-masked]>
Date: Friday, 21 October 2016 at 07:04
To: NVO3 <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Tom Herbert <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>
To: Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Cc: Fabio Maino <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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.
>

Tom

> Dino
>
>> On Oct 20, 2016, at 12:02 PM, Fabio Maino <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> 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.
>>
>> 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.
>>
>>> 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
>>>
>>>
>>> ====
>>> 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:
>>> 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.
>>
>>> 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
>>> 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.
>>>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 21 Oct 2016 10:55:11 -0500

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)
<[email-masked]> 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
>
>
>
>
>
> Cc: "[email-masked]" <[email-masked]>, Tom Herbert
> <[email-masked]>, "[email-masked]" <[email-masked]>
>
>
>>> 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.
>>>
>>>> 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.
>>>>
>>>> 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
>>>>
>>>>
>>>> ====
>>>> 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).
>>>>
>>>> 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
>>> 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
>>>> 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

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Oct 2016 16:23:42 +0000

Good suggestion. I support!
Lucy

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Friday, October 21, 2016 10:55 AM
To: Bocci, Matthew (Nokia - GB); Joe Touch
Cc: [email-masked]; Tom Herbert; [email-masked]; [email-masked]; Lizhong Jin
Subject: Re: [nvo3] Update on encapsulation design team

Hi Matthew,

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) <[email-masked]> wrote:
> 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
>
>
>
>
>
> Subject: Re: [nvo3] Update on encapsulation design team On Thu, Oct 
> 20, 2016 at 12:10 PM, Dino Farinacci <[email-masked]>
> wrote:
>> I agree with Fabio.
>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>> 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.
>>>>
>>>> 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 
>>>> provides an opportunity for those encapsulations to be documented and maintained.
>>>>
>>>> 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.
>>>>
>>>> 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).
>>>>
>>>> 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).
>>>> encapsulation format, although doing so would provide the best 
>>>> benefit to the industry.
>>>
>>> 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
>>> shortcomings of the proposed encapsulations, and where they fall 
>>> short in addressing the NVO3 architectural requirements.
>>>
>>>> Backwards compatibility with the chosen encapsulation and the 
>>>> simple evolution of deployed networks as well as applicability to 
>>>> all locations in the NVO3 architecture
>>>> 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

---

From: Joe Touch <[email-masked]>
Date: Sun, 30 Oct 2016 16:35:00 -0700

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