[Idr] Re: draft-chen-idr-bgp-ls-sr-policy-nrp-08 - updates needed prior to WG adoption call
chen.ran@zte.com.cn Tue, 25 June 2024 01:51 UTC
Return-Path: <chen.ran@zte.com.cn>
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 90670C14F706 for <idr@ietfa.amsl.com>; Mon, 24 Jun 2024 18:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=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, UNPARSEABLE_RELAY=0.001, 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 giUfg6XSsnEi for <idr@ietfa.amsl.com>; Mon, 24 Jun 2024 18:51:53 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9753C14F6FF for <idr@ietf.org>; Mon, 24 Jun 2024 18:51:45 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4W7SVj44Wdz4xPBc; Tue, 25 Jun 2024 09:51:41 +0800 (CST)
Received: from njy2app04.zte.com.cn ([10.40.12.64]) by mse-fl1.zte.com.cn with SMTP id 45P1pXIH029463; Tue, 25 Jun 2024 09:51:33 +0800 (+08) (envelope-from chen.ran@zte.com.cn)
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid203; Tue, 25 Jun 2024 09:51:34 +0800 (CST)
Date: Tue, 25 Jun 2024 09:51:34 +0800
X-Zmail-TransId: 2afb667a22a64ab-a75c6
X-Mailer: Zmail v1.0
Message-ID: <2024062509513489519m9UJpynrsbdHKCJkcZY@zte.com.cn>
In-Reply-To: <20240624095557609oI2QE1hBM6URiPWfUYvdb@zte.com.cn>
References: CO1PR08MB66115B06498AB0B68921FA66B3CC2@CO1PR08MB6611.namprd08.prod.outlook.com,20240624095557609oI2QE1hBM6URiPWfUYvdb@zte.com.cn
Mime-Version: 1.0
From: chen.ran@zte.com.cn
To: shares@ndzh.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 45P1pXIH029463
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 667A22AD.000/4W7SVj44Wdz4xPBc
Message-ID-Hash: LWPSYSRDCBHPUMWIDVD2JIBP3EPV5LTQ
X-Message-ID-Hash: LWPSYSRDCBHPUMWIDVD2JIBP3EPV5LTQ
X-MailFrom: chen.ran@zte.com.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: idr@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: draft-chen-idr-bgp-ls-sr-policy-nrp-08 - updates needed prior to WG adoption call
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LI_J2mPQhnaF1VS_TSGXA3V2qDo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>
Hi Sue, Thank you very much for your valuable comments at the meeting and this summary. Sorry for the late reply. Please see inline... Best Regards, Ran From: SusanHares <shares@ndzh.com> To: idr@ietf.org <idr@ietf.org>; Date: 2024年06月16日 18:31 Subject: [Idr] draft-chen-idr-bgp-ls-sr-policy-nrp-08 - updates needed prior to WG adoption call _______________________________________________ Idr mailing list -- idr@ietf.orgTo unsubscribe send an email to idr-leave@ietf.org On May 20, 2024 IDR interim, the discussion on draft-chen-idr-bgp-ls-sr-policy-nrp-05 was given. I appreciate the updates that the authors made in version -06, -07, and -08.txt The following things do not seem to be resolved in draft-chen-idr-bgp-ls-sr-policy-nrp-08.txt: : What is the relationship between the information in this draft and the information in draft-ietf-spring-resource-aware-segments? Ran: Due to the resource SID mechanism defined in the draft-ietf-spring-resource-aware-segments, the headend node does not have information about the relationship between CP and NRP IDs, so it currently does not consider reporting the relationship between CP and NRP ID. The current draft is only for the scenario where data packets carry NRP ID, The NRP ID is used with the normal SR SID as the resource used will be indicated by the NRP-ID. An SR Policy candidate path (CP) may be instantiated with a specific NRP on the headend node via a local configuration, PCEP, or BGP SR Policy signaling. Then the state and attributes of the NRP associated with the candidate path of SR policy can be distributed to the controller. 2. Discussion of how what state the NRP-ID specifically links to and helps align. Ran: A Network Resource Partition (NRP) is a collection of allocated network resources in a network. The SR policythe forwarding path of the data packet, and the NRP ID indicates the reserved resources along the path specified by the SR policy. By associating the SR policy with a specific NRP, the forwarding path and resource reservation along the path are ensured. BGP-LS reports the association between CP and NRP-ID, which is used to synchronize the association information between CP and NRP-ID. R Discussion of whether this draft applies to SR-MPLS Ran: Yes, this draft applies to SR-MPLS and will be clarified in the draft. Cheerily, Sue Hares Discussion at 5/20/2024 interim – detailed minutes https://datatracker.ietf.org/meeting/interim-2024-idr-04/materials/minutes-interim-2024-idr-04-202405201400-01 ============================== 1. SR Policies Extensions for Network Resource Partition in BGP-LS [15 minutes] draft-chen-idr-bgp-ls-sr-policy-nrp-05 [Ran Chen] [ ] Question 1: Why does the headend need to report the configuration and the states of SR Policy carrying headend information? Joel Halpern: What is the relationship between the information in this draft and the information in draft-ietf-spring-resource-aware-segments? Ran: This draft is about the mechanism in which NRP-ID is carried in the data packet. Joel: According to the draft-ietf-spring-resource-aware-segments draft, the resource SIDs are the only SID identifiers. It would seem that this draft needs to align with the SID identifiers mentioned in this draft, and as far as I can tell it does not. Note: draft-ietf-spring-resource-aware-segments specifies PeerAdj SIDs and resource-aware Prefix SIDS. Sue: I did not understand the resolution to the first problem in Shepherd review. I understand that the headend needs to report policy. What I do not understand is why the headend needs to report configuration. Ran: One of the most important functions is to verify the consistent configuration of the headend. Perhaps the headend can be configured by netconf. The information in BGP indicates what policy has been selected for use. Sue: So, what does the NRP-ID add to that alignment of states? Ran: This NRP-ID is an indication of the state. Sue: It only gives an ID and does not provide additional state. Perhaps you could explain this further on the mail list. Jie: I want to respond to Joel's comment about the draft-ietf-spring-resource-aware-segments draft. When the SR Policy is created on the headend, we need to have identify the [resources] associated with the SR Policy [tunnel]. We have another draft that associates the NRP with SR Policy creation (draft-ietf-idr-sr-policy-nrp). Joel: What spring draft has been adopted that describes that mechanism? As far as I know, the adopted mechanisms for SR with NRP (eithe rmPLS or SRv6) do not use a separate NRP-ID. This draft and draft-ietf-idr-sr-policy-nrp do not explain the relationship between the NRP-ID. Jie: The NRP-ID calculation is not in spring WG, but in 6man (NRP calculation approach). It is not dependent on the resource segment approach. It is a complementary approach. The NRP-ID in the packet would be used for legacy/traditional segments path and NRP-ID is to indicate the resource. Joel Halpern 6man work on NRP-IDs would still need to explain the relationship to SRv6. And doesn't seem to apply to SR-MPLS at all. Sue: Authors should explain how NRP relates or does not relate to SR-MPLS.