Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Plane
draft-ietf-mpls-sr-epe-oam-19

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-mpls-sr-epe-oam and RFC 9703, changed IESG state to RFC Published)

[Ballot comment]
Thanks for working on this specification. My review didn't surface transport protocol related concerns.

However, it was not easy for me to understand the exact meaning of "receiving node", so I interpreted as a node receiving "SID", that can be completely misinterpretation. Can we define it in this specification or point to where this is defined  to avoid confusion?

[Ballot comment]
            If an initiator does not remove the FECs belonging to the previous AS that has traversed,
            it MAY expose the internal AS information to the following AS being traversed in traceroute.

I find the use of MAY here strange. I think what is meant that If the FECs are not removed, it will expose ?
Or if it is really "may expose" because it would depend on the content of the FECs, then it would be a lowercase
may, as an uppercase MAY makes it sound like an instruction or action

[Ballot comment]
Section 7:  I think this could stand to be separated into a few paragraphs.  As it stands, it is hard to read and harder to understand. 

Maybe something like this:
The EPE-SIDs are advertised for egress links for Egress Peer Engineering purposes or for inter-AS links between co-operating ASes. When co-operating domains are involved, they can allow the packets arriving on trusted interfaces to reach the control plane and get processed.

When EPE-SIDs are created for egress TE links where the neighbor AS is an independent entity, it may not allow packets arriving from external world to reach the control plane. In such deployments MPLS OAM packets will be dropped by the neighboring AS that receives the MPLS OAM packet.

In MPLS traceroute applications, when the AS boundary is crossed with the EPE-SIDs, the FEC stack is changed. [RFC8287] does not mandate that the initiator upon receiving an MPLS Echo Reply message that includes the FEC Stack Change TLV with one or more of the original segments being popped remove a corresponding FEC(s) from the Target FEC Stack TLV in the next (TTL+1) traceroute request.

If an initiator does not remove the FECs belonging to the previous AS that has traversed, it MAY expose the internal AS information to the following AS being traversed in traceroute.

[Ballot comment]
I'd like to support John's DISCUSS.

Thanks to Tianran Zhou for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-mpls-sr-epe-oam-15-opsdir-lc-zhou-2024-05-24/) and the authors for addressing the comments. Also thank to Tianran for updating the OpsDir review once the new version was posted.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-sr-epe-oam-18

Many thanks to Matthew Bocci, Shuping Peng and  Joel Halpern for their Routing Directorate reviews and Tarek Saad for the shepherd writeup.


Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

##Supporting the Discuss from John Scudder about confederations ASes


#GENERIC COMMENTS
#================
##The draft has been discussed well within the MPLS WG and is easy to read.


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

244   Local BGP Router ID :
245
246   4 octet unsigned integer representing the BGP Identifier of the
247   advertising node as defined in [RFC4271] and [RFC6286].

[minor]
Maybe add reference to rfc6793 (BGP Support for Four-Octet Autonomous System (AS) Number Space)

295   Length : variable based on IPv4/IPv6 interface address.  Length
296   excludes the length of Type and Length fields.For IPv4 interface
297   addresses length will be 28 octets.  In case of IPv6 address length
298   will be 52 octets.

[major]
What if the length is different from 28 or 52? how will a node receiving such information process or contain the error situation?

[minor]
Would normative language here be considered useful for implementers?

300   Adj-Type : Set to 1 when the Adjacency Segment is IPv4 Set to 2 when
301   the Adjacency Segment is IPv6

[major]
What if for example the length (see comment above) is set to 52 (=IPv6) and the adj-Type is set to IPv4?
What needs to be done? is there a validation that is taking place? does the combination of length and Adj-Type follow certain approved normative combinations?

303   RESERVED : 3 octets.  MUST be zero when sending, and agnored on
304   receiving.

[minor]
s/agnored/ignored/
Are the bits RESERVED or UNUSED? (according IANA registries)

383   Length : variable based on the number of elements in the set.  The
384   length field does not include the length of Type and Length fields.

[minor]
I suspect that the length is expressed in octets similar as the TBD1 and TBD2.
This should be clarified in the text.

410   Number of remote ASes, the set SID load-balances on.

