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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 08 April 2021 09:32 UTC

Return-Path: <rwilton@cisco.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 142193A0924; Thu, 8 Apr 2021 02:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.617
X-Spam-Level:
X-Spam-Status: No, score=-9.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=I6/1wTah; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hB/RgGD2
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 86tyqypoyzwx; Thu, 8 Apr 2021 02:32:18 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA6B3A090D; Thu, 8 Apr 2021 02:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14718; q=dns/txt; s=iport; t=1617874337; x=1619083937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eTsGUInev2X7GIWsyEAnKZWw68/RDCF4nlK/o8r+yp4=; b=I6/1wTahKjznneSIybvpABMbe00qcB4HEBsNYDWgpTly8mqeQ4+EwnEb 3YjFkdx19144qmQ8HzUJRc8fECQ8/epmGKc4SfzaEUvfTuTY+aDk9y+57 Scfhpe3qwLrdpkSFZUa4aY2tRBZwq+5sE8oEZnECUPjxfNjWQMej7WfIM g=;
X-IPAS-Result: =?us-ascii?q?A0DtAQBazW5gmJJdJa1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?VKBU1F+WjYxCoQ4g0gDhTmITgOBCZgyglMDVAsBAQENAQEdCwoCBAEBgVuCd?= =?us-ascii?q?QIXgWACJTgTAgMBAQEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBaIVQDYZEA?= =?us-ascii?q?QEBAQMBARYLEQwBASwLAQsEAgEIEQQBAQECAiYCAgIlCxUICAIEDgUIgmkBg?= =?us-ascii?q?lUDLwEDC6BmAoofd4EygQGCBAEBBoEzAYNyGIITAwaBDyqCdoQJhVR6JxyBS?= =?us-ascii?q?UKBE0OCKQcvPoJgAQGBNwEqgxU1giuBaVsGIB4mAQMiIQgICQsMLgEEBQMqE?= =?us-ascii?q?ywIDQsTBRYfAZE5glBClGGRYQqDC50fpHGzT4RvAgQCBAUCDgEBBoFrIYFbc?= =?us-ascii?q?BU7gmlQFwIOjh8MDQkVgzmFFIVFczgCBgoBAQMJfIlQASeBDgGBDgEB?=
IronPort-PHdr: A9a23:l8Rn3xwbsYW0kj7XCzMhngc9DhMPsqjoPgMT9pssgq5PdaLm5Zn5I UjD/p1FjFLTV4jB9/ZNjeaQuKflCiQM4peE5XYFdpEEFxoIkt4fkAFoBsmZQVb6I/jnY21ff oxCWVZp8mv9PR1TH8DzNF3fuHe/9yIWExPzcwFyI7e9Fovblc/i0ee09tXaaBlJgzzoZ7R0I V22oAzdu9NQj5FlL/M6ywDCpT1DfOEFrV4=
IronPort-HdrOrdr: A9a23:Gj9Uo6+Vw4cHpvenVmpuk+Gpcb1zdoIgy1knxilNYDRvWIixi9 2ukPMH1RX9lTYWXzUalcqdPbSbKEm8ybdc2qNUGbu5RgHptC+TLI9k5Zb/2DGIIUPD38Zn/+ Nbf6B6YeeeMXFTh8z3+RT9Nt4mzsWO/qzAv5ag815GZ2hRGsZdxi1+DRuWFVAzYQFAC4YwGp b03Ls4mxOLf3MLYsOnQkQfV+/YqNHR0L7gaxgKBxkogTP+zA+Awrj8DhSew1MiQypCqI1Sv1 Ttvi7YwuGYs/+9wgLBzGO71fRrsfbo19crPr32tuE7MTPp4zzYAbhJe7rHhzwtpfHq1VBCqq ixnz4FH+Ber0zcZXu0pxyF4Xih7B8L52X5wVGVxVvPyPaJPg4SMMZKiYJHfhax0SNJ17sQvN MprgCknqFaAh/akCP268KgbWAWqmOPvXEgneQP5kYvN7c2Vb5LoYQTuGNTHZsQdRiKkLwPLe h0AMnQoMtRaFORBkqpx1VH/drEZAVWIj62Bmw5/uCF2Tlfm350i2ECwtYEo3sG/JUhD7FZ+u XtKM1T5fJzZ/5TSZg4KPYKQMOxBGCIawnLKniuLVPuE7xCE27RqqTw/K4+6IiRCd415ap3vK 6EfEJTtGY0dU6rI9aJxod3/hfER3j4ejjx1MdE5dxctqfnTLTmdQ2PIWpe1veIkrE6OIn2Sv yzMJVZD7vINm31A7tE2AX4Rt1cMn8bXMoJussqWl6Hr87RQ7ea8dDzQbL2Hv7AADwkUmTwDj 8oRz7oPvhN6UitRzv5jXHqKjXQU3262ag1PLnR/uAVxoRIHJZLqBIphVOw4dzOLTVDt6cxbV ZvOb+PqNLjmUCGuULzq0l5MBtUCUhYpJ/6VWlRmAMMO0ToNbAZu9uefmhW1GCdJgB2St7XFA I3nSUyxYuHa7irgQwyAdOuNWyXy1EJomiRcpsakqqfodv+doggFZYgUqxpHQDNHxh48Dwa8F trWUshfAvyBznugaKqgNgoH+nZbcB7mxruC9VTs2jjuUKVotwPSnMXUyW1a9OehR8jSlNv9w ZM2p5apIDFuD60bUMjnewzMTR3GRWqKYMDKD7AWaJ5tfTAfhpqQWKDmDqA4itDClbCxgE1nW zuLSqdZPfRJEFS00ooiJrCwRdTaniXeV52ZzRct4BwfF625kpb4Kusere51XeXZx855twldB vBYTcUP2pVto2K/RaIhTePEmgnzJ0yPurbSK8uaa3Xx2nFEvz6qYgWW/BT55prL9bor6sCVv +eYRacKHfiB/ouwBH9nAdpBABk7H0lm+jvwhvr8Syx22M+G+PbJD1dNvomCsDZ62jvXPCT1p plydozoOurK230LtqL07veYTIGKhTdpweNPqsVgIERuaI5r71oGZbHFTPOyXFcxR07aN7ui1 l2etUM3JnRfot0O8ACcSNQ+VQk0NyJMUswqwTzRuszZ0skgXPXN86AioC45YYHEwmEvk/9KF Of+ypS87PeUyyP2aUTBqgwLW5VAXJMoEhK7aeHbcndGQ+qf+ZM8B6mKXe7aqZaU7XAFrMKrB p2iuv40NO/Zm79wkTXsjR6KK4VrDriTsO2HQ6WGelHt9a9Ik+Bh6O24Mi1yDf7IAHLH3gwlM lAbwgXaM8GlzwpyIsw2SK2Qrbsok0kn0BFiAsX32LFy8yj+iPDAUpCMQfFmZ1YUjlYL2iQga 3+gJ2l/WW45CIAxILKG0hRdMxfAtQcToD4KCF1NMgb1YTYiJYHk2BEexchD2k1lTD70adnxN 6CqYfvZ9E=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,206,1613433600"; d="scan'208";a="666525873"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2021 09:32:16 +0000
Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 1389WGu3011952 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 8 Apr 2021 09:32:16 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 8 Apr 2021 04:32:16 -0500
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 8 Apr 2021 04:32:15 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Thu, 8 Apr 2021 04:32:15 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sy9/GYSz8q8ewlzq/IJpHbSJ0maASk1dC1Vkj5bxZiImiMoYMJrhk0/BsDDXNtHXIH3ymCmeLLHk3N6362PvcFTrMbiYr55MjGaDdYTCxZrG8z0T5UjEqM8eYGCVfbdVRbmmHTnWQ2ZvxfW62msgihnN2Q+BZPdvCQdwaqE+pEZgGmo0WT8bu54i5lQLkXZahRfMLqJ6iAuQoa68snFUBGPRuGntRKseM9g8EYKUcHl6z+a2UfZQA4r5Qthl5HBh/CO6FlXNeJpKy5bkxvc1M78i8iksow4x+hnpac8E2gOkcG9dZ4jYdCPfEM4Mxs6Pgawsu3AMzpeIhIuXbpfM9A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eTsGUInev2X7GIWsyEAnKZWw68/RDCF4nlK/o8r+yp4=; b=A9cN60B/0/8fjgA9SmMyinJIE6DWYLU+T/wbHxiwdYnhMdM2iKFB3UJ/fXHnc47bAwWaNA9rxjsrLDZ23PlXUKmgX+fbHjmDdsgRRvlaxmtZoTrtgYg+TeUHPnoFGli5Db2hJfz0lzIL52qREw0ZEC0q5AztdVgmdtFc/WDdJLFfqdeR79mPRcvxXI0prhxuvGL0kLUwaWPJOrWzaFOCtp07BpXCk8SCliYbZfpp4+Koaos7GWMkvoAiMyj/BLnbyIwySA058vdJUZC8s++h2goPbMcJrdY4QB3uvZB3By2XiFzy7x9KS56/g1NpJ/+/XamXkaFU/eHwajSTSYuy+A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eTsGUInev2X7GIWsyEAnKZWw68/RDCF4nlK/o8r+yp4=; b=hB/RgGD2Cbpm2iXx+aXhioKuXYaQggcTejtDqagE9xjIVK7ANbNO1Y2+dT61562Auyi+XxKKZDJF6+O7Gs+YiHixoGK90vpEJI969GwBpyqSbBO/wDcAR8gbVs203H+OwncinPnxbTodHrTV9vzbg1CfwgtKh8VSXK7scEk/p7c=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4239.namprd11.prod.outlook.com (2603:10b6:208:192::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.26; Thu, 8 Apr 2021 09:32:13 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::24c4:4c09:f6f0:5510%2]) with mapi id 15.20.3999.032; Thu, 8 Apr 2021 09:32:13 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
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" <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>
Thread-Topic: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
Thread-Index: AQHXCsn5yhj1+hgwUUGOa6kqXcaGXapnh84AgBQtBoCAAJbAAIAAD4+AgAAyVoCALMcmgIAAGNEAgAABCbA=
Date: Thu, 8 Apr 2021 09:32:13 +0000
Message-ID: <MN2PR11MB436645BFD1A460ED3F4A0806B5749@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <161366727749.10107.14514005068158901089@ietfa.amsl.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> <e41f3484-f816-e185-2d99-94323c8da732@si6networks.com> <CALx6S34qSxGijVcs229bAL5gMhMvMNYUXm3yEmrg6wxUiUAiaA@mail.gmail.com> <bf83d228-25bc-21bb-f984-d58ead6bf492@si6networks.com> <CALx6S35Kh-QAXJDAucuw5Wty37MBiwS=pqQknMZ+15b7D5Sn8A@mail.gmail.com> <34e78618-cb28-71a1-a9d3-7aec38032659@si6networks.com> <CAO42Z2zqD9_d2Fbr25Y2CV1GdzYKd167yf5DHeHna7V66pF65A@mail.gmail.com> <0bd316ac-1789-f4c6-d280-943ad6e60309@si6networks.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>
In-Reply-To: <CALx6S3447SJwdRPoG_BaXS=ihBe1xA84vxcCev1y2K4xqMYZaQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 89e4ff1e-5624-4923-1afb-08d8fa71311b
x-ms-traffictypediagnostic: MN2PR11MB4239:
x-microsoft-antispam-prvs: <MN2PR11MB4239569F01603290F386BE33B5749@MN2PR11MB4239.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 540pIGeywv2/qkZ4XcdMS7Khmrbfbj7apSW97CLABuqOAKjUUvDBfmOb1o28+QIc8BSdFsd9x8ELZSn8YkAw7VjeHupRp+cl6e9PJJ2g/U7kz+bBjrvStdJzaLpBKoDLJJ6gdc4rbb4WSTYNMuPw3yJA+0A9oTDueklG4ks1TZs0dYY6Q3011I34ZLaR0DPgNy28tFWmvghighzWLUBba8C8fjA/SZhBrtU+N8LBbIp1yRDTjrctmjqFho4wdrp0ALFZs27udWbWqrfINMOclFtzjtB839XAYCCKd0Pst22wAHzazJEtPY76CsUXfEys+oV0YsglcU6rA40E9yZPplXsHV3Z362QmK3ODCyi/kXqJkjwhyKFRXrj/HeTYb4VruHoiG2VkpGLILGd5g0cNwWzcY0T/m6mx0U5V9CjnkM2O8wh3FhLrBk3kmsIo5pP6ERTAQIN3iHjm7KzEEg7kYc6QQYL2+e4xBYIPjDnS6KHZcFP5MPyuAklepTXYxwTQtsnfUYIKpxTM8Fth9o59tNBGmRUy0a9HUj8LIuEa7aPUq+fzIw6S4LxiUhPWifor2U0iL4Uw2nkRgwl1nLGSSCb2YJMFGqZjyA0YkaXHttXVDYYQSwv42jdz78npcCCUzgeTQ62vc+AISpDQKrDBClg8NnJJ+vCmMmiUQJz07ppEXoyBk5+FcL2LMZBKc0ow82FP4PctDP7oMN4/yQ7tHYd85XBirIUODtKwKu/THzwNc1FweLpX0FJ+GJ/8M/d
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(39860400002)(366004)(376002)(2906002)(316002)(4326008)(478600001)(54906003)(71200400001)(6916009)(52536014)(6506007)(9686003)(66574015)(966005)(186003)(55016002)(8676002)(53546011)(86362001)(33656002)(66946007)(66556008)(66476007)(8936002)(76116006)(66446008)(7696005)(30864003)(64756008)(5660300002)(26005)(38100700001)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?ems3eTY1NG84cFpkL1lReDM0THVyOG5CZ0ovMFdXUFNSemtoYmpwWFRMZ2ZZ?= =?utf-8?B?RnBtRkFISklHT0pUSlhDQnkyRjgvdEp6N2UwMW5VbUhRM1JrTDdEOEpwbGFj?= =?utf-8?B?R01BVWEvWEZUUlA3ZXVaQnRtc2c5c0I3MDcwTGZTSldHLzB3T3p0a0g4cVRh?= =?utf-8?B?MUhCTkg4OWI5TVUrb1ZnMUo1aHF0OFF5K0xXdnozREQ0SVZveDNHMW40ckkr?= =?utf-8?B?cythYnNTUUp4RWl0SWpqS2NmRFdGdXUxT0RpRTMzTlFuYVJSQ1JlQ3J4YWtO?= =?utf-8?B?NytGclJBZU1EdWxZR0R1V1JCQTZRdEVKSFl3MEFjUFRQaGlTdys1QnVuUmFJ?= =?utf-8?B?WDFPQ2tsQmpUTG5BeGhEajl3WUo0T3pEQythK1ZJRFNObWJFZlpqcWY3UTBp?= =?utf-8?B?N0l3cTJnSjIwWUxVcUxQalFHWHNIaDRpRW1wK3pEMFNGOVZFSG85N3lOa1JR?= =?utf-8?B?R1NlRVovdVovNU5zRFE5SXBITjk4anpMUEpVYk9JTGNETHkrY1ZqTXBER0Vl?= =?utf-8?B?Y0ExVGl0VlIzV1pSWWNQeDdJNWljbkVHMll4aVU2akRwVDlvbGZsVGFJd0hH?= =?utf-8?B?bURIdGYvU01DMWkrNFZScFBUTDdBQnlua1pTS0ZPVGpBZFNhMkNzYWhkZ0lw?= =?utf-8?B?QnF4QzAvZlAxRVlwdWljdHdkSkFOV2oxSW5PZTR3U0QzcFdIZU1XUW50K2pK?= =?utf-8?B?akwvVlVDc3JFTEZZVnV2b21GZ1EwbEtKU2ZrL1dXd2lRNUVWVWRqdFMveU5h?= =?utf-8?B?YnR5M1Fxck5YcWttY3hFT1MvZXhYRldkcnMvNk9xeDBCbTNoL0d4dU5MNGJr?= =?utf-8?B?d0FnS3hManJ2WG9OTnNoNWlRQ296di8rVzNGZHR6eGNyVlJwOGNwZ1pyOHJ6?= =?utf-8?B?K3Q5L2hRaFdoMXg0STBkRnRjVzhjdHdFclo3MnhrTUVmdXB6VHVGbkVkWjVa?= =?utf-8?B?bUVqTGc5MFVrR0VodlBsb1pmaWhrc1kybHA2QnVPL2lLTy9LeHhBUjBibVpo?= =?utf-8?B?RHRJU05GZGJqT204SUk5OVVpUVJGQUt0RHRiL0cvV2ZibWN2Wi9nNlFIMUdN?= =?utf-8?B?VDdzNlFSUCtZbzJueDBRSmVySkErcFRIOWl4SWpHaGlpdFAyV1R0M1d2UW96?= =?utf-8?B?Y3RhcWRKWW0vdXhrY2xkWVBuR09lOVJ3VUg4dXVQcHk3UzA3OXo0QnNabVFJ?= =?utf-8?B?TEYrSElCOWxPcnp2OTZZREZOS2FINThwOERGTHlZeDVmQTU4SkFremZYbGpK?= =?utf-8?B?eUFqOGJuekZDcTBvbDFtcUh6NGk2UkVYNk9IWlNaNjFRNzBCM01TNm1Pc1JC?= =?utf-8?B?bExWZUxZRE84UXFQU0g0YzZBL3oyNjhRVFQ1T3lkTHNCQ3BYSlcxUTNJcUFz?= =?utf-8?B?bFAzV1dBZlkvNXJhMVU1RDdjY2E3cnZXWndyN1p5VGJzOXZDakUxRWNLSjdM?= =?utf-8?B?QXJDTmcvb3FacEdsQm81M3VWL0Z3SGJUczUyWGZqQXFVY3puakg0YVIveGRQ?= =?utf-8?B?QTNkOEN3aURXeWpJN0lrRHZtcnZhMXEzQ3N5S24yMExYZ0VLTGlycnk3RFlP?= =?utf-8?B?MVhSS2NZZlRrOGx2UkpxTFNHRHp2eG0yTGZnT3pacmV1bWZEbytXZzlwdTh6?= =?utf-8?B?RkFmZlpQcVYzSGVCR2taU3FqVnJXODlxc1QyMUFrcUd0R2s4aW16RXNNUGR1?= =?utf-8?B?NkV6c3E3RHdXSFdIdFlXdXJzVXVaOUNBZnQ4MTkvZU95NWNGeGNrQ1ZnNXU0?= =?utf-8?Q?9NRPtROv9Vhaq7n71hoSTTcz62Pl7tkj3qLWNJO?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89e4ff1e-5624-4923-1afb-08d8fa71311b
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 09:32:13.4134 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LiztB7Lg2tIYwgpUaGv7mddSaPe9ynssT35IfT/583o0DEna7VbKkrCFnCQ2VLrJIkHkQxHw68gTRMA352cM8Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4239
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/dl9BaxbX0CAAjLjkkB5j5fMKlM0>
Subject: Re: [Tsv-art] [v6ops] [Last-Call] 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, 08 Apr 2021 09:32:23 -0000

