Subject: [nvo3] Consensus call on moving forward with a single encap.

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Thu, 21 Jul 2016 14:52:51 +0000

WG
 
There was a discussion in the NVO3 WG meeting in Berlin following strong advice from our Area Director that we need to come to a consensus on converging on a common encapsulation. Two sets of questions were asked:
(1) Should the WG move forward with one standards track encap?
(2) For a given encap, do you have significant technical objections?

This email relates to the first of these questions. Please refer to the separate email titled “Consensus call on encap proposals” for discussion related to point (2).

We would recommend that those not familiar with RFC 7282 "On Consensus and Humming in the IETF" may wish to read it for a fuller understanding of how the IETF handles challenging consensus decisions and why.
 
We took a sense of the room as to how many people thought that we should move forward with one encapsulation on the standards track (we also clarified that this did not mean preventing other encapsulations from being published as informational or experimental). There was strong support in the room for selecting one encapsulation. 

We would like to repeat that question to determine and make a consensus call now on the mailing list.   Please DO NOT use this thread to argue or debate the importance or details of any technical objections that arise.  That can be done in other threads.    Any objections raised will be summarized in an additional email at the end of this consensus call so that the WG can discuss the results in detail.
 
Please respond to this email on the NVO3 list by 29th July 2016:
- Given the IETF's mission, should NVO3 move forward on the standards track with a single encapsulation on the standards track?  If not, please explain your concern in detail.   

Regards

Matthew and Sam

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 21 Jul 2016 22:54:59 -0700

On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia - GB) <
[email-masked]> wrote:
> - Given the IETF's mission, should NVO3 move forward on the standards
> track with a single encapsulation on the standards track?  If not, please
> explain your concern in detail.
>
>
While the world would be a better place with only one encapsulation, I
think it's better to stick with the original path of allowing the 3
encapsulations as experimental.

The NVO3 charter says:
Based on these requirements the WG will select, extend, and/or
develop one or more data plane encapsulation format(s).

Based on the charter, the WG has gone through the process of accepting to
work on 3 encapsulations.  What do we know now that we did not know back
then?

If we were going to progress only a single encapsulation, I think there
would have been more critical feedback and strong suggestions for changing
that "winning" encapsulation to accommodate what the other encapsulations
perceive as their relative strengths.  And we risk opening up that
discussion now and delaying progress even more.

Otherwise, not having a standard has not been a hinderance for getting
protocols deployed in the past, and I suspect that if the developers of
these encapsulations care enough, we will see deployments of all of them
regardless of whether or not we progress them within the working group.

Thanks,
Anoop

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 22 Jul 2016 20:10:52 +0000

+1.

Besides, IETF already has specified many encapsulations, is it really that bad having one extra?

Linda

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Friday, July 22, 2016 7:55 AM
To: Bocci, Matthew (Nokia - GB)
Cc: NVO3
Subject: Re: [nvo3] Consensus call on moving forward with a single encap.

On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

While the world would be a better place with only one encapsulation, I think it's better to stick with the original path of allowing the 3 encapsulations as experimental.

The NVO3 charter says:

Based on the charter, the WG has gone through the process of accepting to work on 3 encapsulations.  What do we know now that we did not know back then?

If we were going to progress only a single encapsulation, I think there would have been more critical feedback and strong suggestions for changing that "winning" encapsulation to accommodate what the other encapsulations perceive as their relative strengths.  And we risk opening up that discussion now and delaying progress even more.

Otherwise, not having a standard has not been a hinderance for getting protocols deployed in the past, and I suspect that if the developers of these encapsulations care enough, we will see deployments of all of them regardless of whether or not we progress them within the working group.

Thanks,
Anoop

---

From: Alia Atlas <[email-masked]>
Date: Sat, 23 Jul 2016 14:59:31 -0400

Please note that the question asked if,  given the IETF's mission to make
the Internet work & work better, what is the correct answer.

I personally do not see that multiple solutions in this space help.   When
one considers the amount of added complexity on top - considers 3x
extensions, 3x work to implement,  and reduced interoperability, and so on.

