[Idr] Re: draft-ietf-idr-sr-te-policy-attr-00

liu.yao71@zte.com.cn Tue, 03 September 2024 06:06 UTC

Return-Path: <liu.yao71@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 E43B5C15199A for <idr@ietfa.amsl.com>; Mon, 2 Sep 2024 23:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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] 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 jF4XvtyUhmfK for <idr@ietfa.amsl.com>; Mon, 2 Sep 2024 23:06:53 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3C3C151552 for <idr@ietf.org>; Mon, 2 Sep 2024 23:06:49 -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 4WyZrj2L7Xz8QrkZ; Tue, 3 Sep 2024 14:06:45 +0800 (CST)
Received: from njy2app03.zte.com.cn ([10.40.13.14]) by mse-fl2.zte.com.cn with SMTP id 48366ed1084573; Tue, 3 Sep 2024 14:06:40 +0800 (+08) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njy2app02[null]) by mapi (Zmail) with MAPI id mid203; Tue, 3 Sep 2024 14:06:42 +0800 (CST)
Date: Tue, 03 Sep 2024 14:06:42 +0800
X-Zmail-TransId: 2afa66d6a772ffffffffc95-bdd04
X-Mailer: Zmail v1.0
Message-ID: <20240903140642595z48JHqjKt84GCemmnmQpp@zte.com.cn>
In-Reply-To: <CO1PR08MB66118644F1D0E2A46D48715AB3912@CO1PR08MB6611.namprd08.prod.outlook.com>
References: CO1PR08MB66118644F1D0E2A46D48715AB3912@CO1PR08MB6611.namprd08.prod.outlook.com
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: shares@ndzh.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 48366ed1084573
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 66D6A775.003/4WyZrj2L7Xz8QrkZ
Message-ID-Hash: WLCXPKLFPUWI7WZY2WBHPLSJQRID52UK
X-Message-ID-Hash: WLCXPKLFPUWI7WZY2WBHPLSJQRID52UK
X-MailFrom: liu.yao71@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, gyan.s.mishra@verizon.com
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: draft-ietf-idr-sr-te-policy-attr-00
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/aK5VIHWGlndiBdM3CH08-NKTIn0>
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,

Thanks a lot for all the work you've done for this draft!  We'll update the draft based on your shepherd review .

Are you planning any technical changes to this draft? No.

Do you have implementations? Not yet.

Are you ready for WG LC? I think not.


About the codepoints for the TLVs, I think separating  the code space for new segment types and other additional features is reasonable, but this may effect vendors who have already implemented or decided to implement these features using the early allocation codes.  
So from my point of view, the allocation method should be discussed and decided as soon as possible to mitigate the impact on the implementation.

Regards,
Yao




Original


From: SusanHares <shares@ndzh.com>
To: idr@ietf.org <idr@ietf.org>;
Cc: 刘尧00165286;彭少富10053815;Gyan Mishra <gyan.s.mishra@verizon.com>;
Date: 2024年09月02日 01:03
Subject: draft-ietf-idr-sr-te-policy-attr-00



Yao, Shaofu, and Gyan: 
 
Thank you for your hard work on draft-ietf-idr-sr-te-policy-attr-0.txt 
 
Below you will find a shepherd review of draft-ietf-idr-sr-te-policy-attr-00.txt. 
 
Just a warning, we will be discussing the preliminary allocations during 
IDR interim on September 9th, 2024. 
 
It appears that we have Segment lists (L, M, N, O) clashing with the 
Path Segment, Reserve Path segment, Metric, and Segment List Identifier.  
I think I should reassign Path Segment, Reserve Path segment, Metric, 
and Segment List Identifier to a different TLV range (30+). 
 
Let me know what you think about this change. 
As part of the status for the September 9th, 2024 meeting, 
Please let me know: 
 

Are you planning any technical changes to this draft? 

Do you have implementations? 

Are you ready for WG LC? 


 
Cheerily, Sue Hares 
 
 
Shepherd report for draft-ietf-idr-sr-te-policy-attr
 
Status: WG draft 
implementations: unknown 
allocation status: preliminary (upcoming issue)
WG LC status: unknown 
 
 
Technical: 
Issue-1: Section 3.1, SR Algorithm text, A-Flag setting 
 
old text:/
   SR Algorithm: 1 octet specifying SR Algorithm as described in
   Section 3.1.1 of [RFC8402]) when A-Flag as defined in
   [I-D.ietf-idr-bgp-sr-segtypes-ext] is present.  SR Algorithm is used
   by SRPM as described in Section 4 of [RFC9256]).  When A-Flag is not
   encoded, this field SHOULD be set to zero on transmission and MUST be
   ignored on receipt./
New text:/ 
   SR Algorithm: 1 octet specifying SR Algorithm as described in
   Section 3.1.1 of [RFC8402]) when A-Flag as defined in
   [I-D.ietf-idr-bgp-sr-segtypes-ext] is present.  SR Algorithm is used
   by SRPM as described in Section 4 of [RFC9256]).  When A-Flag is not
   set, this field SHOULD be set to zero on transmission and MUST be
   ignored on receipt./
  
Issue-2, Section 3.2, SR algorithm text, A-Flag setting. 
 
Make the same chnage as in section 3.1 
 
Issue-3, Section 3.3, SR algorithm text, A-Flag setting. 
 
Make the same chnage as in section 3.1 
 
Issue-3, Section 3.4, SR algorithm text, A-Flag setting. 
 
Make the same chnage as in section 3.1 
 
 
 
Editorial: 
 
NIT-1, SEction 1, paragraph 2, sentence 1
 
Old text: 
  [I-D.ietf-idr-sr-policy-safi] specifies the way to use BGP to
   distribute one or more of the candidate paths of an SR Policy to the
   headend of that policy.   
   
New text:/
  [I-D.ietf-idr-sr-policy-safi] specifies the way to use BGP to
   distribute information about one or more of the candidate paths of an SR Policy to the
   headend of that policy. / 
   
   
NIT-2: setion 1, paragraph 5, sentence 1
old text:/
[I-D.ietf-lsr-algorithm-related-adjacency-sid] complements that,
   besides the SR-MPLS prefix SID, the algorithm can be also included as
   part of an SR-MPLS Adjacency-SID advertisement, in scenarios where
   multiple algorithm share the same link resource. /
   
new text:/
[I-D.ietf-lsr-algorithm-related-adjacency-sid] comments that,
   besides the SR-MPLS prefix SID, the algorithm can be also included as
   part of an SR-MPLS Adjacency-SID advertisement in scenarios where
   multiple algorithm share the same link resource. /
   
 
 NIT-3: SEction 3.1, sentence 1, editorial

 Old text:/
    This type allows for identification of an Adjacency SID or BGP Peer
   Adjacency SID (as defined in [RFC8402] ) SR-MPLS label for point-to-
   point links including IP unnumbered links/
   
 first suggestion:/
     This type allows for identification of an Adjacency SID or BGP Peer
   Adjacency SID (as defined in [RFC8402] ) as an SR-MPLS label for point-to-
   point links including IP unnumbered links/
   
   comment; Are you trying to use an SR-MPLS label as an Adjacency SID or 
   a BGP Peer Adjaency SID or something else?  Please reword the sentence.