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

Jiayihao <jiayihao@huawei.com> Mon, 08 February 2021 09:39 UTC

Return-Path: <jiayihao@huawei.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 152433A152C; Mon, 8 Feb 2021 01:39:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 RgSXoVl4JviX; Mon, 8 Feb 2021 01:39:14 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25E83A152B; Mon, 8 Feb 2021 01:39:13 -0800 (PST)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DZ15l1MvRz67m0f; Mon, 8 Feb 2021 17:32:43 +0800 (CST)
Received: from dggemi711-chm.china.huawei.com (10.3.20.110) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Mon, 8 Feb 2021 10:39:11 +0100
Received: from dggemi759-chm.china.huawei.com (10.1.198.145) by dggemi711-chm.china.huawei.com (10.3.20.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Mon, 8 Feb 2021 17:39:09 +0800
Received: from dggemi759-chm.china.huawei.com ([10.1.198.145]) by dggemi759-chm.china.huawei.com ([10.1.198.145]) with mapi id 15.01.2106.006; Mon, 8 Feb 2021 17:39:09 +0800
From: Jiayihao <jiayihao@huawei.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
CC: "draft-jia-flex-ip-address-structure@ietf.org" <draft-jia-flex-ip-address-structure@ietf.org>, "draft-jia-scenarios-flexible-address-structure@ietf.org" <draft-jia-scenarios-flexible-address-structure@ietf.org>, int-area <int-area@ietf.org>
Thread-Topic: Using ISO8473 as a network layer to carry flexible addresses
Thread-Index: AQHW+isammJINdBrhE6dfBbprA4VBKpOA0yA
Date: Mon, 08 Feb 2021 09:39:09 +0000
Message-ID: <3dd5a712bd2b4fdbb882d860ab2ece82@huawei.com>
References: <CDB32FF0-5CE0-4C0F-B1D1-B6BFEA42E817@gmail.com>
In-Reply-To: <CDB32FF0-5CE0-4C0F-B1D1-B6BFEA42E817@gmail.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.167.116]
Content-Type: multipart/alternative; boundary="_000_3dd5a712bd2b4fdbb882d860ab2ece82huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Xy2QSfAKnyWN1TKGeGf6p7OYGxU>
Subject: [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: Mon, 08 Feb 2021 09:39:16 -0000

Hi Stewart,

I followed the ISO 8473 specification and find that a “flexible address structure” is similar to it.

ISO 8473 has a variable address length with a <len> field, while for the flexibility described in the “flexible address structure” draft, the flexibility refer to both a) variable length; 2) new semantics. ISO 8473 do cover the variable length, but semantics is not mentioned in it. So a new semantics carried address could be a main difference compared to ISO 8473.

Thanks,
Yihao

发件人: Stewart Bryant [mailto:stewart.bryant@gmail.com]
发送时间: 2021年2月3日 20:50
收件人: draft-jia-scenarios-flexible-address-structure@ietf.org; draft-jia-flex-ip-address-structure@ietf.org; flexip@ietf.org; int-area <int-area@ietf.org>
抄送: Stewart Bryant <stewart.bryant@gmail.com>
主题: Using ISO8473 as a network layer to carry flexible addresses

Re drafts:


https://datatracker.ietf.org/doc/draft-jia-scenarios-flexible-address-structure/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jia-scenarios-flexible-address-structure%2F&data=04%7C01%7Ckiranm%40futurewei.com%7C95b5d102feaf4674ab8408d8c7972448%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637478799262464227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yDi0mFnbU60nFC5PJC%2BAAWVIdSMT%2FY8UO0XIiK3J4iI%3D&reserved=0>

https://datatracker.ietf.org/doc/draft-jia-flex-ip-address-structure/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-jia-flex-ip-address-structure%2F&data=04%7C01%7Ckiranm%40futurewei.com%7C95b5d102feaf4674ab8408d8c7972448%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637478799262464227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XB9VFEQiaa0ZMjG5BuF%2FPeQnvFcmGgfY0%2Bye4s7CSoA%3D&reserved=0>

Since the authors are interested in network layer protocols that support multiple address types and multiple address lengths, I wonder if they have considered using ISO8473 as the bearer and developing that to their needs?

ISO 8473 is also known as ITU X233 (it costs money to download from ISO, but seems to be free from the ITU-T site). It is an in force and actually well deployed network layer protocol with many similar characteristics to IPv6. The reason that it is deployed is that it is used to support SS7. It also has a very widely deployed link-state IGP since IS-IS was developed to support ISO8474 and later adapted to support IP late run its life.

It was one of the contenders for IPv4 replacement, and so there RFCs that authors may study: RFC994 is a copy of the late version of the spec in RFC format. Then there is RFC1195 where Ross Callon shows how it works in an IETF environment carrying IETF transport protocols and this eventually became RFC1347 (TUBA), which whilst whilst marked Historic in the IETF RFC collection is almost certainly still implementable since the base network layer protocol is still an active standard.

It would need some work to determine the applicability of the protocol to your application and the feasibility of adding the necessary new address types (due to crowding of the existing address registry) and any other extensions that you might need.

Note BTW that it supports source routing functionality and so ought to be usable in an SR environment should that be needed.

There would also need to be work to see how feasible it would be to implement in a modern NPU, though having implemented it in a hardware assisted microcode platform that is quite similar to a modern NPU back in the 90s and having got quite creditable performance I think it is feasible to run this on modern hardware including repurposing the existing longest match engine to look up a number of your new address formats.

There are a bunch of specs here for your convenience although I have not studied the list in detail

http://www.networksorcery.com/enp/protocol/clnp.htm

Best regards

Stewart