Subject: [nvo3] Consensus call on Encapsulation Design Team recommendation

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wed, 5 Apr 2017 10:00:50 +0000

WG,

During the Thursday NVO3 meeting in Chicago, we tested the sense of the room to see if there was consensus with the encapsulation design team recommendation to move forward with draft-ietf-nvo3-geneve as the standards track encapsulation for NVO3. There was consensus to do so.

We would now like to confirm this on the list.

Do you agree with the recommendation of the encapsulation design team to move forward with draft-ietf-nvo3-geneve as the standards track encapsulation for NVO3?

If so please reply with “I agree”

If you do not agree, please reply with “I do not agree”. Please also state your reasons for not agreeing.

As we have stated before, this process does not prevent the other encapsulations being published as informational or experimental after publication has been requested for the selected standards track encapsulation draft, if there is agreement to do so in the WG.

This consensus call will end on Friday 21st April 2017.

Regards

Matthew

---

From: David Mozes <[email-masked]>
Date: Wed, 5 Apr 2017 10:38:41 +0000

agree

From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, April 05, 2017 1:01 PM
To: NVO3 <[email-masked]>
Subject: [nvo3] Consensus call on Encapsulation Design Team recommendation

WG,

Regards

Matthew

---

From: Tom Herbert <[email-masked]>
Date: Wed, 5 Apr 2017 06:28:48 -0700

On Wed, Apr 5, 2017 at 3:00 AM, Bocci, Matthew (Nokia - GB)
<[email-masked]> wrote:
> WG,
>
>
>
> During the Thursday NVO3 meeting in Chicago, we tested the sense of the room
> to see if there was consensus with the encapsulation design team
> recommendation to move forward with draft-ietf-nvo3-geneve as the standards
> track encapsulation for NVO3. There was consensus to do so.
>
>
>
> Do you agree with the recommendation of the encapsulation design team to
> move forward with draft-ietf-nvo3-geneve as the standards track
> encapsulation for NVO3?
>
>
>
I do not agree

My reasons are that I don't believe that the technical objections for
Geneve raised after the Berlin meeting and elsewhere have been
adequately addressed. In particular, I don't believe that the
extensibility mechanism defined in the draft has been shown to be
viable or deployable.

Thanks,
Tom

>
>
>
> As we have stated before, this process does not prevent the other
> encapsulations being published as informational or experimental after
> publication has been requested for the selected standards track
> encapsulation draft, if there is agreement to do so in the WG.
>
>
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: "T. Sridhar" <[email-masked]>
Date: Wed, 5 Apr 2017 16:40:12 +0000

I agree.

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wednesday, April 5, 2017 at 3:00 AM
To: "[email-masked]" <[email-masked]>
Subject: [nvo3] Consensus call on Encapsulation Design Team recommendation

WG,

Regards

Matthew

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 5 Apr 2017 16:43:07 +0000

Agree.

Linda Dunbar

From: nvo3 [mailto:[email-masked]] On Behalf Of T. Sridhar
Sent: Wednesday, April 05, 2017 11:40 AM
To: Bocci, Matthew (Nokia - GB) <[email-masked]>; NVO3 <[email-masked]>
Subject: Re: [nvo3] Consensus call on Encapsulation Design Team recommendation

I agree.

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 5, 2017 at 3:00 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [nvo3] Consensus call on Encapsulation Design Team recommendation

WG,

Regards

Matthew

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Apr 2017 10:52:58 -0700

"don't care"

I'm concerned about the large number of reserved fields and insufficient
discussion about fragmentation (notably source fragmentation).

Both issues can be addressed if the doc moves forward.

However, because I saw insufficient rationale for any decision, I'm not
prepared to support or block the approach of picking one to move forward.

Joe

On 4/5/2017 3:00 AM, Bocci, Matthew (Nokia - GB) wrote:
>
> WG,
>
>  
>
> During the Thursday NVO3 meeting in Chicago, we tested the sense of
> the room to see if there was consensus with the encapsulation design
> team recommendation to move forward with draft-ietf-nvo3-geneve as the
> standards track encapsulation for NVO3. There was consensus to do so.
>
>  
>
> Do you agree with the recommendation of the encapsulation design team
> to move forward with draft-ietf-nvo3-geneve as the standards track
> encapsulation for NVO3?
>
>  
>
> This consensus call will end on Friday 21^st April 2017.
>
>  
>
> Regards
>
>  
>
> Matthew
>
>
>

---

From: Jon Hudson <[email-masked]>
Date: Wed, 5 Apr 2017 15:12:14 -0700

I agree 

However I would still like to see Tom's concerns addressed

"I don't believe that the technical objections for
Geneve raised after the Berlin meeting and elsewhere have been
adequately addressed. In particular, I don't believe that the
extensibility mechanism defined in the draft has been shown to be
viable or deployable."

