[Idr] 答复: draft-chen-idr-bgp-ls-sr-policy-nrp-09 - WG adoption call (7/22/2024 to 8/9/2024)

zhao.detao@zte.com.cn Fri, 26 July 2024 01:32 UTC

Return-Path: <zhao.detao@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 199D7C1CAF28 for <idr@ietfa.amsl.com>; Thu, 25 Jul 2024 18:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.193
X-Spam-Level:
X-Spam-Status: No, score=-4.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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 5Vj-vtETyzmz for <idr@ietfa.amsl.com>; Thu, 25 Jul 2024 18:32:44 -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 614F5C1840C7 for <idr@ietf.org>; Thu, 25 Jul 2024 18:32:43 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (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 4WVVcT3p4Qz5B1Kq; Fri, 26 Jul 2024 09:32:41 +0800 (CST)
Received: from njb2app05.zte.com.cn ([10.55.22.121]) by mse-fl2.zte.com.cn with SMTP id 46Q1WcT4006664; Fri, 26 Jul 2024 09:32:38 +0800 (+08) (envelope-from zhao.detao@zte.com.cn)
Received: from mapi (njy2app04[null]) by mapi (Zmail) with MAPI id mid201; Fri, 26 Jul 2024 09:32:38 +0800 (CST)
Date: Fri, 26 Jul 2024 09:32:38 +0800
X-Zmail-TransId: 2afc66a2fcb622d-f56ba
X-Mailer: Zmail v1.0
Message-ID: <20240726093238948ED3H-pEhDS9pA4g3FxhmG@zte.com.cn>
In-Reply-To: <CO1PR08MB6611D8EC1AC1698E609F439AB3A92@CO1PR08MB6611.namprd08.prod.outlook.com>
References: CO1PR08MB6611D8EC1AC1698E609F439AB3A92@CO1PR08MB6611.namprd08.prod.outlook.com
Mime-Version: 1.0
From: zhao.detao@zte.com.cn
To: shares@ndzh.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 46Q1WcT4006664
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66A2FCB9.001/4WVVcT3p4Qz5B1Kq
Message-ID-Hash: F4P2EZDPZVUJWFXCO5CPTJ34EST7Y4XO
X-Message-ID-Hash: F4P2EZDPZVUJWFXCO5CPTJ34EST7Y4XO
X-MailFrom: zhao.detao@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] 答复: draft-chen-idr-bgp-ls-sr-policy-nrp-09 - WG adoption call (7/22/2024 to 8/9/2024)
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/pDEZXqranqSltiUc9vd0sCjUx0E>
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 and WG,
    I support the adoption of this draft as a co-author, and i am not aware of any IPR related to this draft.



Is the addition of NRP-ID information to SR BGP-LS information valuable to networks? 
// Yes. , Through the NRP-ID information, the operator  can learn about the network resource  on the SR Policy CP.


Does the draft clearly specify the TLV? 
//Yes, it`s clear


Are there any security concerns about reporting NRP-ID?
 //no security  concerns


Is this document ready to adopt?
// Yes. It's ready.









赵德涛
软件平台开发一部/有线研究院/有线产品经营部
 
中兴通讯股份有限公司
南京市紫荆花路68号南研一期, 邮编: 210012
T: +86 15951883174      M: +86 15951883174
E: zhao.detao@zte.com.cn




Original


From: SusanHares <shares@ndzh.com>
To: idr@ietf.org <idr@ietf.org>;
Date: 2024年07月23日 09:42
Subject: [Idr] draft-chen-idr-bgp-ls-sr-policy-nrp-09 - WG adoption call (7/22/2024 to 8/9/2024)

_______________________________________________
Idr mailing list -- idr@ietf.org
To unsubscribe send an email to idr-leave@ietf.org
 

This begins a 2+ week WG adoption call (7/22 to 8/9/2024)for
draft-chen-bgp-ls-sr-policy-nrp-09.txt.
(https://datatracker.ietf.org/doc/draft-chen-idr-bgp-ls-sr-policy-nrp/) 
 
The authors should respond to this WG adoption call with an email with the IPR statement.
 
Document focus:
This document defines a new TLV in BGP-LS to report the NRP-ID
associated with an SR Candidate Policy Path (CP).
 
Links to Spring: During the 5/20/2024 interim, the following question was raised:
What is the relationship between the information in this draft and the information in draft-ietf-spring-resource-aware-segments?
 
Ran answered the following:
Due to the resource SID mechanism defined in the draft-ietf-spring-resource-aware-segments
(https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/)

the headend node does not have information about the relationship between
Candidate Path (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.
 
In your discussion, please consider:
 

Is the addition of NRP-ID information to SR BGP-LS information valuable to networks?

Does the draft clearly specify the TLV?

Are there any security concerns about reporting NRP-ID?

Is this document ready to adopt?


 
Cheerily, Sue