Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 08 April 2021 15:49 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502513A0BB0; Thu, 8 Apr 2021 08:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.918
X-Spam-Level:
X-Spam-Status: No, score=-11.918 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_MED=-2.3, 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=DMiZglNN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hiPW5Gs6
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 26hqCp6SQahH; Thu, 8 Apr 2021 08:49:30 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0411D3A0BAA; Thu, 8 Apr 2021 08:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7035; q=dns/txt; s=iport; t=1617896970; x=1619106570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KEdOrULJoF8YQ30QA0WVdlAQ81hPVoDuY21WXwfc6sc=; b=DMiZglNNc3bT00/C/xUFAMP0GVrHvo8OsfFYKYcgNJ41JBb4nevo4xaD Ot5lT5COltpVipYQUZLh6n3wO3x2k+SrbDmLPd5uYLkrabWkub+e8LCn3 +HPw+uJGKlOgmPUpgTeMAaIVMWIlU7+um2TYR/066MYn/4otq2T22ZUHc M=;
X-IPAS-Result: =?us-ascii?q?A0ANAAAjJW9gmIcNJK1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFBAgEBAQELAYFSUX5aNjGICgOFOYhPA4oujw2BQoERA1QLA?= =?us-ascii?q?QEBDQEBHQsKAgQBAYEWAYM5AoF3AiU3Bg4CAwEBAQMCAwEBAQEBBQEBAQIBB?= =?us-ascii?q?gQUAQEBAQEBAQFohVANhkQBAQEBAwEBPgEBLAsBCwQCAQgOAwQBAQEnByEGC?= =?us-ascii?q?xQJCAIEDgUIE4JWAYJVAy8BDqA3AoofdYE0gQGCBAEBBoUnDQuCEwMGgTkBg?= =?us-ascii?q?nWCcVCBW4U7JxyBSUKBE0OBX1EvPoEEgRpCAQGBKwEBCgEGAQMgg0qCK4FZE?= =?us-ascii?q?EKBBwMVGhEQFA4mBwwqEwgsBAkEB00JOgOQWoJpAYoBnChbCoMLl0SFW6Rxp?= =?us-ascii?q?BWPQAiEYQIEAgQFAg4BAQaBaiJrcHAVO4JpUBcCDo4fCRAJg06FFIVFcwI2A?= =?us-ascii?q?gYBCQEBAwl8iVABBiGCHQEB?=
IronPort-PHdr: A9a23:1CW7yB3sLoPFB07JsmDPW1BlVkAck7zpIg4Y7IYmgLtSc6Oluo7vJ 1Hb+e4FpFTSG4vS9rRIhrmev6PhXDkG5pCM+DAHfYdXXhAIwcMRg0Q7AcGDBEG6SZyibyEzE MlYElMw+Xa9PBteA4DwbkCUrnDhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oK xDjpgTKvc5Qioxnec4M
IronPort-HdrOrdr: A9a23:vZgbwqBkQMI2wW7lHei0tceALOonbusQ8zAX/mhLY1h8btGYm8 eynP4SyB/zj3IrVGs9nM2bUZPgfVr1zrQwxYUKJ7+tUE3duGWuJJx/9oeK+VPdMgXE3Kpm2a 9kGpIQNPTZB1J3lNu/xQG+HcopztXvytHXuc715R5WPGZXQotn6Bp0DRveN0VwShVPC5ZRLu vs2uNsoT28dXMLKvmhDn4eUOTZ4/HNnpTqYRkJbiRXqDWmpzWu9bL8Dlykzg4TOgk/gIsK3E rkt0jC5qulu+ym0RO07Q/uxrlfhdeJ8Ko5OOWghscYMS7hh0KEaIFgRLGYrFkO0ZuSwXkwlt 2kmWZEA+1S7DfrcnixsV/R3WDboUkTwlvD7XPdvnf5u8z+Q1sBeol8rKZUaAHQ5UZlnPwU6t M340uju5BaDQzNkU3GjrCiPXwH5ynEw0YKquIdg2dSVoETctZq3PAi1XlIG5QNFj+S0vFALM BSDdrR7PsTUVSWY2GxhBgW/PWQX28+FhrDf04ausb96UkuoFlFySIjtagit0ZF0Kh4Z4hP5u zCPKgtvqpJVNUqYaV0A/pEaderC0TWKCi8cl66EBDCLuUqKnjNo5n47PEe/+exYqEFy5M0hd DoTE5Yj2gvYEjjYPf+maFjw1ToeiGQTD7twsZR69xSobvnXofmNiWFVRQIn9a/pe4cRunWQe y6Np4TI/KLFxqrJa95mynFH7VCI3gXV8MY/vwhXUiVn87NIor28uPBdvLeI6fsDCYkVmvzDm BrZkm0GOxwqmSQHlPoihnYXH3gPmbl+4hrLaTc9+8PjIgBX7c86zQ9uBCc3IWmODdCuqs5cA 9VO7X8iJ62omGw4CLN52VtMRxNE1ZN7NzbIit3jD5PF3mxXacIut2Zd2wX9mCAPAVDQ8TfFx MaoU9296KxJ5mZ3jsjFNqjL2KfgxIo1TW3ZqZZvpfGydbue5s+AJpjcrd2Dx/3Gxt8nhsvtH 1OcxYeRkjUFirnjKKsiJB8PpCFS/BMxCOQZeJEo3PWskuR4fw1TnwARji0TIq8mgA1XQdZgV V37o4SiLeNgiyUNGM6meg0WWc8Mli/MfZjNkClbJ8Rsq33cAtwJF369QCyulUWQC7W0Gk8wk bmNjaZfPnXBEE1gAEq7o/atHVudmuceEpsbGtdqoMVLxWahl9DlcmWe6G0z2ydLnwFz+11Ck CbXRIiZiVz2tuwyBmZ3AynKExj7JAvMuvBZY5TL4370m+xKYGOiKENF+JV+pEgL9z1ruoXS4 ukCn2oBSK9BOUz1wOPoHE5fCFytXk/iPvtnAbo9W6iwRcEcLbvCUUjQ7EQONeH6Wf4A/6OzZ VilNow1NHAeFnZe5qDyavNaSREJQ6WqWmqT/swoZQRua4prrN8E93aVjTPvUs3kSkWPYPxlE kERr58762EMohzf9YKcyYc50E3jr20XQIWmx2zBvV7cUAmjnfdMd/M673UqaA3CknEoAfrI1 GQ/yBU4v+tZVrN6ZcKT6YrZWhGYkk173pvuPmPcIDdEw2mfeBO9ljSCA73TJZNDKyeXbkApB dz5N+F2/KNfy3jwQbKoH91JLlN/2vPe7L9PCucXepTt9q0NlSHjvH0vIq9jDLrRSC6bEpdj4 tfbkAUZtlCjD5njIBf6FnEdoXn5kY+111Z6nV7k1So3I6s6mLSB1tHPg3UmY8+Z0gaDlGYyc DetfGF33H86iVf0ZbNFE1MbshDcuJgOrTfPmNrM4wMp7am8KoknzRbbBovB2A6jirh3+kO58 bO5NzCH+v4CXnpPlod+TlKQo5s9xZb3F19Tw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,206,1613433600"; d="scan'208";a="691471020"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2021 15:49:28 +0000
Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 138FnSVG024435 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 8 Apr 2021 15:49:28 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-007.cisco.com (173.37.102.22) 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 10:49:28 -0500
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rcd-002.cisco.com (173.37.227.250) 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 10:49:28 -0500
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) 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 10:49:27 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X5MFtuGgLHICSAWVLN+5Jz35KnDcHGu77+6LJCah/nfm+THb5o6VKG+z6cf1KldW6L8rNS+YO/I+zxxGdJdvnPA3/2bCuq15Y1KZfcwaf4esDKOlLlAD3gsG/gJoSnCRoD1sksCs5OqC9cQqWYf0/IYiCF7kLwMVYd779FSMpEcxEGifZsWD9wsCJmZQDnEKcG/3ixEEnUZj3xVoQRe8veIJSRL8xfMcsx40OuTTOpyz8uBPzsROzlw3oyxSec0znmAM26EBfrn3rcS6wcf0rJRmYzl7K85DH45PGke4IR8jcbTRmrGGZ2V15LX93U4asHUltR2w4vJLUe/+4aRmKg==
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=FWIi8lGeNxMT6wLDjgZa6xEWAE6uQWw3BRZehf4FVqM=; b=m4sRVH/eQmgwqRU+5NFHoNxrKQyFE3z0h+twg+SbiDhH7QEx1BB5vN8DD1spywPyQi6/b+SUvW22NBsUY9B8UIlMkRZcmnZI1gzJxJdrNAOTXAPWSTkjtPlcLD2v79EV4+ccV1qNQH6q3BGU/ok4Gd0dOh7aA52HXKIL4NZPs9uAZaSyHpvMcRC6/nmUnwzeeIRlydvUlkgpqylWNH4kwtLTb+tFo6yQDaEob6+JwMNl6IZIgNcG8TQdqMkW8DaQH2cvMF46j0YQQBJOC/xGbh1RyG62Hul42ILrjQZmknKYP5NkqLKSqQRghlEiSoKjkC65gE8X4UUUl2HTeiKSnQ==
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=FWIi8lGeNxMT6wLDjgZa6xEWAE6uQWw3BRZehf4FVqM=; b=hiPW5Gs68hcj+1PX7L9lzcUa3noZTKSq0FDZznFHMPybAGQE3zAbr1phYqS8Dh5SWIBg7+AbyCa74mNKiaRhjbXXS5mXYTmCJFPkjENpLPZCqls/RbdfffxHcke3AlwfuEdvOTtBXKMQEwqgvT+KnzzETnkVx1v8yK6rGGFNJj4=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB5060.namprd11.prod.outlook.com (2603:10b6:303:93::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Thu, 8 Apr 2021 15:49:26 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5%6]) with mapi id 15.20.3999.032; Thu, 8 Apr 2021 15:49:26 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Toerless Eckert <tte@cs.fau.de>
CC: Stewart Bryant <stewart.bryant@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "draft-jia-flex-ip-address-structure@ietf.org" <draft-jia-flex-ip-address-structure@ietf.org>, int-area <int-area@ietf.org>, Jiayihao <jiayihao@huawei.com>, "draft-jia-scenarios-flexible-address-structure@ietf.org" <draft-jia-scenarios-flexible-address-structure@ietf.org>
Thread-Topic: [Int-area] Using ISO8473 as a network layer to carry flexible addresses
Thread-Index: AQHW/f5RvUuomHaoYE6mD4FmcmmPVqpOETQAgCFTIQCAAEziAIABExoAgAF58ICAN+DNAIAA/i+g
Date: Thu, 8 Apr 2021 15:49:02 +0000
Deferred-Delivery: Thu, 8 Apr 2021 15:48:26 +0000
Message-ID: <CO1PR11MB4881BB69EE6F535F3D48F0E9D8749@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <2233700F-9AFF-472B-B3BF-33226339DB6E@gmail.com> <93A96A86-C38A-41D9-867A-CC2FE6999505@cisco.com> <20210408002422.GA33100@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20210408002422.GA33100@faui48f.informatik.uni-erlangen.de>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:8832:c2f1:a513:23ff]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 30bc278d-4a49-430a-a29d-08d8faa5e392
x-ms-traffictypediagnostic: CO1PR11MB5060:
x-microsoft-antispam-prvs: <CO1PR11MB5060BEC57D6BD1F6A6A0EC1BD8749@CO1PR11MB5060.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OFSSPU7alrv/hG/S+CuSRpwAPg0HDkL4zZSRQC7NxHEGDYU1fIR43uoSmNImQcBbyK8YvSQi5hVhwz5rPalxI9VpMOI2M3xnVonq7FOuBGj8cQpbPlFEtae/ZvZx17RGVBQAEMU6A1B8a0wpYeOFPOKQ4uwexqCN6EmO4J7cIKD/mTXMTgFDy5cU3r2kF25X6haiSqg/gIQ7FUAPARB6hebu/AD+xXhz7o+SDmsnPFKgl9ScVVMoLJsde1cQYwae9Ng6/4rod4DIEkfDv23XxEZQ5kjQ/8dV0soekSNbAq7p+HgzJXTEe5MpWMdGFk0+ilYYHUB53U5OJOdlWF0jYXV1ZNl13EcH1i5BkzBdBKvrCs1S4UBodwb784jDd6VJYcqUYV4Onn/Yir+r0NjBQqgDQf5lG4aU/qqbqb9PCgnHOqbrWPweaqlVRaUFp/TYvj9NkPDBfdUdqNVTTduDNcJDHIbem1Gu1k9r2NfmpwScAyMOPOBNzQuUl2d8vOHJnikduhWCHUIo1B1RFAbt5bCWhbEeZzu0HI86Vri/tl8EiLhIPnQ7wodx1U3+LzkyQeEHJ2brHn7W0cqsdfxrLsydzExtnhsqQegZzv2vixPvPIcM5lsGmTppQFV8GGRtfJFYvkpz9/I5usLy2rDP2k/HoWVtyNbn1REXnTxzgdy+wEa6IKqSlgz2xAKz5tjKtV0IZ+wd0zdG45TQFdgxdzAcdSThKCaWW86GPcNFVNkBHoEVeOvErIkNdBRfaBQ5
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:(39860400002)(366004)(376002)(136003)(396003)(346002)(9686003)(55016002)(6666004)(6506007)(316002)(2906002)(53546011)(33656002)(71200400001)(4326008)(7696005)(8676002)(966005)(66476007)(66556008)(64756008)(66446008)(66946007)(76116006)(86362001)(83380400001)(478600001)(8936002)(186003)(66574015)(38100700001)(6916009)(54906003)(52536014)(5660300002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?xIESPbQawzB8dFKndSggFWe7RcunChnBYLAUTzkp+AF9Xlo1LC43iqXuhi?= =?iso-8859-1?Q?GuUPwwbLET6lXks6w+eE9+qTkUUVB68LPJnhznf7o9JhF8vPXSivNzMdhD?= =?iso-8859-1?Q?tnCwyVLokOn2sKBuUIFBiPPN28RGIVrcD1bK/rU8U2CycF52CQ18VOX9zA?= =?iso-8859-1?Q?G5pY8tvvq6ul6F1vOcsOLV4qWcIdGQG9Tqh6MKNkgn3aJFQMLB86RClm5P?= =?iso-8859-1?Q?0YDkqVBZXBU3HQxAMSYSxT9VQ/c6iLHklv4VEzNLnmc5hc+OvTCaX+vz5W?= =?iso-8859-1?Q?DqBztPhuIzOR1HU3lzUJjpo0YuNm1w1KVYNzxq5VL0bGrBsUo6ZHFwpaM9?= =?iso-8859-1?Q?CJLVH3KQhOLKXF/ggE7cQDFswcw5H2ZX8KEMSRFrvC3/LmB/T5P+EPxBRY?= =?iso-8859-1?Q?nr6BPzS5yJAz0fziZ+76OW0TeUVqQpdrw72WzjVc+1DkXbFTfJwndafDNJ?= =?iso-8859-1?Q?4lNxb4SJhGc0SRr4V5IUOaSdh4TTq24xLQtzqYaFnsTCH/toGBAzlCxoEy?= =?iso-8859-1?Q?nWkyHx0EHVIW5GkXhdzxr/wrqWDkAt5vqfVumFtnmNPMzkKa0IPNw9yans?= =?iso-8859-1?Q?v9tCCAmGi673e2ROqrXGYsW0qgkmvJo7wN5YUVnOKti/mUgcsbGRh79CGT?= =?iso-8859-1?Q?GuEP2Ex6mCXOk+RMKUoxJOrCZ/3VDX11HigTwR3xegQ11oSHbd1zb5a5G9?= =?iso-8859-1?Q?FZLULxR/YU/CTpww+kew9kgQr3e4dJcd9+o+8G+lA7zZAYEN7IELWDQsAo?= =?iso-8859-1?Q?uRuOYxb62APhmjXsfufo+QZbmQaWmJMIFFInbwUoM/OlA/xP07hJdAkX3h?= =?iso-8859-1?Q?AVcOMFPgIAiPyFU2+ZHgPh4WAxozniE4D22fUgOIO9zyPukl2aQ2NLYBa5?= =?iso-8859-1?Q?orfyeTjMnfMOz3TF9LeI+sBh5MKSF3inNDUO1pxxMDloTk1U8etYrhUn0k?= =?iso-8859-1?Q?gGBHRCJ5TvlROQefnOEZ0My9ndKqHWB0i9vEgzUpXYtarnHCEDeyf+quLk?= =?iso-8859-1?Q?KX+KUB7s+ljbu3mAAp//70MkWRhv51KH1LEFr0GoAeUUcC8oaDKbmIhh+0?= =?iso-8859-1?Q?I/WoNw099atkJuRE95fcRVprdHxGEOysHVL66Z7KNgObxzBJrwH1BZ2pBm?= =?iso-8859-1?Q?ion93LNSJ6GwyCGHQu333ne0UTAMIik4L1MU9fZxJcpMN+EE9jsGLSf/2r?= =?iso-8859-1?Q?C+BfPQiAI74/+fZidpr+YyuIbGi1YS4yvgPl9F42Im+osxcvHP3RTVATYV?= =?iso-8859-1?Q?YyM6bZiqucf7qDe+ZDY8VN1BB5ygnrTvcBuSzcbKNtXj32RZoWFTvTaqQX?= =?iso-8859-1?Q?Uvj+CeQX2bmEie8FPi1ud23mnHlC6HsHV3dCADfx816H8nmYNBL9aR64WZ?= =?iso-8859-1?Q?gwdQfNLtFh7Cb4AddbSmEe4IQ/6MB0Onf1N9y3fBtM9T6IFjz1JBlSjmGE?= =?iso-8859-1?Q?FoONmdmmTjEQi1qR?=
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: 30bc278d-4a49-430a-a29d-08d8faa5e392
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 15:49:26.6405 (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: Ma/cAVC25lspSR5dmBs33Y8sKynLajxyyHAV9J/NcEOAzreUpDx30WXdj/0P+m2wljULLD89I68X9oWgwXS1Fw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5060
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/0MuVAOz-bgME6QAOoxga7N_Jvik>
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2021 15:49:35 -0000

Hello Toerless

I'm not the right person to discuss this, one needs to be close to hardware implementation to wee what's easy what's not. Still I'm curious what you have in mind.

The backward-compatible piece is the core thing isn't it? 
SRv6 flies over a legacy IPv6 network between SR-capable nodes. I believe it is quite a selling point.

Do you intend to make addresses larger than 128bits and then encode network programming in there?
If so, and speaking of 40 years-old networking, I'd be tempted to encode the program as an address extension as opposed to within the address, and to leave the address as is - like good old phone number extension. Arguably one could define a SRH that is composed of {address_extension, next_address} where the extension applies to the previous address (the destination in the IP header for the first entry in the SRH.

For shorter-than-128bits addresses in a limited domain like an IoT network, yes we've done quite a bit in the IoT space, with a degree of freedom that 6MAN seems exempt. SCHC could give you almost anything you want, provided that you can configure the right state everywhere. 6LoWPAN can exclude a well-known prefix from the packet on the wire so you can have shorter local addresses. What the IoT art does not give you is network programmability.

Keep safe;

Pascal

> -----Original Message-----
> From: Toerless Eckert <tte@cs.fau.de>
> Sent: jeudi 8 avril 2021 2:24
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Stewart Bryant <stewart.bryant@gmail.com>om>; Brian E Carpenter
> <brian.e.carpenter@gmail.com>om>; draft-jia-flex-ip-address-
> structure@ietf.org; int-area <int-area@ietf.org>rg>; Jiayihao
> <jiayihao@huawei.com>om>; draft-jia-scenarios-flexible-address-
> structure@ietf.org
> Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible
> addresses
> 
> Pascal,
> 
> Yes, the low-power world in IETF invented a lot of concepts that SRv6 then
> reinvented, but heck, late in the process they managed to at least
> acknowledge some of that prior work through references  ;-) nd not, the
> logic around compact alternatives to SRH also started with the premise
> that those shorter representations are compressed versions of IPv6
> addresses (if i still understand it right).
> 
> This is all great and fine if we think that the only future we can think
> if is one where we try to fit everything we want to innovate on into the
> tight box of rfc8200. And while i agree tht there may be good short-term
> reasons for such options, i just don't see this as a viable long-term
> option to significantly evolve our network layer protocol benefits beyond
> the original esign of 40 years ago. At least not without incurring a lot
> of technology dept that makes it more and more difficult to deploy and
> expand with.
> 
> To me the much more interesting question to ask than "how can we make
> innovation fit rfc8200"
> is how we could provide the most backward compatible superset of network
> layer functionality that does allow us to carry forward what we need
> (e.g.: IPv4/IPv6 semantic), but also allows us to extend semantics
> (especially addressing) in the most cost-effective/performance/least-
> obfuscated way.
> And i don't think it is hard.
> 
> The mayor stumbling block IMHO is to recognize that unlike maybe 25 years
> ago when
> ISO8473 was around, we nowadays IMHO do NOT have any issues high-speed
> hardware forwarding anymore to have headers with different length address,
> but using a unified forwarding plane logic and hopefully even much more
> shared control plane as eventoday acros IPv4 and IPv6.
> 
> If we just had those variable length adddresses, all the discussions about
> SRH alternatives would go away because each address element could have a
> forwarding component as short/long as necessary for the network and as
> many programmabiliy bits behind it as desired - for this element.
> Likewise, i would venture to guess that a lot of the low-power network
> solutions would become much simpler and efficient by aleviating the need
> to compress addresses.
> 
> Cheers
>     Toerless
> 
> On Wed, Mar 03, 2021 at 11:05:42AM +0000, Pascal Thubert (pthubert) wrote:
> > Hello Stewart, Brian and Toerless:
> >
> > Interestingly RFC 8138 took one step in that direction. Yes you???re
> going to need a new Ethertype but it???s still IPv6 I. That is is
> expressed as a compression not a modification of IPv6.
> >
> >  In the compressed form the header starts with the next hops, the
> destination and SRH being indiscriminated, the destination is just the
> first of the list. The size is variable but each hop is at most 128 bits.
> Because the SRH could encode SRv6 you can already go a long way with this.
> >
> > If that can help you do what you want, I m happy to explain more...
> >
> > Keep safe.
> >
> > Pascal
> >
> > Le 2 mars 2021 à 13:33, Stewart Bryant <stewart.bryant@gmail.com> a
> écrit :
> >
> > ???
> >
> > On 1 Mar 2021, at 20:08, Brian E Carpenter
> <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
> >
> >
> > It would take but a minute to design a longer-address mechanism for
> IPv6, although I don't have space to include it in the margin of this
> email**. But it would take many years for it to be widely implemented and
> deployed, during which time the Internet would be opaque to such
> addresses.
> >
> >
> > ** Basically, use a prefix such as fb00::/8 to indicate an extended
> address.
> >
> > Hi Brian
> >
> > Basically I think that this fails the backwards compatibility text.
> >
> > It is perfectly legitimate to write an IPv6 forwarder as follows:
> >
> > If MACaddress == me and MACtype == IPv6 pass packet to IPv6 forwarder
> >
> > In IPv6 forwarder:
> >
> > If version == IPv6 and Hop Limit not exceeded send bytes 24 to 39 to
> > address lookup engine
> >
> > Wait for address result and forward packet accordingly
> >
> > Except that this forwarder would have sent a bunch of random junk to the
> ALE consisting of some of the SA and maybe some of the DA depending on
> their sizes.
> >
> > So to stop an old and legitimately designed parser being fooled you
> really have to use a new MAC type and a new version and as soon as you do
> that you might as well design the packet optimally for the job at hand.
> >
> > If the IPv6 designers had followed the strategy of both the Ethernet
> designers and the ISO8473 designers and put DA before SA then the elegant
> approach that you and others have  proposed at various times would have
> worked nicely.
> >
> > Best regards
> >
> > Stewart
> >
> >
> >
> >
> > _______________________________________________
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
> 
> --
> ---
> tte@cs.fau.de