[i2rs] A question to the modeling of link in network topology

yuchaode <yuchaode@huawei.com> Tue, 06 June 2023 07:55 UTC

Return-Path: <yuchaode@huawei.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D90C15C510; Tue, 6 Jun 2023 00:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHnhkFi6NoT1; Tue, 6 Jun 2023 00:55:33 -0700 (PDT)
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 88101C15109C; Tue, 6 Jun 2023 00:55:33 -0700 (PDT)
Received: from lhrpeml500003.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Qb2nt1v43z6J79v; Tue, 6 Jun 2023 15:55:14 +0800 (CST)
Received: from canpemm100001.china.huawei.com (7.192.105.122) by lhrpeml500003.china.huawei.com (7.191.162.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 6 Jun 2023 08:55:29 +0100
Received: from canpemm500002.china.huawei.com (7.192.104.244) by canpemm100001.china.huawei.com (7.192.105.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 6 Jun 2023 15:55:27 +0800
Received: from canpemm500002.china.huawei.com ([7.192.104.244]) by canpemm500002.china.huawei.com ([7.192.104.244]) with mapi id 15.01.2507.023; Tue, 6 Jun 2023 15:55:27 +0800
From: yuchaode <yuchaode@huawei.com>
To: TEAS WG <teas@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>
Thread-Topic: A question to the modeling of link in network topology
Thread-Index: AdmYItYcRd0VEHN4TeifZnMpODhU9A==
Date: Tue, 06 Jun 2023 07:55:27 +0000
Message-ID: <612627dc89ad478d9e075da76a534a4f@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.20.224]
Content-Type: multipart/alternative; boundary="_000_612627dc89ad478d9e075da76a534a4fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/ugKbeZbzsEB-Hw3Bh__wZFb7rOA>
Subject: [i2rs] A question to the modeling of link in network topology
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jun 2023 07:55:40 -0000

Hello friends,

According to the RFC8345, links are point-to-point and unidirectional. But I can’t find too much information in the document about the reason why they should be unidirectional.
It would be very appreciated if someone can give me some hints?

A possible reason I think is maybe the authors considered bandwidth could be different in uplink and downlink, so the links should be unidirectional.
And we can also find in RFC8795 TE topology model provides lots of augmentation towards link object, including bandwidth, label-restriction .etc.

In the transport domain, I think people would prefer to manage bandwidth and tributary slot information based on port rather than link. And there is not a uplink or downlink neither. So the previous assumption is not valid.
If we remove the restriction that links are unidirectional, then the links managed by the domain controller will be reduced by half. It will relief quite a lot of pressure when managing a large scale of networks.
For the bandwidth and label-restriction information, maybe we can move it to TP, or define a RPC to let the servers retrieve by TP directly. They don’t need to find its corresponding link at first and then find those information, which is time consuming.

It is just my simple consideration, please feel free to give your comments. Thanks!

B.R.
Chaode