Hi Tom,

Thank you for your comments.

Regarding the header sizes, I asked the authors to remove reference to specific products because I believe that information is only illustrative rather than definitive.  Even within the same product family there are often different linecards that are based on different silicon families.  Those silicon families will likely have different characteristics/optimizations, and those characteristics vary by different generations of those product families.  Whether a router will forward a particular packet with extension headers might be due to the size of the packet header that is made available to the forwarding ucode, or it might be due to ucode instruction limits, which may change depending on software version as the ucode gets extended to support more features.  It may also depend on what features are configured by the network operator.  All of which makes me feel that providing some illustrative information about the size of header processing for some devices is helpful, but we should not regard that information as being definitive unless it has both been confirmed by the vendors as being accurate, and the precise scenarios under which it was been tested have been documented.

I am generally supportive of efforts to gather extra empirical test data about how extensions headers are being treated on the Internet, but I agree with Brian's subsequent comments that gathering such data in a meaningful way would take a significant amount of time and effort.

Getting more information from the router vendors may also be helpful, but I'm not sure how forthcoming that information will be, and it may depend on how operators decide to configure those devices.

On a more positive note, I see that various technologies currently being standardized in the IETF (SRv6 and IOAM) that make use of IPv6 extension headers, so we may start seeing greater extension header support in new revisions of hardware and software.

