Path Segment Identifier in MPLS Based Segment Routing Network
draft-ietf-spring-mpls-path-segment-22

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-spring-mpls-path-segment and RFC 9545, changed IESG state to RFC Published)

[Ballot 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.

### 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.

### Section 3, paragraph 0
```
  3.  Use cases
```
I assume this section is informational? It would be good to say so
explicitly.

## 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

### 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.

#### 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".

#### 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".

#### 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.

## 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

[Ballot discuss]
I'd like to have a discussion as regards how this will function in scenarios using UHP.

My understanding is that by default SR-MPLS implements PHP - so the router that receives a packet with a PSID will normally find the PSID at top of stack (it may be the only label but it will be top stack).  This however changes in the case of explicit NULL - which may or may not be BoS.  Normally explicit NULL would be popped on egress - however, in this case the explicit NULL would have to be "ignored (stepped over)" such that the PSID could be processed - and then on egress the explicit NULL and the PSID would have to be popped.  Alternatively, the explicit NULL would need to be popped, the PSID processed, and then the PSID popped.  I'm not quite sure what the implications of this would be, though, at minimum, this could potentially result in significant performance degradation.  Either way, lets discuss because I think this scenario does need addressing.

[Ballot comment]
Firstly, thanks for the document, I found this a relatively easy read.

A few nits and comments below.

Section 1 3rd paragraph is missing a space on the second line, and that paragraph may actually be easier to read if you put the Sectional references in brackets, such that Section 3.1 becomes (Section 3.1) etc.

In Section 2 you write "The value of the TTL field in the MPLS label stack entry containing a PSID can be set to any value except 0.  If a PSID is the bottom label, the S bit MUST be set."  Now, I am presuming that the the PSID does NOT need to be at the bottom of stack.  This is based on my reading of section 3.4.  In the example, you are pushing s-PSID followed by two BSID's and then a final e-PSID.  Am I correct in thinking you could have a situation which each BSID is followed by a PSID, such that you are including the s-PSID for B->C and the s-PSID for C->D?

If I am correct in this reading - I would suggest that you explicitly state that if the PSID is NOT the bottom label, the S bit must NOT be set.  (So as suggested text, "If a PSID is the bottom label, the S bit MUST be set.  Conversely if the PSID is followed by subsequent labels, the S bit MUST NOT be set"

As another random note - it may be worth working with the authors of draft-ietf-idr-segment-routing-te-policy to add PSID into the SR Policy Encoding in the same way that BSID's are specified.

[Ballot 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.

### 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.

### 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

### 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.

### 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:

## 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

[Ballot comment]
Hi,

Thanks for this document.  I found is pretty easy to read, and have a couple of very minor (editorial) comments:

Nit level comments:

(1) p 6, sec 3.1.  PSID for Performance Measurement

  PSID can also be used for In-situ OAM[RFC9197] for SR-MPLS to
  identify the SR Path associated with the in-situ data fields in the
  data packets on the egress node.

  PSID can also be used for In-band PM for SR-MPLS to identify the SR
  Path associated with the collected performance metrics.

Just cosmetic, but given the repetition, perhaps put the last 3 sentences in this section into a list, e.g., starting with "PSID can also be used:"


(2) p 7, sec 3.4.  Nesting of PSIDs

  Binding SID (BSID) [RFC8402] can be used for SID list compression.
  With BSID, an end-to-end SR path in a trusted domain can be split                                                                                                                       
  into several sub-paths, each sub-path is identified by a BSID.  Then                                                                                                                     
  an end-to-end SR path can be identified by a list of BSIDs,                                                                                                                                                                                             
  therefore, it can provide better scalability.                                                                                                                                                                                                           
  BSID and PSID can be combined to achieve both sub-path and end-to-end                                                                                                                                                                                   
  path monitoring.  A reference model for such a combination in                                                                                                                                                                                           
  (Figure 2) shows an end-to-end path (A->D) in a trusted domain that                                                                                                                                                                                     
  spans three sub-domains (Access, Aggregation and Core domain) and                                                                                                                                                                                       
  consists of three sub-paths, one in each sub-domain (sub-path (A->B),                                                                                                                                                                                   
  sub-path (B->C) and sub-path (C->D)).  Each sub-path is associated                                                                                                                                                                                       
  with a BSID and a s-PSID.                                                                                                                                                                                                                               
                                                                                                                                                                                                                                                           
As a minor nit, s-PSID is used above, but not defined until the following paragraph.

Regards,
Rob

[Ballot comment]
# Internet AD comments for draft-ietf-spring-mpls-path-segment-17
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S1.2

* "a part of the a path" ->
  "a part of the path"

[Ballot 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/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-spring-mpls-path-segment-16, which is currently in Last Call (we had also reviewed draft-ietf-spring-mpls-path-segment-08 in a previous Last Call), and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-10-26):

From: The IESG
To: IETF-Announce
CC: bruno.decraene@orange.com, draft-ietf-spring-mpls-path-segment@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Path Segment in MPLS Based
Segment Routing Network'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-10-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  A Segment Routing (SR) path is identified by an SR segment list.  A
  sub-set of segments from the segment list cannot distinguish one SR
  path from another as they may be partially congruent.  SR path
  identification is a pre-requisite for various use-cases such as
  Performance Measurement (PM), and end-to-end 1+1 path protection.

  In SR for MPLS data plane (SR-MPLS), an Egress node cannot determine
  on which SR path a packet traversed the network from the label stack
  because the segment identifiers are removed from the label stack as
  the packet transits the network.

  This document defines Path Segment to identify an SR path on the
  egress node of the path.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3492/
  https://datatracker.ietf.org/ipr/5895/
  https://datatracker.ietf.org/ipr/5063/
  https://datatracker.ietf.org/ipr/5009/
  https://datatracker.ietf.org/ipr/3455/

Document History

    Does the working group (WG) consensus represent the strong concurrence of a
    few individuals, with others being silent, or did it reach broad agreement?

The document has been significantly reviewed and is partially implemented.

    Was there controversy about particular points, or were there decisions where
    the consensus was particularly rough?

No controversy.

    Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

No.

    For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

There are implementations and they are reported in the document (as RFC 7942 recommends).

Additional Reviews

    Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

The document closely interacts with technology defined in the MPLS WG but does not change MPLS specifications.
It defines a new type of Local Segment for Segment Routing MPLS.
(Local Segment are defined in RFC 8402, SR-MPLS is defined in RFC 8660. Both are a product of the SPRING WG)

    Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, YANG module, media type, URI type, or formal language.

    If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

No YANG module.

    Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language.


Document Shepherd Checks

    Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

Yes.

    Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

An early RTGDIR and GENART review has been performed.
An early OPSDIR and SECDIR review has been requested but not performed.

    What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

STD Track is requested. This is reflected in the data tracker and front page of the document.
This seems appropriate to define a new type of Segment Routing segment (the Path Segment)
which will likely need protocol extensions in YANG models, signaling and routing protocols
(e.g. draft-ietf-pce-sr-path-segment)

    Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are five IPR disclosures reported in the datatracker.
No relevant discussion in the WG.
One IPR filed late that was of concern to the chairs
but a satisfactory explaination was provided to the chairs by the filer.

Authors have been asked to indicate whether they know of any undisclosed IPR
https://mailarchive.ietf.org/arch/msg/spring/SkghkLE5JZvw9JGaAOSKRym-toM/

Missing authors have been asked again
https://mailarchive.ietf.org/arch/msg/spring/3DvyDu6VnGihxWXn68Y6EsT2UtY/

Following replies have been received:
W. Cheng https://mailarchive.ietf.org/arch/msg/spring/yBrg0SJTUu5yCzFsZJglRxSYCZs/
H. Li https://mailarchive.ietf.org/arch/msg/spring/gEtpviOJWMFwDqzd2uEw9yAgYEU/
C. Li https://mailarchive.ietf.org/arch/msg/spring/U_PJl3-i9Ot1qk7jNFsjg101g1U/
R. Gandhi https://mailarchive.ietf.org/arch/msg/spring/IFJqpu4MCGdxcg5wn2RqKE1_MXI/
R. Zigler https://mailarchive.ietf.org/arch/msg/spring/aMyvnakERbEkasT-jfGFOTr__Ro/



    Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Total number of authors is five.
No author and no contributor have complained about being listed as such.
All authors are aware that they are listed as authors as they have replied to the IPR call.

    Document any remaining I-D nits in this document. Simply running the idnits
    tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

IdNits runs fine.
"Content Guidelines" have been reviewed.
Shepherd have reviewed the document multiple times (and as a result have found nits multiple times, so unfortunately that's not an indicate that there is no remaining nits)
Two different consecutive shepherds have reviewed the document.

    Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

References look fine to me.

    List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

    Are there any normative downward references (see RFC 3967 and BCP
    97) that are not already listed in the DOWNREF registry? If so,
    list them.

No

    Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

    Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The publication of this document will not change the status of existing RFCs.

    Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

IANA section is empty, which is correct.

    List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registry.

Document History

    Does the working group (WG) consensus represent the strong concurrence of a
    few individuals, with others being silent, or did it reach broad agreement?

The document has been significantly reviewed and is implemented and deployed.

    Was there controversy about particular points, or were there decisions where
    the consensus was particularly rough?

No controversy.

    Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

No.

    For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

There are implementations and they are reported in the document (as RFC 7942 recommends).

Additional Reviews

    Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

The document closely interacts with technology defined in the MPLS WG but does not change MPLS specifications.
It defines a new type of Local Segment for Segment Routing MPLS.
(Local Segment are defined in RFC 8402, SR-MPLS is defined in RC 8660. Both are a product of the SPRING WG)

    Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, YANG module, media type, URI type, or formal language.

    If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

No YANG module.

    Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language.


Document Shepherd Checks

    Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

Yes.

    Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

An early RTGDIR and GENART review has been performed.
An early OPSDIR and SECDIR review has been requested but not performed.

    What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

STD Track is requested. This is reflected in the data tracker and front page of the document.
This seems appropriate to define a new type of Segment Routing segment (the Path Segment)
which will likely need protocol extensions in YANG models, signaling and routing protocols
(e.g. draft-ietf-pce-sr-path-segment)

    Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are five IPR disclosures reported in the datatracker.
No relevant discussion in the WG.
One IPR filed late that was of concern to the chairs
but a satisfactory explaination was provided to the chairs by the filer.

Authors have been asked to indicate whether they know of any undisclosed IPR
https://mailarchive.ietf.org/arch/msg/spring/SkghkLE5JZvw9JGaAOSKRym-toM/

Missing authors have been asked again
https://mailarchive.ietf.org/arch/msg/spring/3DvyDu6VnGihxWXn68Y6EsT2UtY/

Following replies have been received:
W. Cheng https://mailarchive.ietf.org/arch/msg/spring/yBrg0SJTUu5yCzFsZJglRxSYCZs/
H. Li
C. Li https://mailarchive.ietf.org/arch/msg/spring/U_PJl3-i9Ot1qk7jNFsjg101g1U/
R. Gandhi https://mailarchive.ietf.org/arch/msg/spring/IFJqpu4MCGdxcg5wn2RqKE1_MXI/
R. Zigler https://mailarchive.ietf.org/arch/msg/spring/aMyvnakERbEkasT-jfGFOTr__Ro/

/TODO

    Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Total number of authors is five.
No author and no contributor have complained about being listed as such.
/TODO All authors are aware that they are listed as authors as they have replied to the IPR call.

    Document any remaining I-D nits in this document. Simply running the idnits
    tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

IdNits runs fine.
"Content Guidelines" have been reviewed.
Shepherd have reviewed the document multiple times (and as a result have found nits multiple times, so unfortunately that's not an indicate that there is no remaining nits)
Two different consecutive shepherds have reviewed the document.

    Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

References look fine to me.

    List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

    Are there any normative downward references (see RFC 3967 and BCP
    97) that are not already listed in the DOWNREF registry? If so,
    list them.

No

    Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

    Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

The publication of this document will not change the status of existing RFCs.

    Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

IANA section is empty, which is correct.

    List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new IANA registry.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-spring-mpls-path-segment-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-11-20):

From: The IESG
To: IETF-Announce
CC: andrew-ietf@liquid.tech, draft-ietf-spring-mpls-path-segment@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Path Segment in MPLS Based
Segment Routing Network'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-11-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  A Segment Routing (SR) path is identified by an SR segment list.
  Only the complete segment list can identify the end-to-end SR path,
  and a sub-set of segments from the segment list cannot distinguish
  one SR path from another as they may be partially congruent.  SR path
  identification is a pre-requisite for various use-cases such as
  Performance Measurement (PM), bidirectional paths correlation, and
  end-to-end 1+1 path protection.

  In SR for MPLS data plane (SR-MPLS), the segment identifiers are
  stripped from the packet through label popping as the packet transits
  the network.  This means that when a packet reaches the egress of the
  SR path, it is not possible to determine on which SR path it
  traversed the network.

  This document defines a new type of segment that is referred to as
  Path Segment, which is used to identify an SR path in an SR-MPLS
  network.  When used, it is inserted by the ingress node of the SR
  path and immediately follows the last segment identifier in the
  segment list of the SR path.  The Path Segment is preserved until it
  reaches the egress node for SR path identification and correlation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5009/
  https://datatracker.ietf.org/ipr/3492/
  https://datatracker.ietf.org/ipr/3455/
  https://datatracker.ietf.org/ipr/5063/

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track RFC. Correctly reflected in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document defines a new type of segment that is referred to as
  Path Segment, which is used to identify an SR path in an SR-MPLS
  network.  When used, it is inserted by the ingress node of the SR
  path and immediately follows the last segment identifier in the
  segment list of the SR path.  The Path Segment will not be popped off
  until it reaches the egress node of the SR path.  The Path Segment
  then can be used by the egress node to implement SR path
  identification and correlation.

Working Group Summary:

This document has been largely reviewed by the WG, commented on and supported by the working group.

Document Quality:

No concerns with quality of the document.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

The Document Shepherd is James N Guichard.
The Responsible Area Director is Martin Vigoureux.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The whole document has been reviewed before and after the WGLC. Numberous comments sent and addressed by the document authors.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. There have been a lot of reviews and comments from SPRING contributors and all outstanding comments have been addressed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns as the document has been widely reviewed by the WG.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Four IPR disclosures have been filed as required by IETF policy. No WG discussion on this IPR. One IPR filed late that was of concern to the chairs but a satisfactory explaination was provided to the chairs by the filer.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG as a whole understands and agrees with the document based upon extensive review.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits found for this document and tool runs clean.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, Yang model, media type or URI type.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are already RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations seem consistent with the body of the document. No additional comments or concerns.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The document has no sections written in formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not define a YANG module.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standards Track RFC. Correctly reflected in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document defines a new type of segment that is referred to as
  Path Segment, which is used to identify an SR path in an SR-MPLS
  network.  When used, it is inserted by the ingress node of the SR
  path and immediately follows the last segment identifier in the
  segment list of the SR path.  The Path Segment will not be popped off
  until it reaches the egress node of the SR path.  The Path Segment
  then can be used by the egress node to implement SR path
  identification and correlation.

Working Group Summary:

This document has been largely reviewed by the WG, commented on and supported by the working group.

Document Quality:

No concerns with quality of the document.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

The Document Shepherd is James N Guichard.
The Responsible Area Director is Martin Vigoureux.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The whole document has been reviewed before and after the WGLC. Numberous comments sent and addressed by the document authors.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. There have been a lot of reviews and comments from SPRING contributors and all outstanding comments have been addressed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns as the document has been widely reviewed by the WG.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Four IPR disclosures have been filed as required by IETF policy. No WG discussion on this IPR. One IPR filed late that was of concern to the chairs but a satisfactory explaination was provided to the chairs by the filer.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WG as a whole understands and agrees with the document based upon extensive review.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits found for this document and tool runs clean.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, Yang model, media type or URI type.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are already RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations seem consistent with the body of the document. No additional comments or concerns.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The document has no sections written in formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not define a YANG module.