[minor]
Clarification rewrite about the load balancing aspect:
s/Number of remote ASes, the set SID load-balances on/The number of remote ASes over which the set SID performs load balancing/

416 5.  EPE-SID FEC validation

[minor]
This section discusses validation and uses numbers. While it should be already trivial for an implementer to understand that octets are intended, it may be worthwhile to spell it out explicitly so that there is no confusion and by accident bits, nibbles, words or something else obscure would be used instead

[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-mpls-sr-epe-oam-18
CC @jgscudder

Thanks for the document. I have a few DISCUSS-level concerns (but I think they will be easy to fix), and a couple of other comments.

## DISCUSS

### Sections 4.1, 4.2, and 4.3, Confederations

These three sections have similar or identical text defining the local and remote AS numbers, as follows,

  Local AS Number :

  4 octet unsigned integer representing the Member-AS Number inside the
  Confederation [RFC5065].  The AS number corresponds to the AS to
  which PeerNode SID advertising node belongs to.

  Remote AS Number :

  4 octet unsigned integer representing the Member-AS Number inside the
  Confederation [RFC5065].  The AS number corresponds to the AS of the
  remote node for which the PeerNode SID is advertised.

Although I am naturally a huge fan of confederations, I don't understand why you are referencing them here, in this way. Surely this document is not restricted to use only with confederations (if it were it would need a lot more explanation!).

My guess is you're trying to solve the problem where the local and remote nodes are both within the same Confederation, but different Member-ASes. If so, perhaps something like the following,

NEW:

  Local AS Number :

  The 4-octet AS number of the AS to which the PeerNode SID advertising
  node belongs. If Confederations [RFC5065] are in use, and if the
  remote node is a member of a different Member-AS within the local
  Confederation, this is the Member-AS Number inside the Confederation
  and not the Confederation Identifier.

  Remote AS Number :

  The 4-octet AS number of the AS of the remote node for which the
  PeerNode SID is advertised. If Confederations [RFC5065] are in use,
  and if the remote node is a member of a different Member-AS within
  the local Confederation, this is the Member-AS Number inside the
  Confederation and not the Confederation Identifier.
 
I don't know how picky you want to get, but the case not covered in my proposed text is if confederations are in use, but the local node and remote node are in different Confederations. In that case, their respective Confederation Identifiers would be used, but it simplifies to the "AS number" case since a Confederation Identifier is just a (globally visible) AS number. As far as I'm concerned that's obvious enough not to need saying, but YMMV.

### Sections 4.1, 4.2, and 4.3, "advertising node"

These three sections all refer to the "advertising node". I presume this means, "the node that advertised the information into BGP-LS". But is that really what you mean? Keep in mind that by design, sometimes no other than the local one can advertise information into BGP-LS as a proxy for the other node.

I was thinking of proposing different terminology to remedy this problem, but I see RFC 9086 has the same defect (of assuming that the node that owns the SID will be the one that advertises it into BGP-LS), so we may as well stick with it. However, I think it would be helpful to be clear about exactly what "advertising note" means, every time you say it. You've already got a pattern for this in your document, e.g. in Section 4.2 you have "PeerAdj SID advertising node" which is good enough -- I suggest just replicating that pattern and never abbreviating down to "advertising node".

### Sections 4.1, 4.2, and 4.3, "receiving node"

These three sections all refer to the "receiving node". The most obvious and usual reading of "receiving node" is, the node that receives the BGP-LS message carrying the sub-TLV in question. I think that can't be what you mean. I think what you mean is "remote node".

[Ballot comment]

## COMMENT

### Section 4.3, order of description text

Please sort your field descriptions in the same order the fields appear in Figure 5. The out-of-order description threw me off badly on my first read-through.

### Sections 5 and 5.1, "augments"

Section 5 says,

  The below section augments the section 7.4 point 4a of
  [RFC8287].
 
And then Section 5.1 provides the augmentation.

Looking at RFC 8287 I feel sad because the referenced section there already "modifies the procedure defined in Section 4.4.1 of [RFC8029]." But at least 8287 is a straight replacement for the 8029 text -- or I think it is, the language of 8287 is not clear on this point. :-(

Since RFC 8287 §7.4 (4a) is essentially a big disjunction, it makes sense that you can take your text and paste it onto the end of 4a. And I agree that for the same reason, it doesn't matter whether it's appended to the end, placed at the beginning, or even interleaved. However for clarity, I think it would save some future reader my confusion if you reworded the quoted text as,

  The below section is appended to the procedure given in Section 7.4
  point 4a of [RFC8287].

It would also be nice if you followed the pseudo-code convention established in RFC 8287 since you're augmenting that body of pseudo-code. Yours is close, but for example, you don't use braces "{ }" where 8287 does, you don't use the same bullet conventions, etc. I imagine if there are things it's too much effort for you to fix in your source, you could ask the RFC Editor for help with those.

## 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]
I cleared my DISCUSS on the document, but reviewers, make sure you are reviewing -18 version of the draft, even though -17 was submitted for IESG review.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-sr-epe-oam-18

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 Tarek Saad for the shepherd's (very) concise write-up including the WG consensus _but it lacks_ the justification of the intended status.

Please note that Wassim Haddad is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-epe-oam/reviewrequest/19810/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 1

It is unclear (to me at least) whether "administration", "operator", and "AS" are equivalent else how they are different. Some clarifications will be welcome.

## Section 4

Unsure whether the lead text helps as it also appears in the IANA considerations.

## Section 4.1

Please specify the fields Type & Length (notably in size) to be complete.

`Length : 16 octets` is somehow confusing as the field length is 2 octets. Let's be detailed here.

## Section 4.2

Are anycast and multicast addresses in scope in this I-D ? Let's be specific and use "unicast" then.

## Section 6

Suggest adding the URL for the registry https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#sub-tlv-1-16-21

# NITS (non-blocking / cosmetic)

Suggestion: use a spell checker for `administriations`, `bandiwdth`, `descrepancies`, `agnored`, ...

s/4 octet unsigned integer/4-octet unsigned integer/

s/Link Local IPv6/Link-local IPv6/

[Ballot comment]
# Internet AD comments for draft-ietf-mpls-sr-epe-oam-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/

## Comments

### S4.2

* Do you really need this Adj-Type field?  The Length field suffices to
  differentiate v4 from v6 adjacencies (though not v4 with a v6 next hop);
  if that's all that's really needed...

[Ballot discuss]
Fear not. The DISCUSS I am holding seems like an oversight and should be easy to address.

Section 2, paragraph 0
> 2.  Theory of Operation

In response to the OPSDIR review performed by Tianran Zhou, thanks Tianran, the authors proposed additional text to describe what happens when the packet arrives in a non-cooperating domain. The authors promised the changes as part of -18 version of the draft but never posted that version. Holding a DISCUSS to make sure the latest version of the document is being reviewed.

[Ballot comment]
Section 5, paragraph 1
>    When a remote ASBR of the EPE-SID advertisement receives the MPLS OAM
>    packet with top FEC being the EPE-SID, it MUST perform validity
>    checks on the content of the EPE-SID FEC sub-TLV.  The basic length
>    check should be performed on the received FEC.

Is the should a SHOULD? What happens if the basic length check is not performed?

Section 10, paragraph 0
> 10.  APPENDIX

The section formatting for the Appendix does not look correct. It is showing up in the normative section of the draft, instead of appearing as  material. Same for References.

The IANA review of this document seems to not have concluded yet.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

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.

Section 4.1, paragraph 21
> o validate the incoming interface for a OAM packet and if the remote descript
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Gyan Mishra. Sent review to list. Submission of review completed at an earlier date.

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

IANA has completed its review of draft-ietf-mpls-sr-epe-oam-15. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Sub-TLVs for TLV Types 1, 16, and 21 sub-registry of the TLVs registry in the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry group located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

three existing early allocations are to be made permanent and have their references changed to [ RFC-to-be ] as follows:

Sub-type: 38
Sub-TLV Name: PeerAdj
Reference: [ RFC-to-be ]
Comment:

Sub-type: 39
Sub-TLV Name: PeerNode
Reference: [ RFC-to-be ]
Comment:

Sub-type: 40
Sub-TLV Name: PeerSet
Reference: [ RFC-to-be ]
Comment:

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

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 2024-05-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mpls-sr-epe-oam@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, tsaad.net@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Plane) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR)
  Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data
  Plane'
  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 2024-05-17. 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


  Egress Peer Engineering (EPE) is an application of Segment Routing to
  solve the problem of egress peer selection.  The Segment Routing
  based BGP-EPE solution allows a centralized controller, e.g. a
  Software Defined Network (SDN) controller to program any egress peer.
  The EPE solution requires a node to program the PeerNode Segment
  Identifier(SID) describing a session between two nodes, the PeerAdj
  SID describing the link (one or more) that is used by sessions
  between peer nodes, and the PeerSet SID describing an arbitrary set
  of sessions or links between a local node and its peers.  This
  document provides new sub-TLVs for EPE Segment Identifiers (SID) that
  would be used in the MPLS Target stack TLV (Type 1), in MPLS Ping and
  Traceroute procedures.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-epe-oam/



