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

Done, Thanks, --David

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]
> Sent: Tuesday, November 27, 2018 4:13 AM
> To: Black, David
> Cc: tsv-art@ietf.org
> 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:
> 
> 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
> >