Re: [Int-area] [Flexip] The small address use case in FlexIP

"Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com> Sat, 06 February 2021 15:45 UTC

Return-Path: <liguangpeng@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 8214C3A13D2; Sat, 6 Feb 2021 07:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Zhcj2FwxYap0; Sat, 6 Feb 2021 07:45:44 -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 F259B3A13D1; Sat, 6 Feb 2021 07:45:43 -0800 (PST)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DXxNq63ykz67lNq; Sat, 6 Feb 2021 23:42:03 +0800 (CST)
Received: from fraeml736-chm.china.huawei.com (10.206.15.217) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sat, 6 Feb 2021 16:45:38 +0100
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Sat, 6 Feb 2021 16:45:38 +0100
Received: from DGGEMM513-MBS.china.huawei.com ([169.254.4.33]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0509.000; Sat, 6 Feb 2021 23:45:27 +0800
From: "Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Dirk Trossen <dirk.trossen@huawei.com>
CC: Lin Han <lin.han@futurewei.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>, "sarikaya2012@gmail.com" <sarikaya2012@gmail.com>
Thread-Topic: [Flexip] [Int-area] The small address use case in FlexIP
Thread-Index: AQHW+9FfheTGIxxlAE6qDr/w+e0zCapJWqQAgAHpAGA=
Date: Sat, 06 Feb 2021 15:45:27 +0000
Message-ID: <6F4E6B0C717D4641A2B79BC1740D8CF4A8F9CA27@dggemm513-mbs.china.huawei.com>
References: <727cfc33b0cb41acaeacc21a33c39d4d@huawei.com> <B697AF2A-8B98-4CB8-ACDC-688058276F43@gmail.com> <854102e6d17441fcabb16748245b18af@huawei.com> <8EFF0C7E-32B2-4C30-B27A-6C165BA7A30B@gmail.com>
In-Reply-To: <8EFF0C7E-32B2-4C30-B27A-6C165BA7A30B@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.162.77]
Content-Type: multipart/alternative; boundary="_000_6F4E6B0C717D4641A2B79BC1740D8CF4A8F9CA27dggemm513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/LBVE7_Wlw7YhAQu9TjRyEZ5MiCM>
Subject: Re: [Int-area] [Flexip] The small address use case in FlexIP
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: Sat, 06 Feb 2021 15:45:47 -0000

Hi Stewart, Dirk and all,

These drafts are significant work which I don't think there is any conflict view to draft-jia-scenarios-flexible-address-structure. It's hard for most people to reach rough consensus on so many aspects of problem statement at the same time. So it's worth to focus on one of the most obvious ones, like encapsulation efficiency that mainly causes by the long address.

It's observed that 6lowpan approaches have solved problem at some extend, whether shall we discuss a little broad. Which means some scenarios that cannot be covered by current IP or 6lowpan mechanism. The first step may be find them and state the concrete problems, then reach rough consensus. This achievement needs further discussion and potential contributions by everyone here, thus induce to some updates to those drafts.

Best Regards,
Guangpeng

From: Flexip [mailto:flexip-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Saturday, February 6, 2021 2:25 AM
To: Dirk Trossen <dirk.trossen@huawei.com>
Cc: Lin Han <lin.han@futurewei.com>; draft-jia-flex-ip-address-structure@ietf.org; int-area <int-area@ietf.org>; flexip@ietf.org; Jiayihao <jiayihao@huawei.com>; draft-jia-scenarios-flexible-address-structure@ietf.org; Stewart Bryant <stewart.bryant@gmail.com>; sarikaya2012@gmail.com
Subject: Re: [Flexip] [Int-area] The small address use case in FlexIP

Dear Dirk

There may be some material that you can use from

https://tools.ietf.org/html/draft-bryant-arch-fwd-layer-uc-01
And
https://datatracker.ietf.org/doc/draft-bryant-arch-fwd-layer-ps/

- Stewart


On 5 Feb 2021, at 15:12, Dirk Trossen <dirk.trossen@huawei.com<mailto:dirk.trossen@huawei.com>> wrote:

Stewart, all,

As Yihao pointed out, we are working on an update to the draft to focus the discussion on the communication scenarios and problems arising in those scenarios. In that sense, we agree with your desire for a holistic discussion and see this upcoming update as one of the next towards that.

With that in mind, I suggest that we continue the discussions after this upcoming update since it is not the intention at this stage to propose any solutions or constrain any thinking about solutions but to agree that problems may exist that will need to be addressed.

Best regards,

Dirk

From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: 05 February 2021 15:59
To: Jiayihao <jiayihao@huawei.com<mailto:jiayihao@huawei.com>>
Cc: Lin Han <lin.han@futurewei.com<mailto:lin.han@futurewei.com>>; draft-jia-flex-ip-address-structure@ietf.org<mailto:draft-jia-flex-ip-address-structure@ietf.org>; int-area <int-area@ietf.org<mailto:int-area@ietf.org>>; flexip@ietf.org<mailto:flexip@ietf.org>; sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>; draft-jia-scenarios-flexible-address-structure@ietf.org<mailto:draft-jia-scenarios-flexible-address-structure@ietf.org>
Subject: Re: [Int-area] The small address use case in FlexIP





On 5 Feb 2021, at 12:06, Jiayihao <jiayihao@huawei.com<mailto:jiayihao@huawei.com>> wrote:

- Indeed, the network scale of limited domain is supposed to be less that IPv6, but it doesn't mean the address space should be strictly less than 128-bit. If the space of the address is abundant enough, the public key could be embedded without truncation (compare to CGA in IPv6) for certain security purpose.

Interesting, what are the advantages in adding the signature of the address in the address as opposed to carrying it in a different field?

The disadvantage is that you bind the address to the signature algorithm which you would not want to do since you would expect to change the signature algorithm during the lifetime of the protocol.

Also would you really want to feed the signature into the longest match engine? Of course you could and there are some advantages in that you look up both the address and it signature, but I think you loose longest match capability and you significantly increase the size of the TCAM or other FIB design memory, and that memory is very expensive as it determines the line rate of the forwarder.

So this points back to the need for a holistic discussion of what we are trying to achieve, the extent to which modifying existing protocols satisfies that need, and whether (given the presupposed need for a gateway) we should be looking for a single protocol, a family of protocols, or an adaptable protocol.

I don’t think we can design the addressing system in the absence of a discussion on those points.

Best regards

Stewart