[Teas] A suspected issue was found in the TE tunnel draft and a small comment about path computation policy
yuchaode <yuchaode@huawei.com> Fri, 08 December 2023 07:19 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 5041AC14CF05; Thu, 7 Dec 2023 23:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 UpvPV7ljsizS; Thu, 7 Dec 2023 23:19:02 -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 E26AEC14CEFD; Thu, 7 Dec 2023 23:19:01 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SmjCn6W8Xz6J9Zq; Fri, 8 Dec 2023 15:18:13 +0800 (CST)
Received: from lhrpeml500006.china.huawei.com (unknown [7.191.161.198]) by mail.maildlp.com (Postfix) with ESMTPS id 8BD23140133; Fri, 8 Dec 2023 15:18:58 +0800 (CST)
Received: from canpemm500003.china.huawei.com (7.192.105.39) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Dec 2023 07:18:57 +0000
Received: from canpemm500002.china.huawei.com (7.192.104.244) by canpemm500003.china.huawei.com (7.192.105.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 8 Dec 2023 15:18:54 +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.035; Fri, 8 Dec 2023 15:18:54 +0800
From: yuchaode <yuchaode@huawei.com>
To: "teas@ietf.org" <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>
Thread-Topic: A suspected issue was found in the TE tunnel draft and a small comment about path computation policy
Thread-Index: AdoppWQbunZDau86SviSra2x8PgtKA==
Date: Fri, 08 Dec 2023 07:18:54 +0000
Message-ID: <7ffca8743da44f0890ac84a0e9c25008@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.46.217]
Content-Type: multipart/related; boundary="_004_7ffca8743da44f0890ac84a0e9c25008huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-16ydYg9dcRgca4AW9mYF0HDT4s>
Subject: [Teas] A suspected issue was found in the TE tunnel draft and a small comment about path computation policy
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: Fri, 08 Dec 2023 07:19:07 -0000
Hi TEAS Working Group, I found a suspected issue in the latest version of TE Tunnel draft by accident. Please the authors have a look. It seems like that the previous "p2p-primary-paths" container was renamed into "primary-paths". But in the example of session 12.5(https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-34#section-12.5-2), the URL still points to "p2p-primary-paths" structure while the response is using "primary-path" structure. Just like the screenshot shows: [cid:image001.png@01DA29E6.4EDFFD10] I think the authors probably missed to change the URL. Please the authors check! This issue was found when I was doing some research on the path computation policy. I am using an old version, and I was trying to find the "p2p-primary-paths" and then found there was only one case matched. And I noticed that this "p2p-primary-path" structure was renamed by some previous versions. This is an accidental discovery and does not intentionally delay the release of TE tunnels. BTW, I found that all the primary & secondary paths and their reverse paths can support to specify different path computation policy. This capability is great. But what I met is people only wanted to specify a unified path computation policy for all the paths. So is it possible to specify the path computation policy only in the primary-path, and the other paths use this policy by default if there is no specific policy specified on their paths. If the authors agree with this proposal, can some more description be added in the draft or in the model to make it clear? Thanks! B.R. Chaode