I should also be clear.   If these drafts were published as Informational
(I don't see any experiment to be run or answered), then there are at least
5 additional aspects that would happen.

  1) Each would contain a paragraph at the start of the document that says
roughly "This document describes an approach considered by the NVO3 Working
Group, but the Working Group was unable to come to consensus on one
approach.  This approach is documented for information here. "

2)No Standards Track work could refer to it.   This would not be a
permitted down-reference.

3) It would be clear that gaining consensus on anything even mildly
contentious is highly unlikely.  I do not see any conflicts plane work
happening.

4) With the exception,  possibly,  of some Standards Track OAM work that
can be commonly used,  there would be nothing left for the Working Group to
do.

5) Considering the lack of progress and discussion on all these drafts,  I
would question whether the drafts will be ready for publication in a
reasonable time-frame.

I would greatly appreciate hearing from more people and specifically
non-authors on this matter.  The consensus in the room was screaming
clear.   I am startled by the difference so far on the mailing list.

I am,  of course,  quite happy & willing to listen to good reasoning on
this matter.

However,  if NVO3 were to have no standards track work to do,  I am quite
likely to close it within the year.

Regards,
Alia

On Jul 22, 2016 9:11 PM, "Linda Dunbar" <[email-masked]> wrote:

+1.

Besides, IETF already has specified many encapsulations, is it really that
bad having one extra?

Linda

*From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Anoop Ghanwani
*Sent:* Friday, July 22, 2016 7:55 AM
*To:* Bocci, Matthew (Nokia - GB)
*Cc:* NVO3
*Subject:* Re: [nvo3] Consensus call on moving forward with a single encap.

Please respond to this email on the NVO3 list by 29th July 2016:
- Given the IETF's mission, should NVO3 move forward on the standards track
with a single encapsulation on the standards track?  If not, please explain
your concern in detail.

The NVO3 charter says:

Thanks,

Anoop

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Anton Ivanov <[email-masked]>
Date: Sat, 23 Jul 2016 22:28:16 +0100

> that bad having one extra?

If what it does can be done by the already existing ones the answer is a 
definitive "Yes it is bad".

-1

A.

> Linda
>
> *From:*nvo3 [mailto:[email-masked]] *On Behalf Of *Anoop Ghanwani
> On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia - GB) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> track with a single encapsulation on the standards track?  If not, 
> please explain your concern in detail.
>
> Based on the charter, the WG has gone through the process of accepting 
> to work on 3 encapsulations.  What do we know now that we did not know 
> back then?
>
> If we were going to progress only a single encapsulation, I think 
> there would have been more critical feedback and strong suggestions 
> for changing that "winning" encapsulation to accommodate what the 
> other encapsulations perceive as their relative strengths.  And we 
> risk opening up that discussion now and delaying progress even more.
>
> protocols deployed in the past, and I suspect that if the developers 
> of these encapsulations care enough, we will see deployments of all of 
> them regardless of whether or not we progress them within the working 
> group.
>
> Thanks,
>
> Anoop
>
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 23 Jul 2016 23:58:17 +0000

Hi, Alia,

Please find one or two questions inline.

On Jul 23, 2016, at 7:59 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Please note that the question asked if,  given the IETF's mission to make the Internet work & work better, what is the correct answer.

I personally do not see that multiple solutions in this space help.   When one considers the amount of added complexity on top - considers 3x extensions, 3x work to implement,  and reduced interoperability, and so on.

I should also be clear.   If these drafts were published as Informational  (I don't see any experiment to be run or answered), then there are at least 5 additional aspects that would happen.

  1) Each would contain a paragraph at the start of the document that says roughly "This document describes an approach considered by the NVO3 Working Group, but the Working Group was unable to come to consensus on one approach.  This approach is documented for information here. "

Just trying to understand — from a process perspective: how does this play with a Charter (i.e., the “contract between a working group and the IETF to perform a set of tasks” [RFC 2418]) that says “one or more data plane encapsulation format(s)”?

2)No Standards Track work could refer to it.   This would not be a permitted down-reference.

Not having heard from a not-permitted down-ref before, I am curious.

