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 tsv-art@ietf.org 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.