No IPR declarations have been submitted directly on this I-D.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: No.

3. 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.)
[Ans]: No.

4. 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][3] recommends) or elsewhere
  (where)?
[Ans]: A report on the implementation status was added in section 8 of the document.

## Additional Reviews

5. 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.
[Ans]: the document extends LSP Ping/Traceroute to carry new sub-TLVs to identify EPE Segment Identifiers (SID) that would be used in the MPLS Target stack TLV. The SPRING WG has been kept in the loop of the progress of the document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: Yes, MPLS review team members reviewed before adoption by the WG.
Further early reviews by the RTGDIR members and all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?
[Ans]: Does not contain a YANG module.

8. 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.
[Ans]: not applicable.

## Document Shepherd Checks

9. 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?
[Ans]: The shepherd believes this document is useful to extend LSP ping/traceroute to validate the EPE SIDs. The document is ready to be handed off to the responsible AD.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: The RTGDIR was engaged to perform early review.

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

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.
[Ans]: A first IPR poll was done before adoption of the document. A second IPR
poll was done before WGLC.

13. 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.
[Ans]: Currently, the document has 5 authors at the front page.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: Nits to be addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]: None identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: None.

18. 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?
[Ans]: None.

19. 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.
[Ans]: No.

20. 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][11]).
[Ans]:
The IANA considerations section of the document requests allocation of three new Target
FEC stack sub-TLVs from the "Sub-TLVs for TLV types 1,16 and 21" subregistry in the "TLVs"
registry of the "Multi-Protocol Label switching (MPLS) Label Switched Paths (LSPs) Ping
parameters" namespace.

    -- PeerAdj SID Sub-TLV : TBD1
    -- PeerNode SID Sub-TLV: TBD2
    -- PeerSet SID Sub-TLV : TBD3
