On Jul 28, 2021, at 7:09 AM, tirumal reddy <kondtir@xxxxxxxxx> 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 <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> 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
tsv-art@xxxxxxxx <mailto:tsv-art@xxxxxxxx> 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
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
