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

Thanks!

> Am 27.11.2018 um 18:55 schrieb Black, David <David.Black@dell.com>:
> 
> 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
>>> 
> 