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

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492