Hi Lars, Many thanks for your comments. Please see my reply inline.
The comments are quite common among IESG members, I should try to avoid these common concerns in next draft 😊 The draft has been updated to address your comments and Andrew comments together. Please check. HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-mpls-path-segment-21 Thanks, Cheng -----Original Message----- From: Lars Eggert via Datatracker <nore...@ietf.org> Sent: Thursday, November 30, 2023 11:10 AM To: The IESG <i...@ietf.org> Cc: draft-ietf-spring-mpls-path-segm...@ietf.org; spring-cha...@ietf.org; spring@ietf.org; james.n.guich...@futurewei.com; bruno.decra...@orange.com; bruno.decra...@orange.com Subject: Lars Eggert's No Objection on draft-ietf-spring-mpls-path-segment-20: (with COMMENT) Lars Eggert has entered the following ballot position for draft-ietf-spring-mpls-path-segment-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-spring-mpls-path-segment-20 CC @larseggert Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/8Y8zdymWO5b2jAqASpybK3TbVHU). ## Comments ### Section 1, paragraph 3 ``` However, to support various use-cases in SR-MPLS networks, such as Performance MeasurementSection 3.1, bidirectional path Section 3.2, and end-to-end 1+1 path protection (Live-Live case) Section 3.3, the ability to implement path identification on the egress node is a pre- requisite. ``` This paragraph is really incomprehensible. [Cheng]Updated. However, identifying a path on the egress node is a pre-requisite for various use-cases in SR-MPLS networks, such as Performance Measurement ({{psid-for-pm}}), bidirectional path ({{psid-for-bpath}}), and end-to-end 1+1 path protection (Live-Live case) ({{psid-for-protection}}). ### Section 2, paragraph 2 ``` A PSID is used to identify a Segment List. However, one PSID can be used to identify multiple Segment Lists in some use cases if needed. For example, one single PSID MAY be used to identify some or all Segment lists in a Candidate path or an SR policy, if an operator would like to aggregate these Segment Lists in operation. ``` This is confusing. Either a PSID (uniquely?) identifies *one* segment list, or it does not. If it can identify multiple (disjoint?) segment lists, the details of how this works need to be described much more clearly. [Cheng] This comment has been provided by several people 😊 Let me use the answer to Eric here. A simple example can help you. A PSID 1000 is allocated by the egress node. The egress node would like to treat the path 1 and path 2 as a single path(or a path group?) in traffic accounting, then the node uses PSID 1000 for path 1 and path 2. The ingress nodes use PSID 1000 for the packets that to be forwarded over path 1 and path 2. When the egress node receives the packets, from the egress node point of view, the egress node can count how many packets are forwarded over the paths identified as 1000. In this case, a PSID is used for multiple paths. ### Section 3, paragraph 0 ``` 3. Use cases ``` I assume this section is informational? It would be good to say so explicitly. [Cheng] Added. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### URLs These URLs in the document did not return content: * https://www.fiberhome.com/operator/product/products/294.aspx.htm [Cheng]Asking for a new ULR now. I might update it later in other revision instead of this revision. Because it will be deleted in the future anyway, so let's skip it now 😊 ### Grammar/style #### Section 3.2, paragraph 3 ``` trusted domain that spans three sub-domains (Access, Aggregation and Core do ^^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 3.2, paragraph 4 ``` of three sub-paths, one in each sub-domain (sub-path (A->B), sub-path (B->C ^^^^^^^^^^ ``` This word is normally spelled as one. [Cheng]OK, fixed above two. #### Section 3.3, paragraph 1 ``` ub-path is associated with a BSID and a s-PSID. The SID list of the end-to-e ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". [Cheng]Fixed. #### Section 3.4, paragraph 8 ``` PSID from an egress nodes to an ingress nodes is performed within an SR tru ^^^^^^^^^^^^^^^^ ``` The plural noun "nodes" cannot be used with the article "an". [Cheng]Fixed #### Section 5.1, paragraph 3 ``` auses have been implemented in above mentioned New H3C Products(running Versi ^^^^^^^^^^^^^^^ ``` The adjective "above-mentioned" is spelled with a hyphen. [Cheng]Fixed ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