> On Apr 5, 2017, at 3:00 AM, Bocci, Matthew (Nokia - GB) <[email-masked]> wrote:
> 
> WG,
>

---

From: Pat Thaler <[email-masked]>
Date: Wed, 5 Apr 2017 16:40:22 -0700

I agree.

On Wed, Apr 5, 2017 at 3:12 PM, Jon Hudson <[email-masked]> wrote:

> During the Thursday NVO3 meeting in Chicago, we tested the sense of the
> room to see if there was consensus with the encapsulation design team

---

From: Eric Gray <[email-masked]>
Date: Thu, 6 Apr 2017 07:17:38 +0000

+1

From: nvo3 [mailto:[email-masked]] On Behalf Of Pat Thaler
Sent: Wednesday, April 05, 2017 7:40 PM
To: Jon Hudson <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; NVO3 <[email-masked]>
Subject: Re: [nvo3] Consensus call on Encapsulation Design Team recommendation

I agree.

On Wed, Apr 5, 2017 at 3:12 PM, Jon Hudson <[email-masked]<mailto:[email-masked]>> wrote:

I agree

On Apr 5, 2017, at 3:00 AM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
WG,

Regards

Matthew
_______________________________________________
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: "Ganga, Ilango S" <[email-masked]>
Date: Fri, 7 Apr 2017 16:54:07 +0000

I agree.

Regards,
Ilango

From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, April 5, 2017 3:01 AM
To: NVO3 <[email-masked]>
Subject: [nvo3] Consensus call on Encapsulation Design Team recommendation

WG,

Regards

Matthew

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Apr 2017 13:20:45 -0500

+1

Regards,

Behcet

On Fri, Apr 7, 2017 at 11:54 AM, Ganga, Ilango S <[email-masked]>
wrote:

> I agree.
>
>
>
> Regards,
>
> Ilango
>
>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Bocci, Matthew
> (Nokia - GB)
> *Sent:* Wednesday, April 5, 2017 3:01 AM
> *To:* NVO3 <[email-masked]>
> *Subject:* [nvo3] Consensus call on Encapsulation Design Team
> recommendation
>
>
>
> WG,
>
>
>

---

From: Fabio Maino <[email-masked]>
Date: Mon, 10 Apr 2017 23:51:41 -0700

I do not agree.

IMO there are at least two areas where draft-ietf-nvo3-geneve-04 does 
not meet the requirements expressed in draft-dt-nvo3-encap, and one area 
where dt-nvo3 seems to over-design flexibility into nvo3 requirements:

1. SECURITY.
The dt-nvo3 draft, in section 6.2.2, indicates VNI spoofing as a 
sensible threat for nvo3 applications.
/Security e.g. of the VNI has not been addressed by / 
/draft-ietf-nvo3-geneve-04. Although an option header could be used for 
security and other extensions, this has not been defined yet and its 
implications on offloading in NICs are not understood./ (this wording is 
taken from the dt-nvo3 draft, although it refers only to another 
candidate encapsulation there).

2. BURDEN FOR HW IMPLEMENTATIONS.
The dt-nvo3 draft states that one of the main design goals is that the 
"DT should specifically avoid a design that is burdensome on hardware 
implementations, but should allow future extensibility". 
Draft-ietf-nvo3-geneve-04 suggests that for HW implementations both the 
overall length of the options field, the number of options, and their 
ordering should be negotiated by the control plane.  IMO this is a 
serious burden for HW implementations, and in practice will limit the 
deployment of geneve options usable by HW implementations to a very 
limited ordered set. HW implementations will have to pay the cost 
associated with the TLV encoding flexibility, but will not really take 
any advantage of that flexibility.

3. OVER-ENGINEERING FLEXIBILITY REQUIREMENTS
This is not an objection to Geneve itself, but rather to the use of 
Geneve to become a mandatory to implement encoding for nvo3 solutions. 
Because of the considerations in point 2, it seems that nvo3 will end up 
specifying a list of Options that must/should be supported (and the 
order in which they should be encoded).
Specifying the needed metadata, rather than include flexible encoding in 
the requirements, is what a  couple of other metadata-rich use cases 
(SFC and in-situ OAM - see draft-brockners-inband-oam-data for the 
latter) have decided to do. In both cases solutions that have been or 
are being implemented (in HW and SW) are supporting a well defined 
ordered set of metadata, without the need to resort to unordered TLV 
encoding. In those two use cases what seemed to be more important is a 
proper definition of the metadata needed for each application. This 
boils down to a much simpler requirement for the encapsulation protocol 
that can just offer extensibility through protocol layering.

Thanks,
Fabio