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

张晓秋 <zhangxiaoqiu@chinamobile.com> Thu, 25 July 2024 05:10 UTC

Return-Path: <zhangxiaoqiu@chinamobile.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 17CC6C207960 for <idr@ietfa.amsl.com>; Wed, 24 Jul 2024 22:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.054
X-Spam-Level:
X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HDRS_MISSP=1.85, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=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=no 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 lM6MJgV6SQTw for <idr@ietfa.amsl.com>; Wed, 24 Jul 2024 22:10:39 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta8.chinamobile.com [111.22.67.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEC9C09C230 for <idr@ietf.org>; Wed, 24 Jul 2024 22:10:38 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee266a1de4b2af-d52b3; Thu, 25 Jul 2024 13:10:36 +0800 (CST)
X-RM-TRANSID: 2ee266a1de4b2af-d52b3
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from LAPTOP-GNT9J8OI (unknown[10.2.55.132]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee466a1de4bcc7-c47ca; Thu, 25 Jul 2024 13:10:36 +0800 (CST)
X-RM-TRANSID: 2ee466a1de4bcc7-c47ca
MIME-Version: 1.0
x-PcFlag: d3069987-75f1-429a-8d0c-ace3579565f6_5_9670
X-Mailer: PC_RICHMAIL 2.9.57
Date: Thu, 25 Jul 2024 13:10:35 +0800
From: 张晓秋 <zhangxiaoqiu@chinamobile.com>
To: Susan Hares <shares@ndzh.com>, idr@ietf.org
Message-ID: <202407251310351200177062@chinamobile.com>
Content-Type: multipart/Alternative; boundary="----=_001_NextPart1200177062_=----"
Message-ID-Hash: UKNK32QKUPYGNIBZEHM4FOWOG3HN5H7S
X-Message-ID-Hash: UKNK32QKUPYGNIBZEHM4FOWOG3HN5H7S
X-MailFrom: zhangxiaoqiu@chinamobile.com
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: 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/xuLVneynceTyurp_fhJJjojB1z8>
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 and my considerations about the questions are as follows:






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




Yes, I think it is very useful.




2. Does the draft clearly specify the TLV?




Yes, it is clear.




3. Are there any security concerns about reporting NRP-ID?




No, I have no other concerns. 




4. Is this document ready to adopt?




Yes, It is ready.













Best Regards,

Xiaoqiu



发件人:Susan Hares  <shares@ndzh.com>
收件人:"idr@ietf.org" <idr@ietf.org>
抄 送: (无)
发送时间:2024-07-23 09:41:31
主题:[Idr] draft-chen-idr-bgp-ls-sr-policy-nrp-09 - WG adoption call (7/22/2024 to 8/9/2024)

     



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