É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. 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/ ## 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? ## 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. ## Section 2.1 Suggest to introduce ECMP in the title and not in the 3rd paragraph *after* its first use. ## Section 3 Please use PSID rather than "path segment". ## 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/ ? ## Section 3.2 An informative reference will be useful to the reader about `obile backhaul transport networks, there are requirements to support bidirectional paths`. ## 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... ## 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. ## Operational considerations The last paragraph of section 4 should rather be in an "operational considerations" section. # 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/ ? ## Section 2 s/intermedate node/intermediate node/ ## Section 3 s/can leveage/can leverage/ _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
