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

yuchaode <yuchaode@huawei.com> Wed, 07 June 2023 06:18 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 F4173C14CE4F; Tue, 6 Jun 2023 23:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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=unavailable 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 gCokCFYGI9Qy; Tue, 6 Jun 2023 23:18:55 -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 5C26FC14CE4D; Tue, 6 Jun 2023 23:18:55 -0700 (PDT)
Received: from lhrpeml100001.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QbcYv2PpXz6D97b; Wed, 7 Jun 2023 14:16:51 +0800 (CST)
Received: from canpemm500002.china.huawei.com (7.192.104.244) by lhrpeml100001.china.huawei.com (7.191.160.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 7 Jun 2023 07:18:51 +0100
Received: from canpemm500002.china.huawei.com (7.192.104.244) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 7 Jun 2023 14:18:49 +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; Wed, 7 Jun 2023 14:18:49 +0800
From: yuchaode <yuchaode@huawei.com>
To: "Davis, Nigel" <ndavis=40ciena.com@dmarc.ietf.org>
CC: 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: AdmYItYcRd0VEHN4TeifZnMpODhU9AAMECbAACGVSnA=
Date: Wed, 07 Jun 2023 06:18:49 +0000
Message-ID: <942ec6d9a858457d85ceca43cd2fdd70@huawei.com>
References: <612627dc89ad478d9e075da76a534a4f@huawei.com> <DM6PR04MB5803117DE7313CFA57C68FD1D252A@DM6PR04MB5803.namprd04.prod.outlook.com>
In-Reply-To: <DM6PR04MB5803117DE7313CFA57C68FD1D252A@DM6PR04MB5803.namprd04.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.58.9]
Content-Type: multipart/alternative; boundary="_000_942ec6d9a858457d85ceca43cd2fdd70huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/VsNTwVFaXEOvcTkuNJYMCFKqi38>
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: Wed, 07 Jun 2023 06:18:57 -0000

Hello Nigel,

Thanks for your comments.
Now I agree that there are both unidirectional and bidirectional scenario in transport technology.  If a direction or some similar attributes defined in link, it can be very helpful for supporting both scenario.

B.R.
Chaode
发件人: Davis, Nigel [mailto:ndavis=40ciena.com@dmarc.ietf.org]
发送时间: 2023年6月6日 17:17
收件人: yuchaode <yuchaode@huawei.com>; TEAS WG <teas@ietf.org>; ccamp@ietf.org; i2rs@ietf.org
主题: RE: A question to the modeling of link in network topology

HI Chaode/all,

Essentially, a vast majority of structures in transport solutions are fundamentally unidirectional. This applies to most active components and some passive components. Many passive components, such as media are omni-directional (especially free space) unless constrained as a channel (e.g., a fiber, which is bidirectional). Most usages are bidirectional where some are symmetric and some asymmetric. Many usages are multi-point bidirectional (emergent from an assembly of many unidirectional point to point components).

The TAPI model, like many other standard models, focuses on bidirectional multi-point cases but the model classes also support unidirectional cases (as they are uni/bi classes). Clearly, point to point is a degenerate form of multi-point. The arrangement of flows within the multi-point structure can be described using a rule system (a specification model) that itself degenerates to unidirectional flows for the most complex of cases. The most efficient modeling approach appears be a uni/bi-multipoint representation along with a related specification representation.

I know there have been concerns raised from time to time on the unidirectional nature of RFC8345 and suggestions that maybe it should be enhanced to cover uni/bi-multipoint. Perhaps we should discuss this further.

Regards,

Nigel

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of yuchaode
Sent: Tuesday, June 6, 2023 8:55 AM
To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>; ccamp@ietf.org<mailto:ccamp@ietf.org>; i2rs@ietf.org<mailto:i2rs@ietf.org>
Subject: [**EXTERNAL**] [CCAMP] A question to the modeling of link in network topology

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