I always thought that the downref consensus call belongs in the citing document, not in the cited document. How does this work? Do you have a precedence of a “not be a permitted down-reference”?

3) It would be clear that gaining consensus on anything even mildly contentious is highly unlikely.  I do not see any conflicts plane work happening.

s/conflicts plane/control-plane/ ?

4) With the exception,  possibly,  of some Standards Track OAM work that can be commonly used,  there would be nothing left for the Working Group to do.

5) Considering the lack of progress and discussion on all these drafts,  I would question whether the drafts will be ready for publication in a reasonable time-frame.

You said above “5 additional aspects that would happen”. I’m not clear on this one, what is the aspect that would happen in #5? That you would question it, or something else?

Thanks,

— Carlos.

I would greatly appreciate hearing from more people and specifically non-authors on this matter.  The consensus in the room was screaming clear.   I am startled by the difference so far on the mailing list.

I am,  of course,  quite happy & willing to listen to good reasoning on this matter.

However,  if NVO3 were to have no standards track work to do,  I am quite likely to close it within the year.

Regards,
Alia

On Jul 22, 2016 9:11 PM, "Linda Dunbar" <[email-masked]<mailto:[email-masked]>> wrote:
+1.

Linda

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Anoop Ghanwani
Sent: Friday, July 22, 2016 7:55 AM
To: Bocci, Matthew (Nokia - GB)
Cc: NVO3
Subject: Re: [nvo3] Consensus call on moving forward with a single encap.

The NVO3 charter says:

Thanks,
Anoop

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Alia Atlas <[email-masked]>
Date: Sat, 23 Jul 2016 22:19:13 -0400

Hi Carlos,

On Jul 23, 2016 7:58 PM, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:
>> On Jul 23, 2016, at 7:59 PM, Alia Atlas <[email-masked]> wrote:
>>
>> Please note that the question asked if,  given the IETF's mission to
make the Internet work & work better, what is the correct answer.
>>
>> I personally do not see that multiple solutions in this space help.
When one considers the amount of added complexity on top - considers 3x
extensions, 3x work to implement,  and reduced interoperability, and so on.
>>
>> I should also be clear.   If these drafts were published as
Informational  (I don't see any experiment to be run or answered), then
there are at least 5 additional aspects that would happen.
>>
>>   1) Each would contain a paragraph at the start of the document that
says roughly "This document describes an approach considered by the NVO3
Working Group, but the Working Group was unable to come to consensus on one
approach.  This approach is documented for information here. "
>>
>>
>
> Just trying to understand — from a process perspective: how does this
play with a Charter (i.e., the “contract between a working group and the
IETF to perform a set of tasks” [RFC 2418]) that says “one or more data
plane encapsulation format(s)”?

You are right to ask.   Thanks.
I have been clear from the rechartering that 3 standards track
encapsulations is not ok.   I haven't seen the working group indicate any
ability to have consensus on picking 1 or 2 for Standards  track.  The
charter doesn't specify intended status.

I would also note that the lack of discussion and handling of technical
concerns doesn't really indicate a lot of "working" on the encapsulations.

> I always thought that the downref consensus call belongs in the citing
document, not in the cited document. How does this work? Do you have a
precedence of a “not be a permitted down-reference”?

Yes, but very few documents are acceptable for a down-ref & there are
specific reasons the sponsoring AD feels each is acceptable.   The DownRefs
list is not that large.

As for the precedence,  it goes the other way.   By default,
down-references aren't permitted and each is a special exception for the
referenced document.   This is a loosening of the rules that never
permitted them.

> s/conflicts plane/control-plane/ ?

Yup - the perils of auto-correct on my phone & needing to get out the email
right before the plane took off.

>>
>> 5) Considering the lack of progress and discussion on all these drafts,
I would question whether the drafts will be ready for publication in a
reasonable time-frame.
>>
>>
>
> You said above “5 additional aspects that would happen”. I’m not clear on
this one, what is the aspect that would happen in #5? That you would
question it, or something else?

I am trying to be clear on the consequences of the decision the WG makes.
If this were all to happen in the least desirable way possible, yes, if the
drafts aren't professed in a timely fashion & the WG is closed,  they would
need to find an AD to sponsor them.

