[Teas] Discussion of service path computation and TE path computation

yuchaode <yuchaode@huawei.com> Thu, 07 December 2023 01:31 UTC

Return-Path: <yuchaode@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE45C2395EE; Wed, 6 Dec 2023 17:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 q-IrXqgxoSlF; Wed, 6 Dec 2023 17:31:45 -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 3DD53C090363; Wed, 6 Dec 2023 17:31:45 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SlxSg6rvQz6K5lC; Thu, 7 Dec 2023 09:26:43 +0800 (CST)
Received: from frapeml500006.china.huawei.com (unknown [7.182.85.219]) by mail.maildlp.com (Postfix) with ESMTPS id 40DF6140D96; Thu, 7 Dec 2023 09:31:42 +0800 (CST)
Received: from canpemm500002.china.huawei.com (7.192.104.244) by frapeml500006.china.huawei.com (7.182.85.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 7 Dec 2023 02:31:41 +0100
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.035; Thu, 7 Dec 2023 09:31:39 +0800
From: yuchaode <yuchaode@huawei.com>
To: "teas@ietf.org" <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>
CC: "'Sergio Belotti (Nokia)'" <sergio.belotti=40nokia.com@dmarc.ietf.org>, "Dieter Beller (Nokia)" <dieter.beller@nokia.com>, Italo Busi <Italo.Busi@huawei.com>
Thread-Topic: Discussion of service path computation and TE path computation
Thread-Index: AdooqJrZOgJA/oWmQxe4X7iESYTnow==
Date: Thu, 07 Dec 2023 01:31:39 +0000
Message-ID: <53a1f5c8ecb548cf9add410eecb0dcb9@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.46.217]
Content-Type: multipart/alternative; boundary="_000_53a1f5c8ecb548cf9add410eecb0dcb9huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/oeKWrnjmwTYIfn8ZDEbc0IlUu6w>
Subject: [Teas] Discussion of service path computation and TE path computation
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Dec 2023 01:31:50 -0000

Hi TEAS Working Group & Chairs,

In the meeting of IETF 118, I raised some concerns after Sergio's presentation of TE path computation draft.
On the meeting, Oscar asked me whether my scenarios had any impacts on the TE path computation model. Because of lack of enough discussion, my answer was not so sure and didn't give a clear judgement.
Yesterday, I had a meeting with some authors of TE path computation draft, including Sergio, Dieter and Italo, and we fully discussed the scenarios I raised.
Finally we reached these conclusions:

1.       The scenarios I raised are from a parts of Operators who prefer a top down approach. They would like to do a path computation from service level and more intend-based. These Operators only want to care about the configuration on the service level and let the domain controller to finish the calculation & configuration of tunnels underlay.

2.       The current TE path computation is more like a bottom up approach. People who like this approach prefer to do the calculation & provisioning layer by layer. Take transport technology for example, they would like to calculate and provision WDM tunnel at first then to OTN tunnel.

3.       These two approaches come from different kinds of configuration requirement, so they are not conflicted.

4.       It is suggested to define a new RPC in client signal draft of CCAMP to provide a top down approach of path computation. Though it will probably reuse a lot of attributes of TE tunnel, it is not needed to refine the TE path computation model.

So we considered that there is no impact on the TE path computation draft and it is also ready for LC of TE path computation draft.

Thanks
Chaode