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

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 <David.Black@dell.com>:
> 
> 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@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.
> 
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
> 