There is little interoperability from NVO3 after 5 years.  I am quite
disappointed with the progress of NVO3 - despite the brief period of
significant work after the recharter.

Regards,
Alia

this matter.
>>
>> However,  if NVO3 were to have no standards track work to do,  I am
quite likely to close it within the year.
>>> Based on the charter, the WG has gone through the process of accepting
to work on 3 encapsulations.  What do we know now that we did not know back
then?

---

From: Alia Atlas <[email-masked]>
Date: Sat, 23 Jul 2016 22:28:52 -0400

Hi Carlos,

charter doesn't specify the track;  I've written more charters since then.

The default is to not permit a down-reference.  Exceptions can be made
based upon the Sponsoring ADs support and no objections during IETF Last
Call or by other ADs.  The is a list of the exceptions that have been
permitted in the past.

> s/conflicts plane/control-plane/ ?

Yes - the perils of writing email on my spell-checking  phone right before
the plane took off.

I am trying to explain the consequences of different decisions since I
suspect that some of the process implications aren't clear to all. For #5,
if the work doesn't progress rapidly and the WG is closed before they are
done, the resulting drafts would have to find a Sponsoring AD to progress.

After 5 years, NVO3 is not helping interoperability in this space.  That is
not the point of standardization or the IETF.

Regards,
Alia

this matter.

---

From: Kris Price <[email-masked]>
Date: Wed, 27 Jul 2016 13:36:28 -0700

> There was a discussion in the NVO3 WG meeting in Berlin following strong
> advice from our Area Director that we need to come to a consensus on
> converging on a common encapsulation. Two sets of questions were asked:

I prefer to see (1) the WG moving forward with one standards track
encapsulation.

I think this is the best way for NVo3 to be productive for the majority of
end users, as opposed to whoever finds NVo3 useful at the moment (??).

*OFF TOPIC* please fork the thread if anyone is inclined to reply:

An outsider's observation as someone who stopped following NVo3 a couple of
years back because it didn't seem to be making progress:

There is an embarrassing amount in common between the three drafts, maybe
more than half of each proposal could essentially be identical. The
sticking points perhaps should be pulled out for special consideration in
their own threads, which so far from what I've read seem to be:

1) Extensibility: should it be done? How to do it? With a shim such as NSH?
With reserved flags and a possible version increment when they are used,
that can be determined at a future date. Breaking backwards compatibility.
With fixed-size option headers that are indicated by flags. But with a
header_len field to allow backwards compatibility by simply ignoring all
options. With TLV variable length option headers. But with a header_len
field to allow backwards compatibility by simply ignoring all options.

2) VNI - should it be included, or an option header like GUE?

3) Security of VNI, is it needed, how to do it?

4) Re-usability of existing H/W blocks with minimal modification (in the
case of VXLAN)? Is it really important? I suspect it's not, because frankly
the cost of having to implement three new encapsulations where one has some
re-usability is much greater than the cost of having to implement one new
encapsulation that has no re-usability.

5) Ease of processing in H/W in the case of GUE/GENEVE with their more
complex extensibility mechanisms. I am not qualified to hold an opinion
here, but it seems like VXLAN-GPE is easiest, GUE and GENEVE similar with
GUE probably being slightly easier.

Cheers
Kris

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 30 Jul 2016 19:12:46 -0700

Hello Matthew and nvo3 experts,

> with a single encapsulation on the standards track?  If not, please explain 

no.

I prefer instead the 3 encapsulations are well described in 3 documents, 
including their strength and potentially not-so-strong aspects. These 3 
documents could be all "informal" or all "standard" IMHO.

There is in my opinion no point in making the decision for one encapsulation. 
Supporting multiple encapsulation methods in the control plane is already 
happening. If the market finally decides for one encapsulation method - so be 
it. But this is not for IETF to decide.

Nor do I see any consent - the 3 groups see an advantage in their 
encapsulation for their particular architecture and no simple one-fits-all 
compromise exists. My conclusion is we have 3 valid encapsulations. Save the 
essence of the discussions, so future implementors can pick the right choice.

Regards, Marc