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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 19 February 2021 09:30 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B7C3A12FD; Fri, 19 Feb 2021 01:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1a1btn8xYpS; Fri, 19 Feb 2021 01:30:30 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 226923A12FA; Fri, 19 Feb 2021 01:30:25 -0800 (PST)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E13651B001D6; Fri, 19 Feb 2021 09:30:17 +0000 (GMT)
To: Fernando Gont <fgont@si6networks.com>, tsv-art@ietf.org
Cc: last-call@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org, v6ops@ietf.org
References: <161366727749.10107.14514005068158901089@ietfa.amsl.com> <42668fb5-a355-e656-7d99-c40b3d33fb92@si6networks.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <204296d8-8936-de28-9cf1-e9b1e0adb3ce@erg.abdn.ac.uk>
Date: Fri, 19 Feb 2021 09:30:17 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <42668fb5-a355-e656-7d99-c40b3d33fb92@si6networks.com>
Content-Type: multipart/alternative; boundary="------------C62DF5D949C8E6D50B708EB4"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9DiFvhiF8ZG5aCZA6hVkMrBRdMI>
Subject: Re: [v6ops] [Tsv-art] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2021 09:30:34 -0000

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