[Idr] Re: Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11
Cheng Li <c.l@huawei.com> Wed, 25 September 2024 14:47 UTC
Return-Path: <c.l@huawei.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 6E206C157937 for <idr@ietfa.amsl.com>; Wed, 25 Sep 2024 07:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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 Mn6NC2cu1dZe for <idr@ietfa.amsl.com>; Wed, 25 Sep 2024 07:47:10 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F99C1D4A85 for <idr@ietf.org>; Wed, 25 Sep 2024 07:47:09 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XDKGP1PTjz6D94g; Wed, 25 Sep 2024 22:43:09 +0800 (CST)
Received: from frapeml100002.china.huawei.com (unknown [7.182.85.26]) by mail.maildlp.com (Postfix) with ESMTPS id 3D290140736; Wed, 25 Sep 2024 22:47:07 +0800 (CST)
Received: from frapeml500003.china.huawei.com (7.182.85.28) by frapeml100002.china.huawei.com (7.182.85.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 25 Sep 2024 16:47:06 +0200
Received: from frapeml500003.china.huawei.com ([7.182.85.28]) by frapeml500003.china.huawei.com ([7.182.85.28]) with mapi id 15.01.2507.039; Wed, 25 Sep 2024 16:47:06 +0200
From: Cheng Li <c.l@huawei.com>
To: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11
Thread-Index: Adr8f/5jZd3gHoNlRDmyWvRd1YgBJwCLaqYwBCrrmfA=
Date: Wed, 25 Sep 2024 14:47:06 +0000
Message-ID: <a62ffcfd8a5c4c2caa8ff87ca80cde1e@huawei.com>
References: <CO1PR08MB6611FEE769E1E3F7FF09BAF3B3912@CO1PR08MB6611.namprd08.prod.outlook.com> <04ff087c73b74217849aa9439b35cdaf@huawei.com>
In-Reply-To: <04ff087c73b74217849aa9439b35cdaf@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.70.229]
Content-Type: multipart/mixed; boundary="_005_a62ffcfd8a5c4c2caa8ff87ca80cde1ehuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: ZG2BJDE2K3MVPQWY2ZBB3RZ6VAQSAYTT
X-Message-ID-Hash: ZG2BJDE2K3MVPQWY2ZBB3RZ6VAQSAYTT
X-MailFrom: c.l@huawei.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
CC: "yinyuany@chinatelecom.cn" <yinyuany@chinatelecom.cn>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/beHmZD1r9wDbzmAgTpyoiDCJNnk>
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, I reviewed the document once more, and make more updates comparing the previous revision. * adding terms * editorial in security part. Please review this revision. Thank you! Cheng From: Cheng Li Sent: Tuesday, September 24, 2024 10:12 PM To: 'Susan Hares' <shares@ndzh.com>; idr@ietf.org Cc: Lizhenbin <lizhenbin@huawei.com>; yinyuany@chinatelecom.cn; Weiqiang Cheng <chengweiqiang@chinamobile.com>; Ketan Talaulikar <ketant.ietf@gmail.com> Subject: RE: Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11 Hi Sue, Many thanks for your comments, and sorry for my delay. Please see my reply inline. Authors, please also see the discussion below. Comments are welcome! Text proposal will be appreciated! Respect, Cheng From: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> Sent: Sunday, September 1, 2024 5:11 PM To: idr@ietf.org<mailto:idr@ietf.org> Cc: Cheng Li <c.l@huawei.com<mailto:c.l@huawei.com>>; Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>; yinyuany@chinatelecom.cn<mailto:yinyuany@chinatelecom.cn>; Weiqiang Cheng <chengweiqiang@chinamobile.com<mailto:chengweiqiang@chinamobile.com>>; Ketan Talaulikar <ketant.ietf@gmail.com<mailto:ketant.ietf@gmail.com>> Subject: Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11 Cheng, Robin, Yuanyang, Weiqiang, and Ketan: This is a shepherd's review of an IDR SR draft. Please let me know if you have any questions. It would help if you would indicate the status of your work. 1. Do you have 2 implementations of this draft? [Cheng]I will call for the implementation report in the mailing list when we update the draft. Thanks! 1. Have you finished your technical work on this draft? [Cheng]I think we have finished. 1. Are you ready for WG LC? [Cheng]yes, but we need two implementation to publish an RFC, correct? Let's see the implementation and decide. If you would like to update the IDR WG, you may request a time slot at the Sept 9th, 2024 Interim. Cheerily, Sue ==================== Shepherd's report for draft-ietf-idr-sr-policy-path-segment-11. Draft: draft-ietf-idr-sr-policy-path-segment-11 status: WG draft Augments: [RFC9012] by allowing new TLVs in Segment list Status: Needs revision (-12) Implementation status: Needs 2 implementations Technical points: 1. Missing RFC9012 context The abstract, header, and references need to indicate that you are adding TLVs to Tunnel Encapsulation Attribute for the SR Policy Type. Abstract change is provided: Old text:/ A Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists with necessary path attributes. For each SR path, it may also have its own path attributes, and Path Segment is one of them. A Path Segment is defined to identify an SR path, which can be used for performance measurement, path correlation, and end-2-end path protection. Path Segment can be also used to correlate two unidirectional SR paths into a bidirectional SR path which is required in some scenarios, for example, mobile backhaul transport network./ New Text:/ A Segment Routing(SR) policy identifies a set of candidate SR paths Each SR path is passed in BGP as the SR Policy SAFI NLRI accompanied with the Tunnel Encapsulation attribute (Tunnel-encaps). Each SR Path (tunnel) uses a set of TLVs in the Tunnel-encaps attribute to describe the characteristics of the SR Policy tunnel. One of the TLVs that describes the tunnel is the Segment list TLV which provides a list of segments contained in the tunnel. This document specifies a new Path Segment Sub-TLV to associate a Path Segment ID to the SR Segment List. The Path Segment ID can be used for performance measurement, path correlation, and end-2-end path protection. This Path Segment identifier can be also be used to correlate two unidirectional SR paths into a bidirectional SR path. Bidirection SR path may be required in some scenarios such as mobile backhaul transport network./ Hopefully this abstract change will help you make the changes to the introduction. [RFC9012] needs to be included in the references. [Cheng]Oh my god, why you are so nice? Thank you so much for providing the text! If each reviewer can review the document like you, the progress of each IETF document will be much faster than now. Respect from my bottom of my heart! Ack, and accept your proposal, thanks! 2. Is there a case when the multiple Path Segment Sub-TLV included in a list will conflict? (see section 3.0) [Cheng] Good question. Till now, I am open with multiple Path Segment TLV, but to simplify the implementation, will recommend to only encode one, and ignore the rest. My proposal is, __OLD__ Multiple Path Segment MAY be included in a Segment List for different use cases, all of them SHOULD be inserted into the SID List. __NEW__ Multiple Path Segment MAY be included in a Segment List for different use cases. In SR-MPLS, one, or some or all of them MAY be inserted into the SID List as the requirement of the use case. However, in SRv6, only one Path Segment ID can be encoded in a SRH. Therefore, an implementation MUST decide how to choose a Path Segment ID from the multiple Path Segment IDs. In order to simplify the implementation, this document suggests to encode only one Path Segment sub-TLV for a segment list, while the rest Path Segment sub-TLV SHOULD be ignored. 3. Section 5, error handling, The operations defined in [I-D.ietf-idr-sr-policy-safi] do not include your new Sub-TLV. This document needs to state that: 3-1. Error handling as defined in RFC7606 applies to new Sub-TLVs as well as SAFI context. 3-2. A BGP Speaker must perform Syntax validation of the new SubTLV in context. Must validate a) length of TLVs and sub-TLVs b) range of values If determine malformed, it should "treat-as-withdraw", 3-3. Validation of Tunnel Attribute for valid a) tunnel b) sub-TLVs associated with it. 3-4.) Validation SR Candidate routes as active route done by SRPM. [Cheng]Thanks for your suggestions! I have update it according to your comments. Please see the diff if you are ok with the update. 4. Security section needs to be added Please see the security section in SAFI. The identification of bi-direction and performance segments adds to the critical nature of some of the information. [Cheng]added. Please see if it is ok for you. Editorial changes NIT-1: Section 4, paragraph 1, sentence clarity. old text:/ In some scenarios, for example, mobile backhaul transport network, there are requirements to support bidirectional path. / New text:/ In some scenariose such as mobile backhaul transport network, there are requirements to support bidirectional path. / [Cheng]OK. NIT-2: Use Sub-TLV consistently in your text Please use the form "Sub-TLV" consistently. Change sub-TLV to Sub-TLV. [Cheng]OK, updated. If you mean to make difference to the TLVs under Reserve segment, define a term. [Cheng]we may not like to do so. NIT-3: Section 4. 1, last paragraph, sentence clarity Error: Run-on sentence please break this sentence into 2 parts Current:/ The Segment sub-TLVs in the Reverse Path Segment List sub-TLV provides the information of the reverse SR path, which can be used for directing egress BFD peer to use specific path for the reverse direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other applications./ New:/ The Segment sub-TLVs in the Reverse Path Segment List sub-TLV provides the information of the reverse SR path. This Reverse Path Segment list can be used for directing egress BFD peer to use specific path for the reverse direction of the BFD session [I-D.ietf-mpls-bfd-directed] or other applications./ [Cheng]Agree! Thanks!