[v6ops] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

[Gorry Fairhurst via Datatracker <[e-mail]>]

Reviewer: Gorry Fairhurst
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
[e-mail] if you reply to or forward this review.

/ Review:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/?include_text=1
——

This draft examines ops issues associated with IPv6 EHs. The document is
well-written, with an operational/security bias. The transport area interest is
primarily as a user of the potential to use an EH, and how an EH might impact
the probability of packet delivery to an endpoint.

* The ID discusses the current issues that result in EH filtering:
In this respect, the document describes challenges and mitigations based on
experience - and concludes:   “This document is not a recommendation to drop
such packets, but rather an analysis of why they are dropped”. However there is
one sentence where the text could potentially be mis-read as offering new IETF
advice, which if misread, could suggest there is no potential for a future
transport to use this, which I don’t read as the intention: /As a result,
operators usually drop IPv6 packets containing this extension header. / - There
are various ways you might consider rewording this. One way could be to say
something more like “As a result, many operators currently drop”

* The ID also discusses use of the IPv6  Flow Label: This seems a little off
topic, but seems linked to EH implications on ECMP.  However, the final
sentence of this section is a reference to [Jaeggli-2018] which in turn
concludes that the IPv6 Flow Label should not be used it as a part of hashes
for load balancing. Yet, as far as I know, this is not the recommendation of
the IETF in 2020.  This seems therefore to be an odd concluding sentence for a
section that seems otherwise to support the IETF recommendations. - This might
perhaps be easily made more neutral by moving the sentence that affirms the
IETF RFCs. i.e., moving the sentence starting “Clearly,…” to become the last
sentence in that section. —--

The remaining comments are not linked to paths, and are editorial comments/NiTs:

* Maybe the double parenthesis could be just ‘[‘ and ‘]’ rather than “([“ and
“])”?

* Reading: /(and formally forbids such fragmentation case)./ - readability
could improve by removing /case/

* A definition would be helpful for /RLDRAM/.

* There are many types and sizes of routers, is this true of all routers
(including low-end) or could this better reflect some type of routers? So,
maybe the following statements could use better words than /most contemporary
routers/? /Most contemporary routers use dedicated hardware/ … and later: /Most
contemporary routers have a fast hardware-assisted forwarding  plane/

* I suggest a more powerful chip design might not have reduced performance, but
would cost more: /but the overall performance of the system will be reduced. /
- so maybe either performance is reduced or the system cost increased?

* Insert "forward":
/to make a decision regarding which of the links to use for a given packet./
- to /use for/to use to forward/

* Typo:
/ Use of unknown extension headers can prevent an NIDS/IPS from  processing
layer-4 information/ - Add a period after, to match other items in the same
list.