[Last-Call] Tsvart last call review of draft-ietf-6man-hbh-processing-15

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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?

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?



-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux