Hi John, Thank you for your comments. Please see my reply inline.
We have updated the draft according to your comments. 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-20 Thanks, Cheng -----Original Message----- From: John Scudder via Datatracker <nore...@ietf.org> Sent: Wednesday, November 29, 2023 3:04 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: John Scudder's No Objection on draft-ietf-spring-mpls-path-segment-19: (with COMMENT) John Scudder has entered the following ballot position for draft-ietf-spring-mpls-path-segment-19: 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: ---------------------------------------------------------------------- # John Scudder, RTG AD, comments for draft-ietf-spring-mpls-path-segment-19 CC @jgscudder Thanks for this document. I have a few non-blocking comments, below. ## COMMENTS ### Applicability to SRv6 Since SRv6 also doesn't guarantee to propagate the SID list all the way to the egress node, might PSID functionality potentially also be required in SRv6? The way it's defined in this document, it's tightly bound to SR-MPLS, might this create added complication in the future if an SRv6 instantiation is desired? I'm not at all suggesting you define such an SRv6 instantiation in this document. At most, maybe you would revise some of the text in Section 2, to leave open the possibility for such an instantiation in the future. [Cheng] In the beginning, we have some text related to SRv6, but Bruno suggested to delete it to keep this draft clean, so we deleted it. But don't worry, we do have a draft to define the SRv6 path segment: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/ So the possibility is open for sure. Once we finish this draft, we can promote that draft. Thank you for your suggestion! ### Terminology It's probably worth saying somewhere that you assume knowledge of the definitions in Section 2 of RFC 8402. For example, "Local Segment" isn't defined in your document, presumably you're relying on the RFC 8402 definition. I didn't carefully track whether there are other terms similarly in need of definition. [Cheng]Ack, added RFC8402 for Local segment. ### Section 1.2, orphan and near-orphan definitions Some abbreviations are never used, maybe these were used in a previous version of the document, I don't know. Anyway, I think they can be removed from the section now. Some abbreviations are used only once. In my opinion, it would be better to just spell them out where used, instead of introducing an abbreviation and then only using it once. Never used: DM LM SL Used once: PM SRLB Used twice, in the same paragraph, so IMO not needed to be listed in the abbreviations section: MSD [Cheng]Agree. Fixed. ### Section 2, "below MPLS label" I don't understand what precisely you mean by, "The addition of the PSID will require the egress to read and process the PSID label in addition to the regular processing (such as a below MPLS label or the MPLS payload)." What's a "below MPLS label"? I also think "MPLS payload", would be clearer as just "payload" -- using "MPLS" as an adjective doesn't seem to add value in this context. Ironically, I would find the sentence perfectly clear if the portion inside parentheses were removed. [Cheng] Deleted the text in the parentheses. Thanks. ### Section 2, is PSID always the bottom label, or not? Figure 1 implies PSID is always the bottom label. A few paragraphs about that, though, you have "If a PSID is the bottom label, the S bit MUST be set." The "if" implies the PSID doesn't have to be the bottom level. It seems that either Figure 1 or the quoted text should be updated, to make them consistent. Based on Section 3.4, I guess the text is right and Figure 1 is wrong, or at least misleading. One possible fix could be, OLD: The label stack with PSID is shown in Figure 1: NEW: An example label stack with PSID is shown in Figure 1: [Cheng]Thanks, updated. ## 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. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
