On 29/04/2024 12:04, Brian Trammell via Datatracker wrote:
> Reviewer: Brian Trammell
> Review result: Ready with Nits
>
> 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 if you reply to or forward this review.
>
> This document is OK for transport.
>
> Thanks for this document; it's a valiant effort at fixing v6
hop-by-hop options
> to be current-reality compliant. Given the TTL of various devices
doing things
> the old way, I'm skeptical that it will have much immediate effect
but I still
> consider it quite useful to publish as an update to 8200 for its eventual
> future effects.
Thanks for the review.
We are not expecting it to have an immediate effect (like most IETF
documents).
Please see sepcific responses below:
>
> A couple of questions/nits:
>
> in Section 4: "Significant reordering of the packets belonging to a
flow can
> impact the performance of upper layer protocols and needs to be
avoided." The
> first part of this is obviously true. The second part is mostly true
for most
> protocols in most of the Internet, but I'm not sure "needs to be
avoided" is
> universally true for all transports. In the absence of any good way
to know how
> reordering-tolerant a given flow is, I'm not sure I have advice for
making this
> text better, but it makes me feel a little sad nonetheless.
GF/BH: I still think the key word here was "significant", and since an
IP router typically does not know the packet payload, then significant
reordering does need to be "avoided" - because this upsets IPsec, some
transports (not all), some other protocols (not all).
I expect though we could have improved the text that Joe noted,
describing that reordering better, and we propose better text in that
preceding statement to clarify this:
NEW: If a subset of packets in a flow were to include Hop-by-Hop options,
this could introduce a potential to increase the number of
re-ordered packets
and the re-ordering distances of the packets
delivered to the destination.
>
>
> in Section 5.2: "If a router is unable to process further Hop-by-Hop
options
> (or is not configured to do so), the router SHOULD skip the remaining
options
> using the "Hdr Ext Len" field in the Hop-by-Hop Options header." --
This is
> good advice, of course, and the document refers to eh-limits with
respect to
> how long an HbH header should be. Do we have confidence that deployed
routers
> can skip on the fast path?
GF/BH: All IPv6 Hop-by-Hop options have a bit in the option type that
instructs the router to skip this opinion if not recognized, so we have
confidence that routers can do this.
>
>
> Section 5.2.1, in essence if not in explicit language, deprecates the
Router
> Alert option, but the IANA considerations leave
>
https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values.xhtml
> (and its references) untouched. Is this intentional?
>
>
GF/BH: We are not intending to deprecate the router alert option. The
text in the draft that relates to this is in a “Discussion” section, it
is an attempt to describe the issues, and how this ought to be used when
required.
Best wishes,
Gorry & Bob
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
