Hello, Gorry!
Thanks a lot for your review. In-line....
On 18/2/21 13:54, Gorry Fairhurst via Datatracker wrote:
[....]
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”
We'll apply the suggested change.
* 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.
FWIW, we discuss the Flow Label a bit because the usual reaction would
be "why do you process the header chain for load-balancing, instead of
employing the Flow Label?"
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. —--
We'll apply the suggested change. Thanks!
The remaining comments are not linked to paths, and are editorial comments/NiTs:
* Maybe the double parenthesis could be just ‘[‘ and ‘]’ rather than “([“ and
“])”?
Yep. Will do.
* Reading: /(and formally forbids such fragmentation case)./ - readability
could improve by removing /case/
Will do.
* A definition would be helpful for /RLDRAM/.
Would a reference to https://en.wikipedia.org/wiki/RLDRAM do the trick?
Or were you just suggesting to expand the acronym?
* 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/
You mean something like "carrier-grade router"?
* 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?
Agreed. Will incorporate this.
* Insert "forward":
/to make a decision regarding which of the links to use for a given packet./
- to /use for/to use to forward/
Will do.
* 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.
Will do.
Thanks a lot!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