IANA has been instructed to perform early allocation for the above ask. Early allocation has
been issued at https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.txt:

      38      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)
              PeerNode SID Sub-TLV (TEMPORARY - registered
      39      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)
              PeerSet SID Sub-TLV (TEMPORARY - registered
      40      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)

21. 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.
[Ans]: The "Sub-TLVs for TLV types 1,16 and 21" subregistry in the "TLVs"
registry of the "Multi-Protocol Label switching (MPLS) Label Switched Paths (LSPs) Ping
parameters" namespace.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: No.

3. 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.)
[Ans]: No.

4. 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][3] recommends) or elsewhere
  (where)?
[Ans]: A report on the implementation status was added in section 8 of the document.

## Additional Reviews

5. 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.
[Ans]: the document extends LSP Ping/Traceroute to carry new sub-TLVs to identify EPE Segment Identifiers (SID) that would be used in the MPLS Target stack TLV. The SPRING WG has been kept in the loop of the progress of the document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: Yes, MPLS review team members reviewed before adoption by the WG.
Further early reviews by the RTGDIR members and all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?
[Ans]: Does not contain a YANG module.

8. 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.
[Ans]: not applicable.

## Document Shepherd Checks

9. 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?
[Ans]: The shepherd believes this document is useful to extend LSP ping/traceroute to validate the EPE SIDs. The document is ready to be handed off to the responsible AD.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: The RTGDIR was engaged to perform early review.

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

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.
[Ans]: A first IPR poll was done before adoption of the document. A second IPR
poll was done before WGLC.

13. 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.
[Ans]: Currently, the document has 5 authors at the front page.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: Nits to be addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]: None identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: None.

18. 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?
[Ans]: None.

19. 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.
[Ans]: No.

20. 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][11]).
[Ans]:
The IANA considerations section of the document requests allocation of three new Target
FEC stack sub-TLVs from the "Sub-TLVs for TLV types 1,16 and 21" subregistry in the "TLVs"
registry of the "Multi-Protocol Label switching (MPLS) Label Switched Paths (LSPs) Ping
parameters" namespace.

    -- PeerAdj SID Sub-TLV : TBD1
    -- PeerNode SID Sub-TLV: TBD2
    -- PeerSet SID Sub-TLV : TBD3
IANA has been instructed to perform early allocation for the above ask. Early allocation has
been issued at https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.txt:

      38      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)
              PeerNode SID Sub-TLV (TEMPORARY - registered
      39      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)
              PeerSet SID Sub-TLV (TEMPORARY - registered
      40      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)

21. 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.
[Ans]: The "Sub-TLVs for TLV types 1,16 and 21" subregistry in the "TLVs"
registry of the "Multi-Protocol Label switching (MPLS) Label Switched Paths (LSPs) Ping
parameters" namespace.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
[Ans]: The WG consensus represents broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
[Ans]: No.

3. 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.)
[Ans]: No.

4. 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][3] recommends) or elsewhere
  (where)?
[Ans]: Asking authors to document implementations in the document.

## Additional Reviews

5. 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.
[Ans]: the document extends LSP Ping/Traceroute to carry new sub-TLVs to identify EPE Segment Identifiers (SID) that would be used in the MPLS Target stack TLV. The SPRING WG has been kept in the loop of the progress of the document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Ans]: Yes, MPLS review team members reviewed before adoption by the WG.
Further early reviews by the RTGDIR members and all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?
[Ans]: Does not contain a YANG module.

8. 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.
[Ans]: not applicable.

## Document Shepherd Checks

9. 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?
[Ans]: The shepherd believes this document is useful to extend LSP ping/traceroute to validate the EPE SIDs. The document is ready to be handed off to the responsible AD.


10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
[Ans]: The RTGDIR was engaged to perform early review.

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

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.
[Ans]: A first IPR poll was done before adoption of the document. A second IPR
poll was done before WGLC.

13. 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.
[Ans]: Currently, the document has 5 authors at the front page.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
[Ans]: Nits to be addressed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
[Ans]: None identified.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
[Ans]: None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
[Ans]: None.

18. 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?
[Ans]: None.

19. 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.
[Ans]: No.

20. 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][11]).
[Ans]:
The IANA considerations section of the document requests allocation of three new Target
FEC stack sub-TLVs from the "Sub-TLVs for TLV types 1,16 and 21" subregistry in the "TLVs"
registry of the "Multi-Protocol Label switching (MPLS) Label Switched Paths (LSPs) Ping
parameters" namespace.

    -- PeerAdj SID Sub-TLV : TBD1
    -- PeerNode SID Sub-TLV: TBD2
    -- PeerSet SID Sub-TLV : TBD3
IANA has been instructed to perform early allocation for the above ask. Early allocation has
been issued at https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.txt:

      38      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)
              PeerNode SID Sub-TLV (TEMPORARY - registered
      39      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)
              PeerSet SID Sub-TLV (TEMPORARY - registered
      40      2021-05-11, extension registered 2023-06-08, [draft-ietf-mpls-sr-epe-oam-08]
              expires 2024-05-11)

21. 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.
[Ans]: The "Sub-TLVs for TLV types 1,16 and 21" subregistry in the "TLVs"
registry of the "Multi-Protocol Label switching (MPLS) Label Switched Paths (LSPs) Ping
parameters" namespace.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

This document was through WGLC and IPR poll starting in September 2022, this was not entered into the trackercorrectly. I put it in WG Consesnsus" Waiting for Write-Up, before posting the SWU we will need to a RTG Area Early review.