Whilst I entirely understand your desire for end hosts to have better information about how extension headers may be used, I don't think that is the purpose of this document, nor am I willing to send it back to the WG to ask them to rework it into something that would be a significantly larger scope, and would take a long time to collect.

I'm satisfied that this issue has been discussed and that the document represents rough consensus.  I will include a note regarding this discussion in my IESG writeup so that the other ADs are aware of it when they ballot on the document.

Regards,
Rob



> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> Sent: 07 April 2021 16:20
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: Fernando Gont <fgont@si6networks.com>om>; Gorry Fairhurst
> <gorry@erg.abdn.ac.uk>uk>; IPv6 Operations <v6ops@ietf.org>rg>; draft-ietf-
> v6ops-ipv6-ehs-packet-drops.all@ietf.org; last-call@ietf.org; tsv-
> art@ietf.org
> Subject: Re: [v6ops] [Last-Call] Tsvart last call review of draft-ietf-
> v6ops-ipv6-ehs-packet-drops-05
> 
> On Wed, Apr 7, 2021 at 7:22 AM Rob Wilton (rwilton) <rwilton@cisco.com>
> wrote:
> >
> > Hi Tom, Fernando,
> >
> > I would like to send this document to the IESG.
> >
> > Have we managed to reach a conclusion on this issue?
> >
> > Tom, my reading of this draft is as Fernando describes, in that it
> > only intends to describe the implications and avoids making any
> > recommendations.
> >
> > I was going to suggest that a sentence be added to the introduction to
> > make this clear, but on checking again I see that the document
> > already contains a pretty clear disclaimer in section 2.
> >
> > 2.  Disclaimer
> >
> >    This document analyzes the operational challenges represented by
> >    packets that employ IPv6 Extension Headers, and documents some of the
> >    operational reasons why these packets are often dropped in the public
> >    Internet.  This document is not a recommendation to drop such
> >    packets, but rather an analysis of why they are dropped.
> >
> > Is this sufficient?
> >
> > I guess that the authors could consider adding a sentence that it also
> doesn't provide any recommendation on how end hosts make use of extension
> headers, but that might be a bit incongruous in the sense that the
> document doesn't appear to talk about end host behaviour at all ...
> 
> Rob,
> 
> Given that hosts are the ones creating extensions headers and other
> packet formats, hosts have a vested interest in how routers are
> dealing with their packets. Even before this document was created, we
> have long known that extensions headers might be dropped and have been
> working on mitigations to reduce the number of drops which are already
> addressing some of the reasons that packets with EH. For instance,
> consider draft-hinden-6man-hbh-processing-00; this is a proposal to
> limit the number of HBH options to exactly one. The idea is that
> routers will make it feasible for routers packets that have HBH
> options, with the trade off of specifically limiting the extensibility
> of the protocol. The problem is there is no data that indicates this
> proposal would have the desired effect; we don't if routers would
> start accepting packets that are limited to one HBH option.
> 
> So my fundamental concern with this draft is that it is an entirely
> qualitative description of a well known problem, however a qualitative
> analysis is insufficient input for moving extension headers forward.
> In the draft, there are several reasons suggested as to why routers
> might drop packets, however there is no indication of the relative
> occurrence frequency of these. Also, there are parameterizations
> mentioned such as in the state that routers might drop if the chain is
> "too long", there is no analysis on exactly what "too long" commonly
> is (a couple of sizes for parsing buffers are mentioned but without
> reference which is another frustration of mine with this draft). A
> quantified analysis of the problem would delve into implementations
> and deployment thereby providing actionable data. Note this is not the
> same as making recommendations, I am just asking for the operational
> data as part of the analysis from which we could derive guidance or
> new protocol requirements.
> 
> Tom
> 
> 
> Tom
> 
> >
> > Regards,
> > Rob
> >
> >
> > > -----Original Message-----
> > > From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Tom Herbert
> > > Sent: 10 March 2021 02:03
> > > To: Fernando Gont <fgont@si6networks.com>
> > > Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>uk>; IPv6 Operations
> > > <v6ops@ietf.org>rg>; draft-ietf-v6ops-ipv6-ehs-packet-drops.all@ietf.org;
> > > last-call@ietf.org; tsv-art@ietf.org
> > > Subject: Re: [v6ops] [Last-Call] Tsvart last call review of draft-
> ietf-
> > > v6ops-ipv6-ehs-packet-drops-05
> > >
> > > On Tue, Mar 9, 2021 at 4:03 PM Fernando Gont <fgont@si6networks.com>
> > > wrote:
> > > >
> > > > On 9/3/21 19:07, Tom Herbert wrote:
> > > > [...]
> > > > >
> > > > > Yes, ACLs on transport layer ports are common requirements,
> however
> > > > > the problem arises from related requirements that arise due to the
> > > > > limitations of routers to be able to locate the transport layer
> > > > > information in a packet. An example of such an implied requirement
> > > > > from this draft is "don't send packets with IPv6 header chains
> that
> > > > > are too long because some routers can't parse deep enough into
> packets
> > > > > to find the transport layer ports due to implementation
> constraints
> > > > > (like limited size parsing buffer)".
> > > >
> > > > You seem to be reading more from the document than what we actually
> said
> > > > in the document.
> > > >
> > > > There are no requirements in this document. We simply explain things
> > > > operators need to do, what are the associated limitations in real-
> world
> > > > devices, and what's the likely outcome.
> > > >
> > > > That's not an implied requirement, but simply a description of
> facts.
> > > >
> > > It's obvious that the implied or at least inferred requirement is that
> > > if a host wants to increase the probability of packets making it to
> > > the destination then they should not make header chains too long. This
> > > would also be an obvious interoperability requirement, i.e. if I make
> > > my header chains too long then packets will be dropped and my host
> > > stack is not interoperable with some elements in the network.
> > >
> > > >
> > > >
> > > > > While the rationale for the
> > > > > requirement may make sense, the problem, at least from the host
> stack
> > > > > perspective of trying to send packets with low probability they'll
> be
> > > > > dropped, is that a requirement that "don't IPv6 header chains that
> are
> > > > > too long" is is useless without any quantification as exactly to
> what
> > > > > "too long" might be.
> > > >
> > > > "too long" for the processing device(s). You don't know what devices
> > > > will process your packets, hence cannot even guess what "too long"
> might
> > > > mean.
> > > >
> > > > What you know for sure is that the longer the chain, the lower the
> > > > chances of your packets surviving -- as per RFC7872.
> > > >
> > > That seems to me more like an assumption than a proven fact. To prove
> > > it we'd need the data that correlates the length of the chain with
> > > probability of drop, or alternatively, one could survey common router
> > > implementations' capabilities and similarly extrapolate the
> > > correlation. If we had this data then we could derive a meaningful
> > > quantified requirement for both what routers are expected to process
> > > and what hosts can expect. RFC7872 doesn't really have sufficient data
> > > to make this correlation, and besides that it is not current.
> > >
> > > In any case, this draft qualitatively describes why routers are
> > > droppings. Which I suppose is good, but, given that information, I
> > > don't see much that helps host developers that are sending packets in
> > > the network and are trying to go beyond sending packets that conform
> > > to the least common denominator of plain TCP/IP.
> > >
> > > Tom
> > >
> > > > Thanks,
> > > > --
> > > > Fernando Gont
> > > > SI6 Networks
> > > > e-mail: fgont@si6networks.com
> > > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> > > >
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > https://www.ietf.org/mailman/listinfo/v6ops