Hi Eric,
Many thanks for your comments, and sorry for my delay. Please see my reply inline. We have updated the draft to address your comments, please double check the draft to see if it is OK to you. URL: https://www.ietf.org/archive/id/draft-ietf-spring-mpls-path-segment-18.txt Status: https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/ HTML: https://www.ietf.org/archive/id/draft-ietf-spring-mpls-path-segment-18.html 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-18 Thanks and respect, Cheng -----Original Message----- From: Éric Vyncke via Datatracker <nore...@ietf.org> Sent: Wednesday, November 22, 2023 5:47 PM 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: Éric Vyncke's No Objection on draft-ietf-spring-mpls-path-segment-17: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-spring-mpls-path-segment-17: 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: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-spring-mpls-path-segment-17 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Bruno Decraene (one WG chair) for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract and title If the goal is to identify a specific SR path, then why not adding "identification" in the title and the abstract ? PSID is used in the rest of the document and would benefit from being used also in the abstract/title. [Cheng]Ack, done. See diff In `A sub-set of segments from the segment list cannot distinguish one SR path from another as they may be partially congruent`, suggest s/cannot distinguish/cannot be leveraged to distinguish/ [Cheng]Done. ## Lack of extensibility ? As PSID seems to be solely identified by its position (the last label), does it prevent the use of a similar mechanism for future extension of SR list ? Should there be a syntax in this last label to identify it as a PSID? [Cheng]You might misunderstand the usage of PSID. The PSID is not identified by its position, but according to the MPLS label lookup result. The position of Path segment is to make sure that it only be read by the originator node(Egress node of the path) . The rules of using PSID and other labels/SID are described in section 2. Actually, as long as the PSID can be read by the egress node, it won't impact other labels usage. ## Section 2 `However, one PSID can be used to identify multiple Segment Lists in some use cases if needed.` seems like an oxymoron to me (bear with my lack of expertise in SR-MPLS)... Usually "identify" refers to a single identity, i.e., a single segment list in this case. [Cheng]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 2.1 Suggest to introduce ECMP in the title and not in the 3rd paragraph *after* its first use. [Cheng]Fixed, thanks. ## Section 3 Please use PSID rather than "path segment". [Cheng]Done ## Section 3.1 s/existing implementation on the egress node can be leveraged for measuring/existing implementation on the egress node can leverage PSID for measuring/ ? [Cheng]Done. ## Section 3.2 An informative reference will be useful to the reader about `obile backhaul transport networks, there are requirements to support bidirectional paths`. [Cheng]Ack . RFC6965 is added. ## Section 3.4 What is meant by `in a trusted domain` ? Is it rather a common operation ? To be honest, I was about to ballot a DISCUSS on the following point... but I am trusting the RTG AD ;), how can a global PSID be used for perf measurement (and other use cases) when the sub-domains can expenad the BSID at their will ? I.e., PSID does not represent a real hop-by-hop path but more a sub-domain to sub-domain path... [Cheng]Thanks 😊 It is quite common in Segment Routing. In this section, we assume that all the domains(sub-domains) are under control or management by an operator. But the whole domain is divided into multiple sub-domains for some reasons. We do not have global PSID. PSID is always a local label. But a PSID can identify a E2E path, while the E2E path might consist of multiple sub-path that is bound to BSID(s). From the POV from a sub-path, it is a normal path actually, so a path segment can be used for identifying it. Also, the whole SID List can be bound to BSID, and the BSID can be used in the segment list of the E2E label stack to shorten the length/depth of label stack. The usage of BSID is normal. We only would like to share that PSID can be used in this case. Nothing new comparing to the cases without BSID actually. Hope I make it clear for you. But anyway, thank you again for the trust. ## Section 4 `The intermediate nodes of this path will not learn it.` is it true for the first node ? I.e., it knows where it is coming from and have the full view on the segment list. [Cheng] The ingress node should learn the PSID and the Segment List, because it needs to insert the path segment into the segment list. Please see section 2. ## Operational considerations The last paragraph of section 4 should rather be in an "operational considerations" section. [Cheng]We do not have an operational consideration section now, is it ok to keep it as it is? # NITS (non-blocking / cosmetic) ## Section 1.2 s/A sub-path is a part of the a path/A sub-path is a part of a path/ ? [Cheng] fixed. ## Section 2 s/intermedate node/intermediate node/ [Cheng]Fixed ## Section 3 s/can leveage/can leverage/ [Cheng]Fixed. Many thanks!
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
