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

[Gorry Fairhurst <[e-mail]>]

TSV-ART reviews are for our transport ADs's, so they will look at this 
in IETF-LC.

However, thanks really for looking into these details and for the 
changes you propose.

I can help clarify your questions below:

On 18/02/2021 17:56, Fernando Gont wrote:
> 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?"
>
>
Thanks - I see. Brian's Carpenter's suggestion would also help avoid 
misinterpretation.
>> 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?
>
>
I'd suggest to avoid the URL to wikipedia (people can easily find that - 
or a more concrete reference, but need to be certain of the term). To be 
clear, I was more expecting a simple expansion:

"Reduced Latency DRAM (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/
>
> You mean something like "carrier-grade router"?
>
That would be much better, or something similar that differentiates this 
from AP's, desktop routers, etc.
>
>> * 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,

Best wishes,

Gorry