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

Fernando Gont <> Thu, 18 February 2021 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D12A3A14F5; Thu, 18 Feb 2021 09:57:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rhmmsNUjzpPx; Thu, 18 Feb 2021 09:57:01 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CBE23A14F8; Thu, 18 Feb 2021 09:56:48 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:d092:11d0:9223:9b8f] (unknown [IPv6:2800:810:464:2b9:d092:11d0:9223:9b8f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7D08B2801BB; Thu, 18 Feb 2021 17:56:44 +0000 (UTC)
To: Gorry Fairhurst <>,
References: <>
From: Fernando Gont <>
Message-ID: <>
Date: Thu, 18 Feb 2021 14:56:34 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Feb 2021 17:57:08 -0000

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  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!

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492