Re: [Detnet] New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 21 June 2021 10:05 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6223A2AF6; Mon, 21 Jun 2021 03:05:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.996
X-Spam-Level:
X-Spam-Status: No, score=-9.996 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=bBm6UVYN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lycOQU51
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 Ulf752l_TNaB; Mon, 21 Jun 2021 03:05:29 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502D83A2AF3; Mon, 21 Jun 2021 03:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11934; q=dns/txt; s=iport; t=1624269929; x=1625479529; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OVW97DrD/8He6MaM293xcmC7ExlLNveVGO7EvyKNvng=; b=bBm6UVYNqr6zMPU8k94M+6fc9IygxxV/EqIopmcjxUe0gMGPn0MgwOfo HCZ/Sr5HooURrvlig5JPUJ01atqohqDQReJNN83F+a+jyc5nmmYXUd2IW xMe2y4wkAVt1+WhGWTryN8CBCkkHqjagkwa3LwReXL+h+KNJi/rt+FH8S Q=;
IronPort-PHdr: =?us-ascii?q?A9a23=3A4fUEwRYRbd7wpQdBptiTEe7/LTDJhN3EVzX9o?= =?us-ascii?q?rIrjrtUeeKi8ojsekvF6qYlgFzIWNDd7PRJw6rTvrv7UGMNqZCGrDgZcZNKW?= =?us-ascii?q?hNE7KdenwEpDMOfT0GuKvnsYn82Gc1YXxlk8m21d09PF5W2a1jbuHbn6zkUF?= =?us-ascii?q?132PhZ0IeKgHInUgoy32um+9oeVbR9PgW+2YKh5K1O9qgCC3vQ=3D?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A1E43W678XjuXHqEIHAPXwXuBI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiY1TiXIra6TdaoguiMc0AxhJk3Jmbi7Sc69qADnhO9ICO4qTPSftW?= =?us-ascii?q?jdySuVxeRZjbcKrAeQYBEXeIRmpN1dmsRFebjN5B1B/LnHCWqDYpQdKbu8gd?= =?us-ascii?q?2VbI7lph8HJ2wHGsIQjTuRSDzrbnGeLzM2Y6bRYaDsnvav0ADQAEj/AP7LYk?= =?us-ascii?q?UtbqzmnZnmhZjmaRkJC1oM8w+Vlw6l77b8Dlyxwgoeeykn+8ZmzUH11yjCoo?= =?us-ascii?q?mzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8kuLCn2gArAXvUkZ1TChkFznAic0i?= =?us-ascii?q?dyrDD+mWZ5Ay210QKLQoiBm2qq5+An6kd115at8y7EvZKpm72IeNtzMbszuW?= =?us-ascii?q?seSGqE16Ll1+sMjp6iGAmixsVq5Fr77VbAzsmNWBdwmkWup30+1eYVknxESI?= =?us-ascii?q?MbLKRctIoF4SpuYds99Q/Bmcoa+dNVfYzhDTdtABqnRmGcunMqzM2nX3w1EB?= =?us-ascii?q?vDSk8eutaN2zwTmHxi1UMXyMEWg39FrfsGOtd5zvWBNr4tmKBFT8cQY644DO?= =?us-ascii?q?AdQdGvAmiIRR7XKmqdLVnuCalCMXPQrJz85qkz+YiRCdM1JVsJ6d/8uXZjxC?= =?us-ascii?q?8Pkm7VeLqzNaxwg1jwqT+GLEDQI+lllu5EU5PHNc/WDRE=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1BgC5Y9Bg/49dJa1QCh4BAQsSDEC?= =?us-ascii?q?BTAuBU1EHd1oTJDGIEAOFOYhqA49bikKBLhSBEQNUCwEBAQ0BASoLCgIEAQG?= =?us-ascii?q?EDEQCgm0CJTQJDgIEAQEBEgEBBQEBAQIBBgRxE4U7BSgNhkUBAQEEAQEQFRk?= =?us-ascii?q?BASUHCQIBCwQCAQgRAQMBAS8nCxcGCAIEAQ0FCBqCUIJVAy8BDporAYE6Aoo?= =?us-ascii?q?feIEBM4EBggcBAQYEBIE4Ag5BgzAYgjEDBoE6gnuCcVOHKyccgUlEgRQBQ4J?= =?us-ascii?q?gPoJiAQEBAQEXgQwNLySDJ4IughkVARAVgTAEIhkWAgQQDjEIAhYIFgc4CQQ?= =?us-ascii?q?HFApyA5BhBBMaCSKLVoEqi0GSAwqDH4oUhzCMUxKDXosnlm2VWIIYigaTKQQ?= =?us-ascii?q?ECwSEZAICAgIEBQIOAQEGgVQ7gVlwFRohgmlQFwIOhWqINQkDFoNOhRSFSnM?= =?us-ascii?q?CAQE0AgYBCQEBAwl8jBYBAQ?=
X-IronPort-AV: E=Sophos;i="5.83,289,1616457600"; d="scan'208";a="634714723"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jun 2021 10:05:27 +0000
Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 15LA5PIo015332 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Jun 2021 10:05:26 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Mon, 21 Jun 2021 05:05:25 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 21 Jun 2021 06:05:24 -0400
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Mon, 21 Jun 2021 06:05:25 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gCLfXaF/Dh5xfL+MF4/eoC6NY3/miR0NUINSpns8cO34Rj4u/Ueo/0bbv/rCkVoB7am4KC2c00dtdaV06aTjUKHQiOi0tDhrkNSB+c81Ute+NIg401mJd/Za/37T01SaJ4pUZmC3c+4/+Q2IDWuYLcngeYaaH44yvSni3yMqzNE1J3KR7tjW52ZOVuCrsYvUoaump4JxgjZOcRg+cS2wyu63aTw6KvassBB9fguQbU8dabseLKuxC3Mhfhi/enm/qKp8AUT+mETPN6Zxqxczho0vitu5qK+BdiSCLJG1H+KGzQLEepA2ovzI7uKss+vi0Rq9+p9ge2Npf10bxuznTQ==
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=e4dvmXjFPngG/V0DjUevIxEsWGObWe7oG3RL/5AfLHM=; b=X9z+jSJLONQT9lfWmxwcN4pdYzNlTwH8gCrjukz1x5Zjd+TJhB4a9AFz6Q0KvXQkC4Z/7RO9f3pz59aXh7p5UckfWb0ZPEUHzC3WByI+/6fVKUjzvm1igzfxXisWsQRzyw2kMtIZz6bXiKEk0hYRQxENHmuGEc0CwVB4so5xHRmKIYJTcdhHXtp4H3vicLYnL/4OHp+Q9H6GrXZl2yN6QcJlj9SW2ETBGyVe5rl8yO5YMBHyuTIePsCn2mvxz3zy6aJ9nUfxKAcMP+ryUd3t7usnRSQGMbU0G6LKsCUMMLG4VQDPfFqiskeueva0ZyVMD6jHSxC4FECdmDLVKeWRwg==
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=e4dvmXjFPngG/V0DjUevIxEsWGObWe7oG3RL/5AfLHM=; b=lycOQU51UJLB9qrI++x3wLN3aUtQ5p3ozS9EcB2heQs1f1Tb7/+KMbPHoB9ZO4rhhX9o5285EsaWYdnAhXlb+ARVjPLafa8Aw+xQmlrl/jcpPeboN3OY4/3LVfhIXbe6wpQdEc69kR4MlklTR2BXDUjSGEfYYDaUIfg5ZIWPQ2c=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR1101MB2176.namprd11.prod.outlook.com (2603:10b6:301:4f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.23; Mon, 21 Jun 2021 10:05:21 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::9da6:468c:4d04:2110]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::9da6:468c:4d04:2110%6]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 10:05:20 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= <balazs.a.varga=40ericsson.com@dmarc.ietf.org>, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, DetNet WG <detnet@ietf.org>
CC: "raw@ietf.org" <raw@ietf.org>, "draft-hinden-6man-hbh-processing@ietf.org" <draft-hinden-6man-hbh-processing@ietf.org>
Thread-Topic: New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt
Thread-Index: AQHXXGAXtlZ3GlpFqEmWs7L6IwUPz6sKB5zggA9eJnCAABhiEIAE0hOw
Date: Mon, 21 Jun 2021 10:05:06 +0000
Deferred-Delivery: Mon, 21 Jun 2021 10:04:48 +0000
Message-ID: <CO1PR11MB48814010897EAB883F32D8D6D80A9@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <162315455072.2639.8291756086249391036@ietfa.amsl.com> <CO1PR11MB4881E8BD24409460424D22F0D8379@CO1PR11MB4881.namprd11.prod.outlook.com> <AM0PR07MB53476E5292F4250CDBF47C49AC0D9@AM0PR07MB5347.eurprd07.prod.outlook.com> <CO1PR11MB488116FFD3B005528ECC1176D80D9@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB488116FFD3B005528ECC1176D80D9@CO1PR11MB4881.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:f424:93b7:4d6e:5a0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b0ad228f-71f6-4f72-87ad-08d9349c144b
x-ms-traffictypediagnostic: MWHPR1101MB2176:
x-microsoft-antispam-prvs: <MWHPR1101MB2176BA4F9414E7503230BCE7D80A9@MWHPR1101MB2176.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: VfunOkMjjFWFVU4cBrPfKxOE/1bRvcdbP6t2jFVVnpkqYTcS+o7f0CjFovFy3WW6WiItll8q38cIxY++dgFjfvyQcxD7c4tqXQdRpmHEEkPQkXEGTSbpvY8VwAqXR+HvbfXPPIhSeWGXMBbM9Y4zE8mHVpWU5MVaRdQ3PVpgdGK1nKxDlDzCjqFOgSmh+adDni7t10OeFzlVvTo6bCfadZptH9kpbaSxLD9xvA0cbmqMWBr8Cwq7qNZRWezPgDVWZKQAXz9BsjO+6GiKuQGfkv6/jNBoDYhSNOQzYAffh+2mDWFWdl/vZs1HpBNNiEBsxGLKJ3pOHJhHnRiCDVqZThkjU+f9HTVqIroC6uArZ1G05UlFAES4SyDrXjLi0r1ChZkskeRZ1Kq8Un0DIAebTakzquco7cXkSj1go5Qwic8nK8LfLLaZTkPIGiatTCcvZIV8A5gQ8QPDhTDE7jFJwWl5b1+KBuZT6U8zFHoIgdoKhTEJXs522BuCJ0txSDnm/2rACEg0tgP6cqb2NvinwF+gW0eS++d6faQdd1WfHu2vnluDIyLgKaJyJN++UKl+kN6wPnYU+FokQlOav+WVhmyC6spopI7w+xinX7bXqSJXWGALgCruq/QtMEPVud02rZ5Pa/PG42/Iqcz1nCxWOR3cFQb0BTjYIu6mg8WBXBajzJKIZxSBAES5/7UPEfYdkDmpC1iFlpSF/b4CKYW26fNYCXsLm88aHHaWNHrHBLSZLXrsplVmAUd0L+dIs4fv
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(346002)(39860400002)(396003)(376002)(30864003)(4326008)(52536014)(5660300002)(66574015)(83380400001)(15650500001)(122000001)(55016002)(8676002)(8936002)(316002)(76116006)(966005)(71200400001)(478600001)(66946007)(66446008)(64756008)(66556008)(66476007)(33656002)(2906002)(9686003)(6506007)(53546011)(54906003)(110136005)(7696005)(6666004)(186003)(38100700002)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?UCS7f7qdxjqDkCvu2H8rbVA7TZErIuUze/ILz5VmQBQgENm9tZBYE63wOb?= =?iso-8859-1?Q?kysg+RkjNL1GA90Q1RklOLgK0tCUUtXlrjZ/OYQ9HU7H2ygpvm6rAiqZ/R?= =?iso-8859-1?Q?cwi/6k3ROzrMJXLeob3WoFPkcNXkNsid5M6q3mDfa+GkkghMiCqdqDb27i?= =?iso-8859-1?Q?E0ogYvVI5qnKKNvAHS9et7G2NJqkUUnF771bsy7htFoQBjyVvs6eyLpB2a?= =?iso-8859-1?Q?vcHXDz3F1goriJjv+s929BKJKUkI2A9tmJhj8ODHtyLcjINOuuCXc8Sdm8?= =?iso-8859-1?Q?3qjxkzY5okdwfXO4/TwRaBwGmUqFlLHUkDx1drodGtO/IesbwYezzJfp/A?= =?iso-8859-1?Q?JNXl14I4mwBxLA6S+7LLHPmTXXNG+60M0xFYo/lhkcWZQwjiK/OMYfhjBA?= =?iso-8859-1?Q?03J+ad58Cfv6z1oaT9meqyBDHFETx6Qmr2RcUM6dNdWsN9FLxdeRkLfVv2?= =?iso-8859-1?Q?bgLU85SusoL6E0Jw7uG0rYq3GyMr7j8QwrqIic5x5k8VIWSD1T+rfOFMQD?= =?iso-8859-1?Q?yymmXqs2jwJe1i21AlOPCazFiE2nYO6xAMtHBT7L/7GgaO0+9LkI0dd6VH?= =?iso-8859-1?Q?Db70D2zktcTey+Ohm1cOYn8lKBGTzJePxvWuoL99gpLtOjG6FeB6p8eAmv?= =?iso-8859-1?Q?O8Tz81MTb6man1OXcuxYKCyG6Oz69hD5A/hd/spV9SRaUfmbsuYi/VCVIp?= =?iso-8859-1?Q?AMpcZ+PO5Yd16GarpgOiu8JgGgebSGa3CUVeAb6GTemkt8kn08UE4kx+Ix?= =?iso-8859-1?Q?Ryq5ES1BbGhsy8R5USNb7CtfVfU8JezGcNu3Sh6862qTSxHy9BWCsbug5f?= =?iso-8859-1?Q?leYfchwesEwE/WhLW+1fkTerdjDWbj7XivlIvnL1DYE1YeaQ/VVej5wuNX?= =?iso-8859-1?Q?ipQZ8noAfEUtnvtkqUOWTM1Ad01EVF/ZxwPe9+17wKDLzBtBXS4BqWhliW?= =?iso-8859-1?Q?sCfZBgDGcTMIFMzU9/cVoFZU4hT2fW/hoXsDGAcSlCa2npUB0QRQ3cRpsC?= =?iso-8859-1?Q?B5q1mY1uP2K6ZzyPy+h4Kn3dg7vtnwSQQb4UA+4tCRegcvZHjkUR2yQD2Y?= =?iso-8859-1?Q?NUnUG8mJJoHGbnHlwPKfAMuSkDjT/Rhz46sUPvGK02ky0WNYhvQ4y+2ZZ8?= =?iso-8859-1?Q?8TnEThJN1Xd/Vu7U0hVmDf01WG038t3m6F+qYaM4W3dKKHqnvvVTLb5sOF?= =?iso-8859-1?Q?GQ9N+ZWCKeEAGlf4rOBsZuz0ONq+evH+8MY37S3uwxAVeSMGcBG/cELC20?= =?iso-8859-1?Q?va32l/UTHkLGw9UFUNu37sypewPqmGg4k/EqnCyDVH955HjZ4kQlKaamzh?= =?iso-8859-1?Q?RXe/tXKN6r5o23fTYEHmsla1tGv/Ml8qQ1DPPvd790sH0OuA80KHR27VQR?= =?iso-8859-1?Q?edr9aXyx6haYfhkEaAL3uRTb5KVN3pcNH2DTczsaUwso4zo31boBQERnc2?= =?iso-8859-1?Q?gx9PTtbA/dg2Zq9s?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b0ad228f-71f6-4f72-87ad-08d9349c144b
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2021 10:05:20.8527 (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: WBXIJiCRhhLJgX981lWlFLu4ogr+69jcwjGlJa+YTEGyA9ZYHEGi7OOLxuRiMzCxJR4jlvmkriHnoEP1UUAFRg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2176
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/wXqA8vbp9qlDTFLLgJId12K64NU>
Subject: Re: [Detnet] New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jun 2021 10:05:34 -0000

Hello again Bala'zs

As promised, I published an 04 to cover your comments. You'll find a section on applicability where the needs and reasons to encapsulate are discussed further.

URL:            https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-04.txt
Status:         https://datatracker.ietf.org/doc/draft-pthubert-detnet-ipv6-hbh/
Html:           https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-04.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh
Diff:           https://www.ietf.org/rfcdiff?url2=draft-pthubert-detnet-ipv6-hbh-04

Many thanks again!

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: vendredi 18 juin 2021 13:37
> To: Balázs Varga A <balazs.a.varga=40ericsson.com@dmarc.ietf.org>rg>; Pascal
> Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>rg>; DetNet WG
> <detnet@ietf.org>
> Cc: raw@ietf.org; draft-hinden-6man-hbh-processing@ietf.org
> Subject: RE: New Version Notification for draft-pthubert-detnet-ipv6-hbh-
> 01.txt
> 
> Hello Bala'zs
> 
> Many thanks for pointing out what might be unclear to the reader!
> 
> I'll update the draft to clarify the points you made there. I'm still
> answering inline to share with all what the intent is, and get feedback.
> 
> 
> > In general:
> > 1, Do You propose to use IPv6/UDP tunneling between DetNet relay nodes?
> > "... the DetNet information ... and can be added by a service instance
> > as part of the
> > >>> encapsulation by the Ingress of the DetNet path <<<."
> 
> The draft proposes a pure L3/RFC8200 DetNet/IPv6 signaling, using an IPv6
> EH. This is my reading of the intention of RFC 8200, as served by SRv6 or
> RPL today. To your question, and per RFC 8200:
> 
> - if the DetNet end points are the flow endpoints there is no
> encapsulation, and the HbH is placed by the flow source
> - else, if the DetNet path endpoints are routers they'll need to
> encapsulate
> 
> This makes DetNet fully inline with the IPv6 architecture and open to the
> progress / extensions done elsewhere for IPv6. E.g., if the DetNet path
> leverages SRv6 for some reason - there are plausible ones in RAW -, the
> SRH will also inserted at the ingress and readily accessible without DPI
> next to the HbH EH.
> 
> Note also that the sequence is determined by the DetNet ingress point for
> the path independent of the flows that are carried within the path. The
> drafts adds the important distinction of path and flows, which was missing
> from the earlier dataplane document but present in the 6TiSCH and RAW
> architectures (https://www.rfc-editor.org/rfc/rfc9030.html#name-on-tracks,
> https://www.ietf.org/archive/id/draft-pthubert-raw-architecture-
> 07.html#name-wireless-tracks), and can be signaled by RPL
> (https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-
> projection#section-9).
> 
> This distinction will make our OAM work easier, allowing non-IPPM OAM to
> traverse the same path as the flow(s) with the same treatment.
> 
> 
> > 2, Are the proposed options encoded in the tunnel IPv6 header?
> > " It can then be accessed by the intermediate DetNet routers
> > >>> without <<< the need of a deep packet inspection (e.g., >>> beyond
> > >>> UDP
> > <<<)."
> 
> Yes, the packet has src/dst the detnet endpoints and the HbH is found
> after the outer IPv6 header.
> See RFC8200 and https://www.rfc-editor.org/rfc/rfc9008.html#name-storing-
> mode for how that 's done in gory details.when the HbH being used is the
> RPL one. The draft extends the existing model to paths that would not be
> signaled using the RPL RPI (which signals a topology) but also using
> different path IDs.
> 
> 
> >
> > 3, All that DetNet functions need are FlowId and Sequence information.
> > Could You please clarify the role of the path option for DetNet
> functions?
> > Or path option is used by RAW (and not DetNet) specific functions?
> >
> 
> The "path" is a wrapper for one or more flows (signaled by 5/6 tuple) and
> OAM packets to incur the same forwarding treatment. It is a Track in the
> 6TiSCH/RAW/ROLL terminology. Apparently DetNet favors the term path; the
> intention in the other groups was to avoid the serial (A->B->C->D)
> assumption that comes with legacy formulations of a path.
> 
> Using a path matches the original intention in the DetNet architecture was
> that a "flow" was a abstract group of packets that must incur the same
> treatment.
> 
> DetNet IP Dataplane decided to signal a flow with the 5-6 tuple, which
> IMHO caused issues such as same treatment for multiple flows and including
> OAM, different transport and address families. With eth IP DP you have to
> wrap them all in a L4 wrapper like UDP, which defeats the purpose of
> operating at the network layer.
> 
> The draft restores the original abstract grouping signaled by a pure L3
> information and avoids reliance on the transport information. It also
> avoids the lookup of the transport header that can be deep in the packet
> and may cause issues when the hardware cannot parse deep enough down the
> IPv6 header chain.
> 
> > In particular:
> > 4, If a tunnel is used, why not to encode the information in
> > Destination Options header?
> 
> Because it is used by all hops to locate the forwarding information
> associated to the path.
> That's what HbH EH is about.
> 
> 
> > Sequence information is not used by DetNet Transit nodes.
> 
> RFC 8200 allows intermediate routers to ignore the HbH options they do not
> understand. That's encoded in the option type.
> 
> > " In that context, it makes sense to consider >>> Hop-by-Hop Options
> > <<< to transport the information that is relevant to DetNet."
> >
> > 5, Why are new sequence counter formats needed?
> > " ... and it is possible that the value 0 is reserved when wrapping,
> > to the option offers both possibilities, wrapping to either 0 or to 1."
> 
> There are some sequence counters that behave like that. This enables to
> embed them directly.
> 
> 
> > 6, Could You please clarify why time stamp is needed? For which DetNet
> > function?
> > " This specification also allows to use a time stamp for the packet
> > redundancy information, ..."
> 
> Timestamping is an alternate sequencing technique, that avoids maintaining
> per-path state at the path ingress. Which is quite cool if you think about
> it, considering that determinism comes with a very precise sense of time
> anyway.
> 
> As long as the time granularity is in the order of a few bytes
> transmission the system timestamp provides an absolute sense of ordering
> over a very long period across all paths for which this node is ingress,
> and thus within any of those. With no additional state to maintain. Just
> program the hardware timestaping to write the offset wherewhen the OH is
> located.
> 
> >
> > 7, R-Tag format and sequencing function is defined by 802.1CB-2017. It
> > is incremented by 1 when a packet is sent. Have I missed something here?
> > "... though it >>> cannot <<< be assumed that the R-Tag is
> > sequentially incremented; ..."
> 
> It cannot be assumed for 2 reasons:
> - only the last 2 bytes of 6 are incremented and the wrapping happens
> there. Knowing that fact is already a layer violation.
> - R-TAG it is owned by IEEE 802 and subject to redefinition there, as you
> are proposing at this very moment, wishing you the best on that.
> 
> The bottom line is that since we (IETF) do not own the properties of the
> 6-byte field, we cannot depend on its properties, beyond the fact that it
> is unique within a reasonable set of sequential packet so all packets with
> the same value (+ same tag) are redundant. The intension is that the
> values are stored in full and individually as opposed to considered as a
> range.
> 
> >
> > 8, Is the hybrid model used by a RAW function?
> > " This specification also allows for an >> hybrid model <<< with a
> > coarse grained packet sequence within a coarse grained time stamp."
> 
> No, but it is already used in draft-ietf-rift-rift; it is a very cool
> thing when the sense of time is derived from NTP as opposed to PTP.
> 
> 
> > 9, What DetNet state is meant her?
> > " When present, it is the information that MUST be used to select the
> > >>> DetNet state <<< at the DetNet forwarding sublayer.
> 
> That's the information as was configured by the PCE for the flow and that
> indicates the per flow behavior.
> 
> My deepest thanks Bala'zs for pointing out places where the draft is
> lacking clarity. I'll publish an improved version asap. If you agree with
> the principles I laid out here (including the OAM incorporation), please
> feel free to consider joining me in this effort.
> 
> Keep safe
> 
> Pascal
> >
> > Thanks
> > Bala'zs
> >
> > -----Original Message-----
> > From: detnet <detnet-bounces@ietf.org> On Behalf Of Pascal Thubert
> > (pthubert)
> > Sent: Tuesday, June 8, 2021 2:23 PM
> > To: DetNet WG <detnet@ietf.org>
> > Cc: raw@ietf.org; draft-hinden-6man-hbh-processing@ietf.org
> > Subject: [Detnet] FW: New Version Notification for
> > draft-pthubert-detnet- ipv6-hbh-01.txt
> >
> > Dear DetNet
> >
> > This new draft is an effort to equalize the work at RAW and DetNet in
> > terms of path signaling in the IPv6 dataplane, and provide the same
> > capabilities in the MPLS and the IPv6 for sequencing.
> > It recognizes and leverages the recent evolution at 6MAN which makes
> > the HBH OH more and more usable in the greater internet.
> >
> > Comments welcome!
> >
> > Pascal
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> > Sent: mardi 8 juin 2021 14:16
> > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> > Subject: New Version Notification for draft-pthubert-detnet-ipv6-hbh-
> > 01.txt
> >
> >
> > A new version of I-D, draft-pthubert-detnet-ipv6-hbh-01.txt
> > has been successfully submitted by Pascal Thubert and posted to the
> > IETF repository.
> >
> > Name:		draft-pthubert-detnet-ipv6-hbh
> > Revision:	01
> > Title:		IPv6 Hop-by-Hop Options for DetNet
> > Document date:	2021-06-08
> > Group:		Individual Submission
> > Pages:		10
> > URL:            https://www.ietf.org/archive/id/draft-pthubert-detnet-
> > ipv6-hbh-01.txt
> > Status:         https://datatracker.ietf.org/doc/draft-pthubert-detnet-
> > ipv6-hbh/
> > Html:           https://www.ietf.org/archive/id/draft-pthubert-detnet-
> > ipv6-hbh-01.html
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-pthubert-
> > detnet-ipv6-hbh
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-pthubert-detnet-
> > ipv6-hbh-01
> >
> > Abstract:
> >    RFC 8938, the Deterministic Networking Data Plane Framework relies on
> >    the 6-tuple to identify an IPv6 flow.  But the full DetNet operations
> >    require also the capabilities to signal meta-information such as a
> >    sequence within that flow, and to transport different types of
> >    packets along the same path with the same treatment, e.g.,
> >    Operations, Administration, and Maintenance packets and/or multiple
> >    flows with fate and resource sharing.  This document introduces new
> >    Hop-by-Hop header options that can signal that information to the
> >    intermediate relays.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet
> >
> > --
> > RAW mailing list
> > RAW@ietf.org
> > https://www.ietf.org/mailman/listinfo/raw