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