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

Nick Hilliard <nick@foobar.org> Sat, 20 February 2021 19:10 UTC

Return-Path: <nick@foobar.org>
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 271E63A084A; Sat, 20 Feb 2021 11:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 b-InGE1BMiLC; Sat, 20 Feb 2021 11:10:29 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082CA3A0839; Sat, 20 Feb 2021 11:10:27 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 11KJAHrm064972 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Feb 2021 19:10:18 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
To: Tom Herbert <tom@herbertland.com>
Cc: Fernando Gont <fgont@si6networks.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, IPv6 Operations <v6ops@ietf.org>, draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org, last-call@ietf.org, tsv-art@ietf.org, Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <161366727749.10107.14514005068158901089@ietfa.amsl.com> <42668fb5-a355-e656-7d99-c40b3d33fb92@si6networks.com> <0e377231-c319-2157-30a0-759e2f96a692@gmail.com> <5f464f17-85ed-f105-35f9-02f35d04aed2@si6networks.com> <CALx6S364zGbq_HZNNVEaJHnHccuk4Zau2DXhmaVYbwnYQc-5bw@mail.gmail.com> <1847e8e3-543f-5deb-dd14-f7c7fa3677db@si6networks.com> <CALx6S34TPppMRJrOvyJ05LLeRvv+S51pQHJnzZDKk-qOdsF0AA@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <33917505-f8d0-ecce-dd3a-ef9812d62602@foobar.org>
Date: Sat, 20 Feb 2021 19:10:16 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.46
MIME-Version: 1.0
In-Reply-To: <CALx6S34TPppMRJrOvyJ05LLeRvv+S51pQHJnzZDKk-qOdsF0AA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/AOeuwok1a_OeoSfCGTZGTejzYsc>
Subject: Re: [v6ops] [Last-Call] 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: Sat, 20 Feb 2021 19:10:31 -0000

Hi Tom,

Tom Herbert wrote on 20/02/2021 15:32:
> This is reflected in the statement: "If an IPv6 header chain is
> sufficiently long that it exceeds the packet look-up capacity of the
> router, the router might be unable to determine how the packet should
> be handled, and thus could resort to dropping the packet." It's not to
> me clear what "sufficiently long" means;

Is this just an issue of dialect?  The term "If an IPv6 header chain is 
sufficiently long that..." just means "If an IPv6 header chain is long 
enough that..."

> in particular, such a
> statement isn't helpful to the host stack developer trying to figure
> out if the packets they're creating will be properly forwarded.

That's something that should be addressed in a future ID.  Right now 
we're concentrating on documenting the problem.

Nick