Subject: [Tsv-art] Tsvart early review of draft-ietf-nvo3-geneve-08

From: David Black <[email-masked]>
Date: Fri, 09 Nov 2018 21:23:51 -0800

Reviewer: David Black
Review result: On the Right Track

This document has been reviewed as part of the transport area review team's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors and WG to 
allow them to address any issues raised and also to the IETF discussion list for 
information. 

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please
always CC [email-masked] if you reply to or forward this review.

I need to start by disclosing a potential conflict of interest - my employer (Dell EMC)
and VMware are both part of Dell Technologies and my job responsibilities include
working with VMware.  I don't believe that this situation affects the content of this
review.

On its own, the Geneve encapsulation protocol design looks reasonably good and solid.
The draft is well-written and provides significant useful design rationale to explain the
Geneve design in addition to its specification of Geneve.

This review focuses on concerns that arise in interactions with IP networks.  As this is
an early review, it mostly points out areas where additional work is needed without
providing all the details of what should be done.  I'm willing to work with the draft 
authors and the nvo3 WG to address these concerns, and regret that other demands on
my time prevented completion of this review before the Bangkok IETF meeting week.

[1] UDP Requirements.  Geneve uses UDP, but this draft does not reference RFC 8085 on
UDP Requirements.   That RFC needs to be referenced, and its implications for the
Geneve design worked through.  Section 3.6 of RFC 8085 is of particular importance,
as I expect that many uses of Geneve will be in Controlled Environments (a concept
defined in Section 3.6 of RFC 8085), which in turn enables some requirement
relaxation, as described in RFC 8085.

[2] UDP Zero Checksum.  The draft's text in Section 3.3 on use of a zero UDP checksum is
probably ok for IPv4, but it is definitely inadequate for IPv6.

RFC 6936 is not currently referenced by this draft - that RFC needs to be a normative
reference, and the draft needs to discuss how Geneve meets the requirements in Sections
4 and 5 of RFC 6936 (see Section 5 of RFC 6935 to understand why this is necessary).
Please note that a simple sentence that requires implementations to meet these RFC
6936 requirements is insufficient, as some of the requirements are design requirements.

A specific example is that Geneve does not provide its own integrity check, as
RECOMMENDED by item 2 in Section 5 of RFC 6936, and hence the draft needs to
explain why.  It may help to look at the examples of working through these RFC 6936
requirements for other encapsulations in RFC 7510 (MPLS/UDP) and for the TMCE
applicability scenario in RFC 8086 (GRE/UDP).

[3]   The recommendation for Path MTU Discovery in Section 4.1.1 is a good start, but
needs to be extended and strengthened.  In particular, it should be a Geneve design goal
that if an end-system sends a non-fragmentable packet whose size exceeds the MTU of
the overlay network provided by Geneve,  then the ICMP PTB message back to the end
system is originated by the encapsulating (first) NVE.   This avoids loss of ICMP payload
information caused by nesting of tunnels.  For more discussion, see
draft-ietf-intarea-tunnels and draft-ietf-intarea-frag-fragile, at least the first of which
should be added as a reference, probably informative.

As noted previously, I'm willing to work with the draft authors and the nvo3 WG to address
these concerns, and regret that other demands on my time prevented completion of
this review before the Bangkok IETF meeting week.

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Mon, 12 Nov 2018 18:37:13 +0000

Hello David,

Thanks for  your review of draft-ietf--nvo3-geneve-08. We will work with you to address the comments. We will get back with responses later this week.

Regards,
Ilango

-----Original Message-----
From: David Black [mailto:[email-masked]] 
Sent: Friday, November 9, 2018 9:24 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Tsvart early review of draft-ietf-nvo3-geneve-08

Reviewer: David Black

This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. 

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

I need to start by disclosing a potential conflict of interest - my employer (Dell EMC) and VMware are both part of Dell Technologies and my job responsibilities include working with VMware.  I don't believe that this situation affects the content of this review.

On its own, the Geneve encapsulation protocol design looks reasonably good and solid.
The draft is well-written and provides significant useful design rationale to explain the Geneve design in addition to its specification of Geneve.

This review focuses on concerns that arise in interactions with IP networks.  As this is an early review, it mostly points out areas where additional work is needed without providing all the details of what should be done.  I'm willing to work with the draft authors and the nvo3 WG to address these concerns, and regret that other demands on my time prevented completion of this review before the Bangkok IETF meeting week.

[1] UDP Requirements.  Geneve uses UDP, but this draft does not reference RFC 8085 on
UDP Requirements.   That RFC needs to be referenced, and its implications for the
Geneve design worked through.  Section 3.6 of RFC 8085 is of particular importance, as I expect that many uses of Geneve will be in Controlled Environments (a concept defined in Section 3.6 of RFC 8085), which in turn enables some requirement relaxation, as described in RFC 8085.

[2] UDP Zero Checksum.  The draft's text in Section 3.3 on use of a zero UDP checksum is probably ok for IPv4, but it is definitely inadequate for IPv6.

RFC 6936 is not currently referenced by this draft - that RFC needs to be a normative reference, and the draft needs to discuss how Geneve meets the requirements in Sections
4 and 5 of RFC 6936 (see Section 5 of RFC 6935 to understand why this is necessary).
Please note that a simple sentence that requires implementations to meet these RFC
6936 requirements is insufficient, as some of the requirements are design requirements.

A specific example is that Geneve does not provide its own integrity check, as RECOMMENDED by item 2 in Section 5 of RFC 6936, and hence the draft needs to explain why.  It may help to look at the examples of working through these RFC 6936 requirements for other encapsulations in RFC 7510 (MPLS/UDP) and for the TMCE applicability scenario in RFC 8086 (GRE/UDP).

[3]   The recommendation for Path MTU Discovery in Section 4.1.1 is a good start, but
needs to be extended and strengthened.  In particular, it should be a Geneve design goal that if an end-system sends a non-fragmentable packet whose size exceeds the MTU of the overlay network provided by Geneve,  then the ICMP PTB message back to the end
system is originated by the encapsulating (first) NVE.   This avoids loss of ICMP payload
information caused by nesting of tunnels.  For more discussion, see draft-ietf-intarea-tunnels and draft-ietf-intarea-frag-fragile, at least the first of which should be added as a reference, probably informative.

As noted previously, I'm willing to work with the draft authors and the nvo3 WG to address these concerns, and regret that other demands on my time prevented completion of this review before the Bangkok IETF meeting week.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 27 Nov 2018 10:12:36 +0100

Hi David,

thanks for this very good review. I noticed that many of the references you provide below are not given on the wiki page:

https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues

In case you happen to have some time, it would be great if you could update that page/the references on that page… or any body else in the ART…?

Thanks!
Mirja

> Am 10.11.2018 um 06:23 schrieb David Black <[email-masked]>:
> 
> Reviewer: David Black
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
>

---

From: "Black, David" <[email-masked]>
Date: Tue, 27 Nov 2018 17:55:32 +0000

Done, Thanks, --David

> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2018 4:13 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-nvo3-geneve-08
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
> 
> thanks for this very good review. I noticed that many of the references you
> provide below are not given on the wiki page:
> 
> In case you happen to have some time, it would be great if you could update
> that page/the references on that page… or any body else in the ART…?
> 
> Thanks!
> Mirja
> 
> 
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 28 Nov 2018 09:17:51 +0100

Thanks!

> Am 27.11.2018 um 18:55 schrieb Black, David <[email-masked]>:
> 
> Done, Thanks, --David
>