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

"Timothy J. Salo" <salo@saloits.com> Thu, 08 April 2021 14:33 UTC

Return-Path: <salo@saloits.com>
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 4551C3A19B0; Thu, 8 Apr 2021 07:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 kKMZifh2Prx1; Thu, 8 Apr 2021 07:33:42 -0700 (PDT)
Received: from saloits.com (saloits.com [63.228.11.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D6C3A19B2; Thu, 8 Apr 2021 07:33:41 -0700 (PDT)
Received: from [192.168.255.218] (t460-1.saloits.com [192.168.255.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by saloits.com (Postfix) with ESMTPSA id 5AAA8BE0058; Thu, 8 Apr 2021 09:33:40 -0500 (CDT)
To: Tom Herbert <tom@herbertland.com>
Cc: IPv6 Operations <v6ops@ietf.org>, "draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org" <draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
References: <161366727749.10107.14514005068158901089@ietfa.amsl.com> <CALx6S34dMEEJ+OPUu_=FW1Y5AQuvAaHzBPEe448S7rfbMmHN_w@mail.gmail.com> <CEFDF511-9255-4913-840D-50CCBC2B7B17@gmail.com> <CALx6S36_w+zxyUt0DzQ9NKBs+SAPZDNhs_sqLBwi+qneOPSS5A@mail.gmail.com> <ef2bd4f5-3b1e-b88c-ec8f-dd9a2f9a60ba@si6networks.com> <CALx6S349X7fQR=9Dj+n5X7ovXsSjLYibv-C-+bL0nkWsYP5NGA@mail.gmail.com> <MN2PR11MB43668EDA6209CA6AF3BCC5EEB5759@MN2PR11MB4366.namprd11.prod.outlook.com> <CALx6S3447SJwdRPoG_BaXS=ihBe1xA84vxcCev1y2K4xqMYZaQ@mail.gmail.com> <a68c5a02-ad6b-1966-7fe4-678abf14af24@si6networks.com> <CALx6S36pLpF8+Y_8oDiO+UQAnXFt5STSaB5fJgjWp9jFEFv3-A@mail.gmail.com> <42039a4f-b65d-27ad-32a9-a26d0914ec0d@si6networks.com> <CALx6S352qOQD_gvU=Lnyy6U41irs6CPJPc=oNqXqX19JcveNOg@mail.gmail.com> <CALx6S37WDki4e6k9z_Fgf8JB3vOFeHfxkBCmDcryB0vkK5MnrA@mail.gmail.com> <018ce8cc-1db2-ad47-aebe-7b875331e106@gont.com.ar> <CALx6S37ddjxv_k0fUerXT9V08V1+=sH1heAdAoYDVVh427iuQw@mail.gmail.com>
From: "Timothy J. Salo" <salo@saloits.com>
Message-ID: <eac57d7c-5514-3756-f553-0957a959f7c4@saloits.com>
Date: Thu, 8 Apr 2021 09:33:27 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CALx6S37ddjxv_k0fUerXT9V08V1+=sH1heAdAoYDVVh427iuQw@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/eC5DBawghRB66HSmFX73hBQpt7o>
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: Thu, 08 Apr 2021 14:33:45 -0000

On 4/8/2021 9:21 AM, Tom Herbert wrote:
> [...] 
> Sure, tell me, as a host stack developer, what at reasonable minimum
> length is for an IP header chain and I'll fix the packets I'm sending
> so that the operators don't need to be bothered with this.

No one really knows.  Moreover, there is no reason to believe that the
value won't change in the future.  Furthermore, this is well beyond the
control of the IETF: it is driven by decisions made by router vendors
and ISPs.

I think that this has been explained several times, has it not?

-tjs