IETF Logo Mail Archive

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

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

Return-Path: <nick@foobar.org>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B6D3A0C33; Sat, 20 Feb 2021 12:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 sh2wIvYsGgOz; Sat, 20 Feb 2021 12:27:03 -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 435303A0C35; Sat, 20 Feb 2021 12:27:00 -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 11KKQqlX074266 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Feb 2021 20:26:53 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> <33917505-f8d0-ecce-dd3a-ef9812d62602@foobar.org> <CALx6S34MrT=aGq3cWkGTrZsbQQJhxVGo1x6HfLP-pxKsfhYy2g@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <a70544d6-fa7b-a712-2f22-b081e9774e97@foobar.org>
Date: Sat, 20 Feb 2021 20:26:51 +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: <CALx6S34MrT=aGq3cWkGTrZsbQQJhxVGo1x6HfLP-pxKsfhYy2g@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/last-call/_OELTnMEP2Glz-yqwISj3IJhw5k>
Subject: Re: [Last-Call] [v6ops] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Feb 2021 20:27:05 -0000

Hi Tom,

Tom Herbert wrote on 20/02/2021 19:46:
> Give that these classes are documented, then the obvious question is
> what are the common limits that should work. RFC8504 does this for
> some of the limits that are more apropos to the host; hopefully, an
> outcome of this draft will define some practical limits for routers
> and set some expectations about what should work.

Definitely that would be good material for a future ID.  This aim of 
this draft is:

>    This document summarizes the operational implications of IPv6
>    extension headers specified in the IPv6 protocol specification
>    (RFC8200), and attempts to analyze reasons why packets with IPv6
>    extension headers are often dropped in the public Internet.

I'd love to see some future discussion about reasonable lower limits 
that we could expect manufacturers and software authors to aim towards, 
but it's out of scope for this draft.

Nick

v2.23.0 | Report a Bug | By Email