[Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy

Zhuangshunwan <zhuangshunwan@huawei.com> Tue, 26 December 2023 12:18 UTC

Return-Path: <zhuangshunwan@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79587C14F5F8 for <idr@ietfa.amsl.com>; Tue, 26 Dec 2023 04:18:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.894
X-Spam-Level:
X-Spam-Status: No, score=-6.894 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, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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 lwHfK_hicD4Y for <idr@ietfa.amsl.com>; Tue, 26 Dec 2023 04:18:07 -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 7BBF5C14F5F4 for <idr@ietf.org>; Tue, 26 Dec 2023 04:18:07 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Sztzb3qf8z6JB2B for <idr@ietf.org>; Tue, 26 Dec 2023 20:16:27 +0800 (CST)
Received: from lhrpeml500001.china.huawei.com (unknown [7.191.163.213]) by mail.maildlp.com (Postfix) with ESMTPS id 750EF140B63 for <idr@ietf.org>; Tue, 26 Dec 2023 20:18:04 +0800 (CST)
Received: from kwepemi100002.china.huawei.com (7.221.188.188) by lhrpeml500001.china.huawei.com (7.191.163.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Dec 2023 12:18:03 +0000
Received: from kwepemi500002.china.huawei.com (7.221.188.171) by kwepemi100002.china.huawei.com (7.221.188.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 26 Dec 2023 20:18:01 +0800
Received: from kwepemi500002.china.huawei.com ([7.221.188.171]) by kwepemi500002.china.huawei.com ([7.221.188.171]) with mapi id 15.01.2507.035; Tue, 26 Dec 2023 20:18:01 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Mail regarding draft-ietf-idr-segment-routing-te-policy
Thread-Index: Ado38HEwremPhizlS0WvTIqroErgaw==
Date: Tue, 26 Dec 2023 12:18:01 +0000
Message-ID: <2e6eeec0a3d84172840b9de61109e497@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.95]
Content-Type: multipart/alternative; boundary="_000_2e6eeec0a3d84172840b9de61109e497huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mCTvPKQN16WdRgbN_ZQOtnAJqbs>
Subject: [Idr] Mail regarding draft-ietf-idr-segment-routing-te-policy
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Dec 2023 12:18:11 -0000

Dear Co-Authors,

Thank you for writing a very useful document! I have a question that need your help.

Multiple Sub-TLVs, such as the Policy Candidate Path Name Sub-TLV, are defined as follows:
"
The Policy Candidate Path Name sub-TLV is optional and it MUST NOT appear more than once in the SR Policy encoding.
"

What should we do if a Sub-TLV presents more than once?

Per section 5. Error Handling and Fault Management, should the "treat-as-withdraw" strategy be applied?


When we refer to the PCEP SR Policy draft (draft-ietf-pce-segment-routing-policy-cp-12 - PCEP extension to support Segment Routing Policy Candidate Paths<https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/>), it is described in section 4.2 as follows:
"
Unless specifically stated otherwise, the TLVs listed in the following sub-sections are assumed to be single instance. Meaning, one instance of the TLV SHOULD be present in the object and only the first instance of the TLV SHOULD be interpreted and subsequent instances SHOULD be ignored.
"

Could BGP SR Policy applies the same strategy as PCEP SR Policy?

Thanks,
Shunwan