Re: [spring] John Scudder's No Objection on draft-ietf-spring-mpls-path-segment-19: (with COMMENT)

[Cheng Li <[e-mail]>]

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 <[e-mail]> 
Sent: Wednesday, November 29, 2023 3:04 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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