Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-sfc-nsh-integrity-06

["Joel M. Halpern" <[e-mail]>]

If you want the terminology usage clarified, then what they have 
proposed is sufficient.

If you want to change RFC 8300, this is not the place to do that.

Yours,
Joel

On 7/29/2021 12:41 AM, Joe Touch wrote:
> Insufficient.
> 
>> On Jul 28, 2021, at 7:09 AM, tirumal reddy <[e-mail]> wrote:
>>
>> 
>> Thanks Joseph for the detailed comment and explanation. We plan to add 
>> the following text to address the issue:
>>
>> Note that the term “transport encapsulation” used in this document is 
>> equivalent to the term “tunnel encapsulation” used In 
>> [ietf-intarea-tunnel].
>>
>>
>> Cheers,
>>
>> -Tiru
>>
>>
>> On Mon, 26 Jul 2021 at 10:34, Joseph Touch via Datatracker 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Reviewer: Joseph Touch
>>     Review result: Not Ready
>>
>>     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
>>     [e-mail] <mailto:[e-mail]> if you reply to or
>>     forward this review.
>>
>>     It was very difficult to review this document for IETF transport
>>     protocol
>>     considerations.
>>
>>     Although "transport encapsulation" is indicated repeatedly, it is
>>     never
>>     referred to directly or described either in this document or its
>>     citations. It
>>     appears to be using this term in the sense of RFC8300, which too
>>     never defines
>>     it, but uses examples that are more accurately referred to in the
>>     IETF as link
>>     layer protocols or either network or link tunnel protocols (IP in
>>     IP, GRE,
>>     VXLAN, Ethernet).
>>
>>     Regardless of the fact that this confusion originates in RFC8300,
>>     it needs to
>>     be addressed here and corrected before this document can be
>>     reviewed to
>>     determine if there are any IETF transport area issues.
>>
>>     The remainder of these notes provide detail of this issue.
>>
>>     -----
>>
>>     The document refers back to RFC8300 to define the NSH itself; that
>>     document
>>     discusses transport issues just as vaguely (never mentioning a
>>     particular
>>     transport protocol), and when it discusses fragmentation, it
>>     refers to section
>>     9 of a document (draft-ietf-rtgwg-dt-encap-02 from 2017) that had
>>     expired prior
>>     to the publication of RFC8300.  Because transport fragmentation
>>     is, IMO, a
>>     normative issue, this should not have been permitted.
>>
>>     Further, Section 9 of that draft incorrectly recommends reliance
>>     on ICMP
>>     feedback to address MTU failures when not under a single
>>     operator’s management.
>>     That was widely known even then to be insufficient due to
>>     blackholing; this had
>>     motivated PLPMTUD in RFC4821 a full decade earlier. RFC8300
>>     compounds this
>>     error by simply asserting that the operator should ensure that
>>     ICMPs are not
>>     blocked, overlooking the need to address when this is not the case.
>>
>>     This document cannot ignore that issue and simply refer to RFC8300
>>     on this
>>     issue.
>>
>>     Note that one of the only places an actual encapsulation protocol
>>     is mentioned
>>     is RFC8300, in which Section 5 mentions IP and  Section 6.1 Table
>>     1 describes
>>     VXLAN-GPE, GRE, and Ethernet – all of which are described as
>>     “transport
>>     encapsulation”.
>>
>>     If, in fact, IETF transport protocols are being used, at some
>>     point the use of
>>     an actual IETF transport protocol should be described (e.g., TCP,
>>     UDP, SCTP,
>>     DCCP). At that point, the transport issues would be reviewable. As
>>     the document
>>     currently stands, it completely ignores such transport issues and
>>     should not
>>     proceed until this is addressed and re-reviewed.
>>
>>     If instead, as I suspect, the term “transport encapsulation”
>>     actually refers to
>>     “network layer encapsulation” or “link layer encapsulation” and
>>     really implies
>>     some sort of tunnel, there would be no transport area issues to
>>     review unless
>>     that tunnel were to include a transport protocol as part of the
>>     layers of
>>     encapsulation. If that is the case, the document should be revised
>>     to replace
>>     the term “transport” with something that more accurately describes
>>     VXLAN-GPE,
>>     GRE, Ethernet, and IP encapsulation using IETF terminology. Note that
>>     draft-ietf-intarea-tunnels never uses the term “transport” except when
>>     referring to the use of IETF transport protocols as a tunnel
>>     layer, e.g. (i.e.,
>>     the last sentence of Sec 8 of this doc is incorrect in implying
>>     otherwise).
>>
>>     (I would also note that neither this doc nor RFC8300 define “transport
>>     encapsulation” in their terminology; even if they would, they
>>     should not
>>     attempt to define it in a way inconsistent with widespread use in
>>     the IETF).
>>
>>
>>
>> -- 
>> last-call mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/last-call