[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.
- [Idr] draft-ietf-idr-sr-te-policy-attr-00 Susan Hares
- [Idr] Re: draft-ietf-idr-sr-te-policy-attr-00 liu.yao71