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

Fernando Gont <fgont@si6networks.com> Thu, 18 February 2021 17:57 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D12A3A14F5; Thu, 18 Feb 2021 09:57:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhmmsNUjzpPx; Thu, 18 Feb 2021 09:57:01 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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 fgont.go6lab.si (Postfix) with ESMTPSA id 7D08B2801BB; Thu, 18 Feb 2021 17:56:44 +0000 (UTC)
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsv-art@ietf.org
Cc: draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org, last-call@ietf.org, v6ops@ietf.org
References: <161366727749.10107.14514005068158901089@ietfa.amsl.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <42668fb5-a355-e656-7d99-c40b3d33fb92@si6networks.com>
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: <161366727749.10107.14514005068158901089@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/LG6AAwfn-j7p6UKapvMdPRPSyf4>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=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 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@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492