Skip to main content

Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks
draft-ietf-mpls-spring-inter-domain-oam-20

Revision differences

Document history

Date Rev. By Action
2024-08-16
20 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-08-16
20 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-08-16
20 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-08-15
20 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-08-06
20 (System) RFC Editor state changed to EDIT
2024-08-06
20 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-08-06
20 (System) Announcement was received by RFC Editor
2024-08-06
20 (System) IANA Action state changed to In Progress
2024-08-06
20 Jenny Bui IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-08-06
20 Jenny Bui IESG has approved the document
2024-08-06
20 Jenny Bui Closed "Approve" ballot
2024-08-06
20 Jenny Bui Ballot approval text was generated
2024-08-06
20 (System) Removed all action holders (IESG state changed)
2024-08-06
20 Jim Guichard IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2024-08-05
20 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2024-06-26
20 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-20.txt
2024-06-26
20 Shraddha Hegde New version accepted (logged-in submitter: Shraddha Hegde)
2024-06-26
20 Shraddha Hegde Uploaded new revision
2024-06-25
19 Gunter Van de Velde
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17
## DISCUSS has been resolved with the -19 version together with addressing the …
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17
## DISCUSS has been resolved with the -19 version together with addressing the detailed observations.

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson and for the shepherd writeup by Adrian Farrel.

Many thanks for this write-up. It is well written. I did find when reading the document that some constructs were presented more complex as necessary.

Please find in this review three blocking DISCUSS observations, followed by non-blocking high-level observations. Additionally, there is a set of detailed comments categorized as [minor] and [major] observations, which I hope you will find useful for improving the document.

#[all DISCUSS resolved] DISCUSS items
#====================================
##[resolved] DISCUSS1
Why is there the A-flag? would the existence of an SR Algorithm in the TypeC/D subTLVs not be sufficient? It implicit suggests that there is an algorithm?

##[resolved] DISCUSS2
What should be done when, for Type-C and D, the encoded IP address does not match the encoded SID for the node or the correct algorithm for that node? Is there a validation process or error messaging in place?

##[resolved] DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.

#GENERIC COMMENTS
#================
##There is some usage of RFC2119 normative language that may not be needed in some sections. Some have been flagged in the detail review

##The SID is encoded with only a label in the Type-A/C/D. SR also allows a SID to be an index instead of a label. Is there a reason why index was excluded?

##with the explanation of the Type-A/C/D subTLVs there was some duplicate text for explaining the fields. I would suggest to revise and the fields and the formal procedures only once per Type. Now some fields are described twice in the same section

##Section 6 details an example. Examples are not formal normative procedures. It seems more opportune to place the example in Appendix to reduce the formal part of the draft and to clearly identify it is informational. It makes the main part of the formal procedure of the RFC less long

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

26   domains.  This document describes mechanisms to facilitate LSP ping
27   and traceroute in inter-AS and inter-domain SR-MPLS networks
28   efficiently with a simple Operations, Administration and Maintenance
29   (OAM) protocol extension which uses data plane forwarding alone for
30   forwarding echo replies on transit nodes.

[minor]
I got confused wit the wording of 'alone' and am not convinced it is used correctly.

"This document outlines mechanisms to enable efficient LSP ping and traceroute in inter-AS and inter-domain SR-MPLS networks through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes."

115   [RFC8660] specifies SR with an MPLS data plane.  [RFC8402] describes
116   BGP peering SIDs, and [RFC9087] describes Egress Peer Engineering,

[minor]
s/BGP peering SIDs/BGP Peering Segments/
s/Egress Peer Engineering/Centralized BGP Egress Peer Engineering/

117   which will help in steering packets from one AS to another.  Using
118   the above SR capabilities, paths that span across multiple ASes can
119   be created.

[minor]
slight rewrite from readability perspective:
"By utilizing these SR capabilities, it is possible to create paths that span multiple ASes."

192   SR label stack.  The return path can either be derived by a smart
193   application or controller that has a full topology view.  This
194   document also proposes mechanisms to derive the return path
195   dynamically during traceroute procedures.

[major]
I am not sure what is a 'smart' application or controller. Is a full topology view really required? a topology view of the network section being investigated seems sufficient, not?

197   The current document is focused on the inter-domain use case.
198   However, the protocol extensions described in this document may be
199   applied to indicate the return path for other use cases as well,
200   which are out-of-scope for this document and therefore not further
201   described in this document.  SRv6 data plane is not in the scope of
202   this document.

[minor]
Why is the text seems complicated constructed. What about the following:

"This document focuses on the inter-domain use case. The protocol extensions described may also indicate the return path for other use cases, which are outside the scope of this document and are not further detailed here. The SRv6 data plane is also not covered in this document."

204 1.1.  Definition of Domain

206   The term domain used in this document implies an IGP domain where
207   every node is visible to every other node for shortest path
208   computation.  The domain implies an IGP area or level.  An AS
209   consists of one or more IGP domains.  The procedures described in
210   this document apply to paths built across multiple domains which
211   include inter-area as well as inter-AS paths.  The procedures and
212   deployment scenarios described in this document apply to inter-AS
213   paths where the participating ASes belong to closely coordinating
214   administrations or to single ownership.  This document applies to SR-
215   MPLS networks where all nodes in each of the domains are SR capable.
216   It also applies to SR-MPLS networks where SR acts as an overlay
217   having SR-incapable underlay nodes.  In such networks, the traceroute
218   procedure is executed only on the overlay SR nodes.

[minor]
I found this section hard to parse. The following text proposal processes slightly better:

"In this document, the term "domain" refers to an IGP domain where every node is visible to every other node for the purpose of shortest path computation, implying an IGP area or level. An Autonomous System (AS) comprises one or more IGP domains. The procedures described herein are applicable to paths constructed across multiple domains, including both inter-area and inter-AS paths. These procedures and deployment scenarios are relevant for inter-AS paths where the participating ASes are under closely coordinating administrations or single ownership. This document pertains to SR-MPLS networks where all nodes within each domain are SR-capable. It also applies to SR-MPLS networks where SR functions as an overlay with SR-incapable underlay nodes. In such networks, the traceroute procedure is executed only on the overlay SR nodes.
"

253   Reply Path (RP) TLV is defined in [RFC7110].  SR networks statically
254   assign the labels to nodes and a PMS/head-end may know the entire
255   database.  The reverse path can be built from the PMS/head-end by

[major]
What for database? The LSDB? a database with the all the nodes and assigned SIDs? something else?

265   The type of segment that the head-end chooses to send in the Reply
266   Path TLV is governed by local policy.  Implementations MAY provide
267   Command Line Interface (CLI) input parameters in the form of Labels/
268   IPv4 addresses/IPv6 addresses or a combination of these which get
269   encoded in the Reply Path TLV.  Implementations MAY also provide
270   mechanisms to acquire the database of remote domains and compute the
271   return path based on the acquired database.  For traceroute purposes,
272   the return path will have to consider the reply being sent from every
273   node along the path.  The return path changes when the traceroute

[major]
I do not understand why these are uppercase MAY? no formal protocol procedures are provided in this section? consider lower case as it distracts from formal protocol procedures

[major]
The term 'database' is unclear. What for database is exactly intended? A node may have many databases

279   Some networks may consist of pure IPv4 domains and pure IPv6 domains.
280   Handling end-to-end MPLS OAM for such networks is out of the scope of
281   this document.  It is recommended to use dual-stack in such cases and
282   use end-to-end IPv6 addresses for MPLS ping and traceroute
283   procedures.

[minor]
Clarification: I suspect that it is intended to indicate that it is pure ipv4-only or ipv6-only networks?

295   The below types of Segment sub-TLVs apply to the Reply Path TLV.  The
296   code points for the sub-TLVs are taken from the IANA registry common
297   to TLVs 1, 16, and 21.  This document defines the Segment sub-TLVs
298   usage and processing when it appears in TLV 21.  If these sub-TLVs
299   appear in TLVs 1 or 16, appropriate error codes MUST be returned as
300   defined in [RFC8029].

[major]
While the text here is is not wrong, it is confusing type-A/C/D and then three code-point TLVs... The text should be more explit that code points punt towards:
1 Target FEC Stack
16 Reverse-path Target FEC Stack
21 Reply Path

and be more explicit that the new defined sub-TLVs are only to be used with TLV21 (Reply Path TLV).

327   Type: TBD1(to be assigned by IANA from the registry "Sub-TLVs for TLV
328   Types 1, 16, and 21").

[minor]
Should it not specify a field length of 2 octets?

330   Length: 2 octets.  Carries value 8.  The length excludes the length
331   of the Type and Length Fields.

[minor]
The length "value" exclude....

335   RESERVED: 3 octets of reserved bits.  MUST be set to zero when
336   sending; MUST be ignored on receipt.

[minor]
I believe that the declaration for reserved is the correct one, but want to double check. If there is any potential that in future these bits may be used, then instead Future Use may be better choice.

342   S: 1 bit Reserved.

[minor]
few lines above the RESERVED 3 octets were described directly, however the formal procedure for handling S bit is explained later in the text, which is inconsistent

390   Length: 2 octets.  Carries value 8 without SID included or 12 with
391   SID included.

[minor]
The text should be more prescriptive.
"Caries value 8 when no optional SID is included or value 12 when optional SID is included."

395   SR Algorithm: 1 octet specifying SR Algorithm as described in section
396   3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present.
397   SR Algorithm is used by the receiver to derive the Label.  When
398   A-flag is unset, this field has no meaning and thus MUST be set to
399   zero on transmission and ignored on receipt.

[major]
Is the algorithm not always used by the received to derive the used label?
the algorithm is either 0 (or 1) or one of the flex-algorithms.
Iam not sure why there is an A-flag? could the setting of AR Algorithm not implicit assume that there is an SR Algorithm? why a specific A-fleg?

404   IPv4 Node Address: 4-octet IPv4 address representing a node.

[minor]
Should it be mentioned that this should be best a stable address (e.g a loopback address?)

406   SID: optional: 4-octet field containing label, TC, S and TTL as
407   defined in Section 4.1.  When the SID field is present, it MUST be
408   used for constructing the Reply Path.

[major]
A SID can be a label or an index. Is there a reason to exclude the index type of SID? (see: https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.2 )

414   The SID is optional and specifies a 4-octet MPLS SID containing
415   label, TC, S and TTL as defined in Section 4.1.

[minor]
Seems duplicate text meanings already documented in line406-408

417   If the length is 8, then only the IPv4 Node Address is present.
419   If the length is 12, then the IPv4 Node Address and the MPLS SID are
420   present.

[minor]
Is this not already documented earlier when the Length field is described?

422 4.3.  Type D: IPv6 Node Address with Optional SID for SR MPLS

[minor]
This section has similar editorial issues as section 4.2 where some fields are explained twice. Maybe optimise the formal text

494   A-Flag: This flag indicates the presence of SR Algorithm ID in the
495   "SR-Algorithm" field applicable to various segment Types.

[major]
Why not use the existence of the SR Algorithm field instead of a A-flag?

507   This section uses the term "initiator" for the node that initiates
508   the MPLS ping or MPLS traceroute procedure.  The term "responder" is
509   used for the node that receives the echo request and sends the echo
510   reply.  The term egress node is used to identify the last node where
511   the MPLS ping or traceroute is destined to.  In an MPLS network any
512   node can be initiator or responder or egress.

[minor]
What is the difference between 'responder and the 'egress node'? should they be the same node?

516   In the inter-AS scenario, the procedures described in this document
517   are used to specify the return path, if IP connectivity to the
518   initiator is not available, and may be used in any case.  The LSP

[minor]
Readability rewrite:
"In the inter-AS scenario, the procedures outlined in this document are employed to specify the return path when IP connectivity to the initiator is unavailable. These procedures may also be utilized regardless of the availability of IP connectivity.
"

529   As described in [RFC7110], when Reply mode is set to 5 (Reply via
530   Specified Path), the echo request must contain the Reply path TLV.
531   Absence of Reply Path TLV is treated as a malformed echo request.

[minor]
In previous section uppercase RFC2119 language is used. Would using MUST here not be justified?

532   When an echo request is received, if the responder does not know the
533   Reply Mode 5 defined in [RFC7110], an echo reply with the return code
534   set to "Malformed echo request received" and the Subcode set to zero
535   must be sent back to the initiator according to the rules of
536   [RFC8029].  If the echo request message contains a malformed Segment

[minor]
instead of 'does not know' i suspect what is meant is 'does not support'?

541   When a Reply Path TLV is received, the responder that supports
542   processing it, MUST use the segments in Reply Path TLV to build the
543   echo reply.  The responder MUST follow the normal FEC validation
544   procedures as described in [RFC8029] and [RFC8287] and this document
545   does not suggest any change to those procedures.  When the echo reply

[major]
If validation fails (e.g. sid does not exist or is not reachable for example) would this cause a echo reply to be returned with some error subcode?

545   does not suggest any change to those procedures.  When the echo reply
546   has to be sent out the Reply Path TLV MUST be used to construct the
547   MPLS packet to send out.

[major]
Must the MPLS label stack created by the node be an exact copy of the sid stack encoded in the Reply Path TLV? can there be MPLS labels added (for redirecting purposes or special services)?

555   segment from the Reply Path TLV.  The remaining labels MUST follow
556   the order from the Reply Path TLV.  The responder MAY check the

[major]
What if te order of labels is kept, but some other labels are inserted for steering or other purposes?

566   if such information is available from the controller or via operator
567   input.  In such cases, the node sending the echo reply MUST derive
568   the MPLS labels based on Node-SIDs associated with the IPv4/IPv6
569   addresses or from the optional MPLS SIDs in the Type-C/Type-D
570   segments and encode the echo reply with MPLS labels.

[major]
What if the Type-C/D encoded IP address does not correspond with that nodes SID? What would happen? for example IP address 1.1.1.1 has SID 111 but in the subTLV the address 1.1.1.1 is encoded with ID222. Would that give an error or is there some validation?

636   it is RECOMMENDED to add a Type-C or a Type-D segment, but
637   implementations MAY safely use other approaches if they see benefits
638   in doing so.  If the existing segment in the Reply Path TLV is a

[minor]
I am confused by the wording of other approaches? If Type-C or D is not used, only Type-A remains. Is that 'the other' approaches? If yes, then why not just say to insert Type-A?

646   When an ASBR receives an echo request from another AS, and the ASBR
647   is configured to build the return path dynamically, the ASBR should
648   build a Reply Path TLV and include it in the echo reply.  The Reply

[major]
This is most likely a clarification item. Would this result into potentially multiple Replay Path TLVs to be appended? or to have additional subTLVs (i.e. Type-A) to be inserted into the Type 21 TLV? i believe that later in the paragraph it is indicated that subTLVs are added

674   An ASBR that receives the echo request from a neighbor belonging to
675   the same AS, MUST look at the Reply Path TLV received in the echo
676   request.  If the Reply Path TLV consists of a Type-C/Type-D segment,

[minor]
IS 'receiving' correct? it is receiving and if the local SID is the top sid of the received packet then the processing takes place. Otherwise the packet is presumably MPLS switched onwards without any processing by the local node.

701 6.  Detailed Example

[major]
This is an example of the formal procedures outlined in this document.
Examples are not formal procedures and are better placed into the Appendix.

950   IANA should assign three new sub-TLVs from the "sub-TLVs for TLV
951   Types 1, 16, and 21" sub-registry of the "Multiprotocol Label
952   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
953   registry.

[major]
These subTLVs can only be in the TLV21. Should that be mentioned on the IANA page in the registry notes?

978   New entries are assigned by Standards Action.  Initial entries in the
979   registry are as follows:

[minor]
Using standards action would not allow the allocation of flags for experimental purpose.
Maybe more appropriate is to allocate using 'IETF Review' (also known as IETF Consensus)?
2024-06-25
19 Gunter Van de Velde [Ballot Position Update] Position for Gunter Van de Velde has been changed to No Objection from Discuss
2024-06-24
19 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-19.txt
2024-06-24
19 (System) New version approved
2024-06-24
19 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-06-24
19 Shraddha Hegde Uploaded new revision
2024-06-24
18 (System) Changed action holders to Jim Guichard (IESG state changed)
2024-06-24
18 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-06-24
18 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-06-24
18 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-18.txt
2024-06-24
18 (System) New version approved
2024-06-24
18 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-06-24
18 Shraddha Hegde Uploaded new revision
2024-06-13
17 (System) Changed action holders to Nagendra Nainar, Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan (IESG state changed)
2024-06-13
17 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-06-13
17 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this specificaition. Special thanks for Michael Tüxen for his TSVART review.

I have don't have any objection from transport …
[Ballot comment]
Thanks for working on this specificaition. Special thanks for Michael Tüxen for his TSVART review.

I have don't have any objection from transport protocol point of view. However, I am supporting Gunter's Discuss on a need to algorithm where we do find it, and supporting Jhon's discuss as it appears to be critical for the inter-domain use case.
2024-06-13
17 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-06-13
17 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-06-12
17 Roman Danyliw
[Ballot comment]
Thank you to Peter E. Yee for the GENART review.

** Abstract
  It is
  useful to have the Label Switched Path …
[Ballot comment]
Thank you to Peter E. Yee for the GENART review.

** Abstract
  It is
  useful to have the Label Switched Path (LSP) ping and traceroute
  procedures when an SR end-to-end path traverses multiple ASes or
  domains.

Are the multiple domains mentioned here “IGP domains”?  See below.

** Section 7
  The procedures described in this document enable LSP ping and
  traceroute to be executed across multiple IGP domains or multiple
  ASes that belong to the same administration or closely cooperating
  administrations.

I was under the impression (from RFC8402) that SR is limited to a single domain:
  By default, SR operates within a trusted domain.  Traffic MUST be
  filtered at the domain boundaries.

This text in Section 7 seems to be expanding scope.

** Section 8.3.  Editorial.  The registry name should be “Reply path return codes" – “code” is missing an “s”
2024-06-12
17 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-06-11
17 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-06-11
17 Deb Cooley [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley
2024-06-11
17 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

Thank you for the work put into this document.

Please find below some non-blocking COMMENT …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-spring-inter-domain-oam-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 one nit.

Special thanks to Adrian Farrel for the shepherd's detailed write-up including the WG consensus and a (concise) justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Section 3

`Some networks may consist of pure IPv4 domains and pure IPv6 domains` the usual terminology is rather IPv4-only and IPv6-only. The sentence is also a little unclear whether these domains can overlap (shared routers) or are disjunct.

## Section 4.3

`IPv6 Node Address` usually IPv6 addresses represent an interface (of a host), suggest to s/16-octet IPv6 address representing a node/16-octet IPv6 address of one interface of a node/

## Section 4.4

Is there any reason why the A-flag is not bit 0 ? (existing implementations of a previous I-D ?)

## Section 7

An informational reference to MACsec will be useful.

# NITS (non-blocking / cosmetic)

## Section 4.2

Suggest to explain all fields in their order in the sub-TLV.
2024-06-11
17 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-06-11
17 John Scudder
[Ballot comment]
## COMMENTS

### Section 3, if I can compute the return path I don't need to trace the route

This text made my …
[Ballot comment]
## COMMENTS

### Section 3, if I can compute the return path I don't need to trace the route

This text made my brain hurt:

                                        One of the ways this can be
  implemented on the head-end is to acquire the entire database (of all
  domains) and build a return path for every node along the SR-MPLS
  path based on the knowledge of the database. 
 
That's because, if I have the detailed topology database required to do this, I already know everything the traceroute will tell me. So why bother tracing the route? It can't be simply to verify connectivity, ping would do that, and if I want to verify that connectivity follows the expected route, I can ping with a strict source route. Furthermore, if the traceroute diverges from the expected path, it might be that replies don't come back to me, because the return path I've included might not work for nodes along the actual path.

I see that dynamically computed return path addresses these concerns. But I'm struggling to understand what value a precomputed return path, as per the quote, brings to the table.

### Section 4.1, minor comment, consistency, flow

You have,

  RESERVED: 3 octets of reserved bits.  MUST be set to zero when
  sending; MUST be ignored on receipt.

  Label: 20 bits of label value.

  TC: 3 bits of traffic class.

  S: 1 bit Reserved.

  TTL: 1 octet of TTL.

  The following applies to the Type-A Segment sub-TLV:

  The S bit MUST be zero upon transmission, and MUST be ignored upon
  reception.

Why not specify the S bit value and behavior in line just as the reserved bits are? As in,

NEW:
  RESERVED: 3 octets of reserved bits.  MUST be set to zero when
  sending; MUST be ignored on receipt.

  Label: 20 bits of label value.

  TC: 3 bits of traffic class.

  S: 1 bit Reserved.  MUST be zero upon transmission, and MUST be ignored upon
  reception.

  TTL: 1 octet of TTL.

  The following applies to the Type-A Segment sub-TLV:

  <"The S bit" line is deleted.>

### Section 4.2, why exclude Flex Algo?

You cite RFC 8402:

  SR Algorithm: 1 octet specifying SR Algorithm as described in section
  3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present.
  SR Algorithm is used by the receiver to derive the Label.  When
  A-flag is unset, this field has no meaning and thus MUST be set to
  zero on transmission and ignored on receipt.

Are you intentionally excluding flexible algorithm (RFC 9350)? If not, you might take a look at the way draft-ietf-mpls-mldp-multi-topology does this. In brief, they have a definition in their Introduction:

  A more lightweight mechanism to define constraint-based topologies is
  the Flexible Algorithm (FA) [RFC9350].  FA can be seen as creating a
  sub-topology within a topology using defined topology constraints and
  computation algorithms.  This can be done within an MTR topology or
  the default Topology.  An instance of such a sub-topology is
  identified by a 1 octet value (Flex-Algorithm) as documented in
  [RFC9350].  A flexible Algorithm is a mechanism to create a sub-
  topology, but in the future, different algorithms might be defined
  for how to achieve that.  For that reason, in the remainder of this
  document, we'll refer to this as the IGP Algorithm.
 
And then elsewhere they just refer to "IGP Algorithm". I'm not saying you have to adopt this approach, but it's one idea.

Same comment applies to Section 4.3.

### Section 4.2, SID field

It’s a little messy that what is defined as four separate fields in the previous section, here is defined as a single SID field. For consistency, I'd suggest either representing this the same way you did in section 4.1, or alternately, Section 4.1 could include text to the effect of “collectively, these four sub-fields comprise the SID field”.

### Section 5.5.1, weird use of "MAY not"

“MAY not” looks weird:

  Internal nodes or non-domain border nodes MAY not set the Reply Path
  TLV return code to TBA1 in the echo reply message as there is no
  change in the return Path.
 
Can you clarify that you really mean what this literally says as per the RFC 2119 definition of "MAY", which would be, these nodes are permitted to refrain from setting the return code, but they also can set it, it’s all good? Or, did you mean MUST NOT? if you do genuinely mean the first thing I wrote, I recommend using language different from “MAY not“, since it looks quite weird.

### General, SRGB behavior

In various places you talk about different actions depending on whether SRGB is uniform or non-uniform. I don’t think you mention anywhere how the determination of uniform or non-uniform SRGB behavior is made. Is it up to configuration? It would be good to be specific about this.

## 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
2024-06-11
17 John Scudder Ballot comment text updated for John Scudder
2024-06-11
17 John Scudder
[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17
CC @jgscudder

I can see that this document solves an important problem, thanks for your …
[Ballot discuss]
# John Scudder, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17
CC @jgscudder

I can see that this document solves an important problem, thanks for your work on it. I find a few of the consequences of the use case a little puzzling, more in my DISCUSS and comments below.

## DISCUSS

As I understand it, the motivating use case for this document is summed up by this paragraph in the introduction:

  It is not always possible to carry out LSP ping and traceroute
  functionality on these paths to verify basic connectivity and fault
  isolation using existing LSP ping and traceroute mechanisms([RFC8287]
  and [RFC8029]).  That is because there might not always be IP
  connectivity from a responding node back to the source address of the
  ping packet when the responding node is in a different AS from the
  source of the ping.

That is, you are fixing the problem where some node needs to send a packet back to the originator, but doesn't have reachability to it.

As a general thing, I think the document would benefit from more careful consideration of this in some of the sections, and I have some comments below related to that. I also have identified what looks like at least one bug --

Section 5.3 includes this requirement:

                                              If the top label is
  unreachable, the responder MUST send the appropriate return code and
  follow procedures as per section 5.2 of [RFC7110].
 
But, in this situation, the responder is unlikely to be able to successfully send any return message, because the top label is unreadable, and by definition of the use case, the responder doesn't have IP reachability to the head end.

I understand that this might be a problem that has no perfect fix, but (unless I'm just wrong, in which case please tell me!), I think you should put some more realistic guidance in this requirement.

By the way, the detailed example section was very useful, thank you. I think adding an example walk-through of an error case to that section would help elucidate this.
2024-06-11
17 John Scudder
[Ballot comment]
## COMMENTS

### Section 3, if I can compute the return path I don't need to trace the route

This text made my …
[Ballot comment]
## COMMENTS

### Section 3, if I can compute the return path I don't need to trace the route

This text made my brain hurt:

                                        One of the ways this can be
  implemented on the head-end is to acquire the entire database (of all
  domains) and build a return path for every node along the SR-MPLS
  path based on the knowledge of the database. 
 
That's because, if I have the detailed topology database required to do this, I already know everything the traceroute will tell me. So why bother tracing the route? It can't be simply to verify connectivity, ping would do that, and if I want to verify that connectivity follows the expected route, I can ping with a strict source route. Furthermore, if the traceroute diverges from the expected path, it might be that replies don't come back to me, because the return path I've included might not work for nodes along the actual path.

I see that dynamically computed return path addresses these concerns. But I'm struggling to understand what value a priori computed return path, as per the quote, brings to the table.

### Section 4.1, minor comment, consistency, flow

You have,

  RESERVED: 3 octets of reserved bits.  MUST be set to zero when
  sending; MUST be ignored on receipt.

  Label: 20 bits of label value.

  TC: 3 bits of traffic class.

  S: 1 bit Reserved.

  TTL: 1 octet of TTL.

  The following applies to the Type-A Segment sub-TLV:

  The S bit MUST be zero upon transmission, and MUST be ignored upon
  reception.

Why not specify the S bit value and behavior in line just as the reserved bits are? As in,

NEW:
  RESERVED: 3 octets of reserved bits.  MUST be set to zero when
  sending; MUST be ignored on receipt.

  Label: 20 bits of label value.

  TC: 3 bits of traffic class.

  S: 1 bit Reserved.  MUST be zero upon transmission, and MUST be ignored upon
  reception.

  TTL: 1 octet of TTL.

  The following applies to the Type-A Segment sub-TLV:

  <"The S bit" line is deleted.>

### Section 4.2, why exclude Flex Algo?

You cite RFC 8402:

  SR Algorithm: 1 octet specifying SR Algorithm as described in section
  3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present.
  SR Algorithm is used by the receiver to derive the Label.  When
  A-flag is unset, this field has no meaning and thus MUST be set to
  zero on transmission and ignored on receipt.

Are you intentionally excluding flexible algorithm (RFC 9350)? If not, you might take a look at the way draft-ietf-mpls-mldp-multi-topology does this. In brief, they have a definition in their Introduction:

  A more lightweight mechanism to define constraint-based topologies is
  the Flexible Algorithm (FA) [RFC9350].  FA can be seen as creating a
  sub-topology within a topology using defined topology constraints and
  computation algorithms.  This can be done within an MTR topology or
  the default Topology.  An instance of such a sub-topology is
  identified by a 1 octet value (Flex-Algorithm) as documented in
  [RFC9350].  A flexible Algorithm is a mechanism to create a sub-
  topology, but in the future, different algorithms might be defined
  for how to achieve that.  For that reason, in the remainder of this
  document, we'll refer to this as the IGP Algorithm.
 
And then elsewhere they just refer to "IGP Algorithm". I'm not saying you have to adopt this approach, but it's one idea.

Same comment applies to Section 4.3.

### Section 4.2, SID field

It’s a little messy that what is defined as four separate fields in the previous section, here is defined as a single SID field. For consistency, I'd suggest either representing this the same way you did in section 4.1, or alternately, Section 4.1 could include text to the effect of “collectively, these four sub-fields comprise the SID field”.

### Section 5.5.1, weird use of "MAY not"

“MAY not” looks weird:

  Internal nodes or non-domain border nodes MAY not set the Reply Path
  TLV return code to TBA1 in the echo reply message as there is no
  change in the return Path.
 
Can you clarify that you really mean what this literally says as per the RFC 2119 definition of "MAY", which would be, these nodes are permitted to refrain from setting the return code, but they also can set it, it’s all good? Or, did you mean MUST NOT? if you do genuinely mean the first thing I wrote, I recommend using language different from “MAY not“, since it looks quite weird.

### General, SRGB behavior

In various places you talk about different actions depending on whether SRGB is uniform or non-uniform. I don’t think you mention anywhere how the determination of uniform or non-uniform SRGB behavior is made. Is it up to configuration? It would be good to be specific about this.

## 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
2024-06-11
17 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2024-06-10
17 Qin Wu Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Qin Wu. Sent review to list. Submission of review completed at an earlier date.
2024-06-10
17 Qin Wu Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Qin Wu.
2024-06-10
17 Carlos Pignataro Request for Telechat review by OPSDIR is assigned to Qin Wu
2024-06-07
17 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-mpls-spring-inter-domain-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 …
[Ballot comment]
# Internet AD comments for draft-ietf-mpls-spring-inter-domain-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

### S5.3

* What should a responder do if the option SID is present but does not
  correspond to a Node SID for the associated IP address (Type C/D)?

  Depending on what you'd like to do, one option might be to make the
  IPv4/IPv6 address exclusive of the presence of a SID? (revise S4.2 & S4.3)

  In the case of an IPv6 address, the length can be used to tell whether
  it's an address or a SID.  In the IPv4 case it might be necessary to take
  a flag bit to indicate the contents of a 32-bit field.
2024-06-07
17 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-06-07
Tess Chapeta Posted related IPR disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-mpls-spring-inter-domain-oam
2024-06-06
17 Gunter Van de Velde
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR …
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson and for the shepherd writeup by Adrian Farrel.

Many thanks for this write-up. It is well written. I did find when reading the document that some constructs were presented more complex as necessary.

Please find in this review three blocking DISCUSS observations, followed by non-blocking high-level observations. Additionally, there is a set of detailed comments categorized as [minor] and [major] observations, which I hope you will find useful for improving the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existence of an SR Algorithm in the TypeC/D subTLVs not be sufficient? It implicit suggests that there is an algorithm?

##DISCUSS2
What should be done when, for Type-C and D, the encoded IP address does not match the encoded SID for the node or the correct algorithm for that node? Is there a validation process or error messaging in place?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.
2024-06-06
17 Gunter Van de Velde Ballot discuss text updated for Gunter Van de Velde
2024-06-06
17 Gunter Van de Velde
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR …
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson and for the shepherd writeup by Adrian Farrel.

Many thanks for this write-up. It is well written. I did find when reading the document that some constructs were presented more complex as necessary.

Please find in this review three blocking DISCUSS observations, followed by non-blocking high-level observations. Additionally, there is a set of detailed comments categorized as [minor] and [major] observations, which I hope you will find useful for improving the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existence of an SR Algorithm in the TypeC/D subTLVs not be sufficient? It implicit suggests that there is an algorithm?

##DISCUSS2
What to do when for Type-C and D the encoded IP address does not match with the encoded SID for the node or with the correct algorithm for such node? Is there any validation or error messaging?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.
2024-06-06
17 Gunter Van de Velde
[Ballot comment]
#GENERIC COMMENTS
#================
##There is some usage of RFC2119 normative language that may not be needed in some sections. Some have been flagged …
[Ballot comment]
#GENERIC COMMENTS
#================
##There is some usage of RFC2119 normative language that may not be needed in some sections. Some have been flagged in the detail review

##The SID is encoded with only a label in the Type-A/C/D. SR also allows a SID to be an index instead of a label. Is there a reason why index was excluded?

##with the explanation of the Type-A/C/D subTLVs there was some duplicate text for explaining the fields. I would suggest to revise and the fields and the formal procedures only once per Type. Now some fields are described twice in the same section

##Section 6 details an example. Examples are not formal normative procedures. It seems more opportune to place the example in Appendix to reduce the formal part of the draft and to clearly identify it is informational. It makes the main part of the formal procedure of the RFC less long

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

26   domains.  This document describes mechanisms to facilitate LSP ping
27   and traceroute in inter-AS and inter-domain SR-MPLS networks
28   efficiently with a simple Operations, Administration and Maintenance
29   (OAM) protocol extension which uses data plane forwarding alone for
30   forwarding echo replies on transit nodes.

[minor]
I got confused wit the wording of 'alone' and am not convinced it is used correctly.

"This document outlines mechanisms to enable efficient LSP ping and traceroute in inter-AS and inter-domain SR-MPLS networks through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes."

115   [RFC8660] specifies SR with an MPLS data plane.  [RFC8402] describes
116   BGP peering SIDs, and [RFC9087] describes Egress Peer Engineering,

[minor]
s/BGP peering SIDs/BGP Peering Segments/
s/Egress Peer Engineering/Centralized BGP Egress Peer Engineering/

117   which will help in steering packets from one AS to another.  Using
118   the above SR capabilities, paths that span across multiple ASes can
119   be created.

[minor]
slight rewrite from readability perspective:
"By utilizing these SR capabilities, it is possible to create paths that span multiple ASes."

192   SR label stack.  The return path can either be derived by a smart
193   application or controller that has a full topology view.  This
194   document also proposes mechanisms to derive the return path
195   dynamically during traceroute procedures.

[major]
I am not sure what is a 'smart' application or controller. Is a full topology view really required? a topology view of the network section being investigated seems sufficient, not?

197   The current document is focused on the inter-domain use case.
198   However, the protocol extensions described in this document may be
199   applied to indicate the return path for other use cases as well,
200   which are out-of-scope for this document and therefore not further
201   described in this document.  SRv6 data plane is not in the scope of
202   this document.

[minor]
Why is the text seems complicated constructed. What about the following:

"This document focuses on the inter-domain use case. The protocol extensions described may also indicate the return path for other use cases, which are outside the scope of this document and are not further detailed here. The SRv6 data plane is also not covered in this document."

204 1.1.  Definition of Domain

206   The term domain used in this document implies an IGP domain where
207   every node is visible to every other node for shortest path
208   computation.  The domain implies an IGP area or level.  An AS
209   consists of one or more IGP domains.  The procedures described in
210   this document apply to paths built across multiple domains which
211   include inter-area as well as inter-AS paths.  The procedures and
212   deployment scenarios described in this document apply to inter-AS
213   paths where the participating ASes belong to closely coordinating
214   administrations or to single ownership.  This document applies to SR-
215   MPLS networks where all nodes in each of the domains are SR capable.
216   It also applies to SR-MPLS networks where SR acts as an overlay
217   having SR-incapable underlay nodes.  In such networks, the traceroute
218   procedure is executed only on the overlay SR nodes.

[minor]
I found this section hard to parse. The following text proposal processes slightly better:

"In this document, the term "domain" refers to an IGP domain where every node is visible to every other node for the purpose of shortest path computation, implying an IGP area or level. An Autonomous System (AS) comprises one or more IGP domains. The procedures described herein are applicable to paths constructed across multiple domains, including both inter-area and inter-AS paths. These procedures and deployment scenarios are relevant for inter-AS paths where the participating ASes are under closely coordinating administrations or single ownership. This document pertains to SR-MPLS networks where all nodes within each domain are SR-capable. It also applies to SR-MPLS networks where SR functions as an overlay with SR-incapable underlay nodes. In such networks, the traceroute procedure is executed only on the overlay SR nodes.
"

253   Reply Path (RP) TLV is defined in [RFC7110].  SR networks statically
254   assign the labels to nodes and a PMS/head-end may know the entire
255   database.  The reverse path can be built from the PMS/head-end by

[major]
What for database? The LSDB? a database with the all the nodes and assigned SIDs? something else?

265   The type of segment that the head-end chooses to send in the Reply
266   Path TLV is governed by local policy.  Implementations MAY provide
267   Command Line Interface (CLI) input parameters in the form of Labels/
268   IPv4 addresses/IPv6 addresses or a combination of these which get
269   encoded in the Reply Path TLV.  Implementations MAY also provide
270   mechanisms to acquire the database of remote domains and compute the
271   return path based on the acquired database.  For traceroute purposes,
272   the return path will have to consider the reply being sent from every
273   node along the path.  The return path changes when the traceroute

[major]
I do not understand why these are uppercase MAY? no formal protocol procedures are provided in this section? consider lower case as it distracts from formal protocol procedures

[major]
The term 'database' is unclear. What for database is exactly intended? A node may have many databases

279   Some networks may consist of pure IPv4 domains and pure IPv6 domains.
280   Handling end-to-end MPLS OAM for such networks is out of the scope of
281   this document.  It is recommended to use dual-stack in such cases and
282   use end-to-end IPv6 addresses for MPLS ping and traceroute
283   procedures.

[minor]
Clarification: I suspect that it is intended to indicate that it is pure ipv4-only or ipv6-only networks?

295   The below types of Segment sub-TLVs apply to the Reply Path TLV.  The
296   code points for the sub-TLVs are taken from the IANA registry common
297   to TLVs 1, 16, and 21.  This document defines the Segment sub-TLVs
298   usage and processing when it appears in TLV 21.  If these sub-TLVs
299   appear in TLVs 1 or 16, appropriate error codes MUST be returned as
300   defined in [RFC8029].

[major]
While the text here is is not wrong, it is confusing type-A/C/D and then three code-point TLVs... The text should be more explit that code points punt towards:
1 Target FEC Stack
16 Reverse-path Target FEC Stack
21 Reply Path

and be more explicit that the new defined sub-TLVs are only to be used with TLV21 (Reply Path TLV).

327   Type: TBD1(to be assigned by IANA from the registry "Sub-TLVs for TLV
328   Types 1, 16, and 21").

[minor]
Should it not specify a field length of 2 octets?

330   Length: 2 octets.  Carries value 8.  The length excludes the length
331   of the Type and Length Fields.

[minor]
The length "value" exclude....

335   RESERVED: 3 octets of reserved bits.  MUST be set to zero when
336   sending; MUST be ignored on receipt.

[minor]
I believe that the declaration for reserved is the correct one, but want to double check. If there is any potential that in future these bits may be used, then instead Future Use may be better choice.

342   S: 1 bit Reserved.

[minor]
few lines above the RESERVED 3 octets were described directly, however the formal procedure for handling S bit is explained later in the text, which is inconsistent

390   Length: 2 octets.  Carries value 8 without SID included or 12 with
391   SID included.

[minor]
The text should be more prescriptive.
"Caries value 8 when no optional SID is included or value 12 when optional SID is included."

395   SR Algorithm: 1 octet specifying SR Algorithm as described in section
396   3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present.
397   SR Algorithm is used by the receiver to derive the Label.  When
398   A-flag is unset, this field has no meaning and thus MUST be set to
399   zero on transmission and ignored on receipt.

[major]
Is the algorithm not always used by the received to derive the used label?
the algorithm is either 0 (or 1) or one of the flex-algorithms.
Iam not sure why there is an A-flag? could the setting of AR Algorithm not implicit assume that there is an SR Algorithm? why a specific A-fleg?

404   IPv4 Node Address: 4-octet IPv4 address representing a node.

[minor]
Should it be mentioned that this should be best a stable address (e.g a loopback address?)

406   SID: optional: 4-octet field containing label, TC, S and TTL as
407   defined in Section 4.1.  When the SID field is present, it MUST be
408   used for constructing the Reply Path.

[major]
A SID can be a label or an index. Is there a reason to exclude the index type of SID? (see: https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.2 )

414   The SID is optional and specifies a 4-octet MPLS SID containing
415   label, TC, S and TTL as defined in Section 4.1.

[minor]
Seems duplicate text meanings already documented in line406-408

417   If the length is 8, then only the IPv4 Node Address is present.
419   If the length is 12, then the IPv4 Node Address and the MPLS SID are
420   present.

[minor]
Is this not already documented earlier when the Length field is described?

422 4.3.  Type D: IPv6 Node Address with Optional SID for SR MPLS

[minor]
This section has similar editorial issues as section 4.2 where some fields are explained twice. Maybe optimise the formal text

494   A-Flag: This flag indicates the presence of SR Algorithm ID in the
495   "SR-Algorithm" field applicable to various segment Types.

[major]
Why not use the existence of the SR Algorithm field instead of a A-flag?

507   This section uses the term "initiator" for the node that initiates
508   the MPLS ping or MPLS traceroute procedure.  The term "responder" is
509   used for the node that receives the echo request and sends the echo
510   reply.  The term egress node is used to identify the last node where
511   the MPLS ping or traceroute is destined to.  In an MPLS network any
512   node can be initiator or responder or egress.

[minor]
What is the difference between 'responder and the 'egress node'? should they be the same node?

516   In the inter-AS scenario, the procedures described in this document
517   are used to specify the return path, if IP connectivity to the
518   initiator is not available, and may be used in any case.  The LSP

[minor]
Readability rewrite:
"In the inter-AS scenario, the procedures outlined in this document are employed to specify the return path when IP connectivity to the initiator is unavailable. These procedures may also be utilized regardless of the availability of IP connectivity.
"

529   As described in [RFC7110], when Reply mode is set to 5 (Reply via
530   Specified Path), the echo request must contain the Reply path TLV.
531   Absence of Reply Path TLV is treated as a malformed echo request.

[minor]
In previous section uppercase RFC2119 language is used. Would using MUST here not be justified?

532   When an echo request is received, if the responder does not know the
533   Reply Mode 5 defined in [RFC7110], an echo reply with the return code
534   set to "Malformed echo request received" and the Subcode set to zero
535   must be sent back to the initiator according to the rules of
536   [RFC8029].  If the echo request message contains a malformed Segment

[minor]
instead of 'does not know' i suspect what is meant is 'does not support'?

541   When a Reply Path TLV is received, the responder that supports
542   processing it, MUST use the segments in Reply Path TLV to build the
543   echo reply.  The responder MUST follow the normal FEC validation
544   procedures as described in [RFC8029] and [RFC8287] and this document
545   does not suggest any change to those procedures.  When the echo reply

[major]
If validation fails (e.g. sid does not exist or is not reachable for example) would this cause a echo reply to be returned with some error subcode?

545   does not suggest any change to those procedures.  When the echo reply
546   has to be sent out the Reply Path TLV MUST be used to construct the
547   MPLS packet to send out.

[major]
Must the MPLS label stack created by the node be an exact copy of the sid stack encoded in the Reply Path TLV? can there be MPLS labels added (for redirecting purposes or special services)?

555   segment from the Reply Path TLV.  The remaining labels MUST follow
556   the order from the Reply Path TLV.  The responder MAY check the

[major]
What if te order of labels is kept, but some other labels are inserted for steering or other purposes?

566   if such information is available from the controller or via operator
567   input.  In such cases, the node sending the echo reply MUST derive
568   the MPLS labels based on Node-SIDs associated with the IPv4/IPv6
569   addresses or from the optional MPLS SIDs in the Type-C/Type-D
570   segments and encode the echo reply with MPLS labels.

[major]
What if the Type-C/D encoded IP address does not correspond with that nodes SID? What would happen? for example IP address 1.1.1.1 has SID 111 but in the subTLV the address 1.1.1.1 is encoded with ID222. Would that give an error or is there some validation?

636   it is RECOMMENDED to add a Type-C or a Type-D segment, but
637   implementations MAY safely use other approaches if they see benefits
638   in doing so.  If the existing segment in the Reply Path TLV is a

[minor]
I am confused by the wording of other approaches? If Type-C or D is not used, only Type-A remains. Is that 'the other' approaches? If yes, then why not just say to insert Type-A?

646   When an ASBR receives an echo request from another AS, and the ASBR
647   is configured to build the return path dynamically, the ASBR should
648   build a Reply Path TLV and include it in the echo reply.  The Reply

[major]
This is most likely a clarification item. Would this result into potentially multiple Replay Path TLVs to be appended? or to have additional subTLVs (i.e. Type-A) to be inserted into the Type 21 TLV? i believe that later in the paragraph it is indicated that subTLVs are added

674   An ASBR that receives the echo request from a neighbor belonging to
675   the same AS, MUST look at the Reply Path TLV received in the echo
676   request.  If the Reply Path TLV consists of a Type-C/Type-D segment,

[minor]
IS 'receiving' correct? it is receiving and if the local SID is the top sid of the received packet then the processing takes place. Otherwise the packet is presumably MPLS switched onwards without any processing by the local node.

701 6.  Detailed Example

[major]
This is an example of the formal procedures outlined in this document.
Examples are not formal procedures and are better placed into the Appendix.

950   IANA should assign three new sub-TLVs from the "sub-TLVs for TLV
951   Types 1, 16, and 21" sub-registry of the "Multiprotocol Label
952   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
953   registry.

[major]
These subTLVs can only be in the TLV21. Should that be mentioned on the IANA page in the registry notes?

978   New entries are assigned by Standards Action.  Initial entries in the
979   registry are as follows:

[minor]
Using standards action would not allow the allocation of flags for experimental purpose.
Maybe more appropriate is to allocate using 'IETF Review' (also known as IETF Consensus)?
2024-06-06
17 Gunter Van de Velde Ballot comment and discuss text updated for Gunter Van de Velde
2024-06-06
17 Gunter Van de Velde
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR …
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson and for the shepherd writeup by Adrian Farrel.

Many thanks for this write-up. It is well written. I did find when reading the document that some constructs were presented more complex as necessary.

Please find in this review three blocking DISCUSS observations, followed by non-blocking high-level observations. Additionally, there is a set of detailed comments categorized as [minor] and [major] observations, which I hope you will find useful for improving the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existance of an SR ALgorithm not be sufficient? It implicit suggests that there is an algorthm?

##DISCUSS2
What to do when for Type-C and D the encoded IP address does not match with the encoded SID for the node or with the correct algorithm for such node? Is there any validation or error messaging?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.
2024-06-06
17 Gunter Van de Velde Ballot discuss text updated for Gunter Van de Velde
2024-06-06
17 Gunter Van de Velde
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR …
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson.

Many thanks for this write-up. It is well written. I did find when reading the document that some parts were presented more complex as necessary.

Please find in this review three blocking DISCUSS observations, followed by non-blocking high-level observations. Additionally, there is a set of detailed comments categorized as [minor] and [major] observations, which I hope you will find useful for improving the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existance of an SR ALgorithm not be sufficient? It implicit suggests that there is an algorthm?

##DISCUSS2
What to do when for Type-C and D the encoded IP address does not match with the encoded SID for the node or with the correct algorithm for such node? Is there any validation or error messaging?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.
2024-06-06
17 Gunter Van de Velde Ballot discuss text updated for Gunter Van de Velde
2024-06-06
17 Gunter Van de Velde
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR …
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson.

Many thanks for this write-up. It is well written. I did find when reading the document that some parts were presented more complex as necessary.

Please find in this review 3 blocking DISCUSS observations followed with non-blocking high-level observations and a set of Detailed comments that you may want to address classified as [minor] and [major] observations for which i hope you find useful to improve the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existance of an SR ALgorithm not be sufficient? It implicit suggests that there is an algorthm?

##DISCUSS2
What to do when for Type-C and D the encoded IP address does not match with the encoded SID for the node or with the correct algorithm for such node? Is there any validation or error messaging?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.

##DISCUSS4
Section 6 details an example. Examples are not formal normative procedures. It seems more opportune to place the example in Appendix to reduce the formal part of the draft and to clearly identify it is informational. It makes the main part of the formal procedure of the RFC less long
2024-06-06
17 Gunter Van de Velde Ballot discuss text updated for Gunter Van de Velde
2024-06-06
17 Gunter Van de Velde
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR …
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson.

Many thanks for this write-up. It is well written. I did find when reading the document that some parts were presented more complex as necessary.

Please find below 3 blocking DISCUSS observations followed with some generic high level observations and a set of Detailed comments that you may want to address classified as [minor] and [major] observations for which i hope you find useful to improve the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existance of an SR ALgorithm not be sufficient? It implicit suggests that there is an algorthm?

##DISCUSS2
What to do when for Type-C and D the encoded IP address does not match with the encoded SID for the node or with the correct algorithm for such node? Is there any validation or error messaging?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.

##DISCUSS4
Section 6 details an example. Examples are not formal normative procedures. It seems more opportune to place the example in Appendix to reduce the formal part of the draft and to clearly identify it is informational. It makes the main part of the formal procedure of the RFC less long
2024-06-06
17 Gunter Van de Velde Ballot discuss text updated for Gunter Van de Velde
2024-06-06
17 Gunter Van de Velde
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR …
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson.

Many thanks for this write-up. It is well written. I did find when reading the document that some parts felt written more complex as necessary.

Please find below 3 blocking DISCUSS observations followed with some generic high level observations and a set of Detailed comments that you may want to address classified as [minor] and [major] observations for which i hope you find useful to improve the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existance of an SR ALgorithm not be sufficient? It implicit suggests that there is an algorthm?

##DISCUSS2
What to do when for Type-C and D the encoded IP address does not match with the encoded SID for the node or with the correct algorithm for such node? Is there any validation or error messaging?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.

##DISCUSS4
Section 6 details an example. Examples are not formal normative procedures. It seems more opportune to place the example in Appendix to reduce the formal part of the draft and to clearly identify it is informational. It makes the main part of the formal procedure of the RFC less long
2024-06-06
17 Gunter Van de Velde
[Ballot comment]
#GENERIC COMMENTS
#================
##There is some usage of RFC2119 normative language that may not be needed in some sections. Some have been flagged …
[Ballot comment]
#GENERIC COMMENTS
#================
##There is some usage of RFC2119 normative language that may not be needed in some sections. Some have been flagged in the detail review

##The SID is encoded with only a label in the Type-C/D. SR allows a SID to be an index or a label. Is there a reason why index was excluded? if so, maybe best to explicit mention that index is not supported

##with the explanation of the Type-A/C/D subTLVs there was some duplicate text for explaining the fields. I would suggest to revise and the fields and the formal procedures only once per Type. Now some fields are described twice in the same section

##Section 6 details an example. Examples are not formal normative procedures. It seems more opportune to place the example in Appendix to reduce the formal part of the draft and to clearly identify it is informational. It makes the main part of the formal procedure of the RFC less long

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

26   domains.  This document describes mechanisms to facilitate LSP ping
27   and traceroute in inter-AS and inter-domain SR-MPLS networks
28   efficiently with a simple Operations, Administration and Maintenance
29   (OAM) protocol extension which uses data plane forwarding alone for
30   forwarding echo replies on transit nodes.

[minor]
I got confused wit the wording of 'alone' and am not convinced it is used correctly.

"This document outlines mechanisms to enable efficient LSP ping and traceroute in inter-AS and inter-domain SR-MPLS networks through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes."

115   [RFC8660] specifies SR with an MPLS data plane.  [RFC8402] describes
116   BGP peering SIDs, and [RFC9087] describes Egress Peer Engineering,

[minor]
s/BGP peering SIDs/BGP Peering Segments/
s/Egress Peer Engineering/Centralized BGP Egress Peer Engineering/

117   which will help in steering packets from one AS to another.  Using
118   the above SR capabilities, paths that span across multiple ASes can
119   be created.

[minor]
slight rewrite from readability perspective:
"By utilizing these SR capabilities, it is possible to create paths that span multiple ASes."

192   SR label stack.  The return path can either be derived by a smart
193   application or controller that has a full topology view.  This
194   document also proposes mechanisms to derive the return path
195   dynamically during traceroute procedures.

[major]
I am not sure what is a 'smart' application or controller. Is a full topology view really required? a topology view of the network section being investigated seems sufficient, not?

197   The current document is focused on the inter-domain use case.
198   However, the protocol extensions described in this document may be
199   applied to indicate the return path for other use cases as well,
200   which are out-of-scope for this document and therefore not further
201   described in this document.  SRv6 data plane is not in the scope of
202   this document.

[minor]
Why is the text seems complicated constructed. What about the following:

"This document focuses on the inter-domain use case. The protocol extensions described may also indicate the return path for other use cases, which are outside the scope of this document and are not further detailed here. The SRv6 data plane is also not covered in this document."

204 1.1.  Definition of Domain

206   The term domain used in this document implies an IGP domain where
207   every node is visible to every other node for shortest path
208   computation.  The domain implies an IGP area or level.  An AS
209   consists of one or more IGP domains.  The procedures described in
210   this document apply to paths built across multiple domains which
211   include inter-area as well as inter-AS paths.  The procedures and
212   deployment scenarios described in this document apply to inter-AS
213   paths where the participating ASes belong to closely coordinating
214   administrations or to single ownership.  This document applies to SR-
215   MPLS networks where all nodes in each of the domains are SR capable.
216   It also applies to SR-MPLS networks where SR acts as an overlay
217   having SR-incapable underlay nodes.  In such networks, the traceroute
218   procedure is executed only on the overlay SR nodes.

[minor]
I found this section hard to parse. The following text proposal processes slightly better:

"In this document, the term "domain" refers to an IGP domain where every node is visible to every other node for the purpose of shortest path computation, implying an IGP area or level. An Autonomous System (AS) comprises one or more IGP domains. The procedures described herein are applicable to paths constructed across multiple domains, including both inter-area and inter-AS paths. These procedures and deployment scenarios are relevant for inter-AS paths where the participating ASes are under closely coordinating administrations or single ownership. This document pertains to SR-MPLS networks where all nodes within each domain are SR-capable. It also applies to SR-MPLS networks where SR functions as an overlay with SR-incapable underlay nodes. In such networks, the traceroute procedure is executed only on the overlay SR nodes.
"

253   Reply Path (RP) TLV is defined in [RFC7110].  SR networks statically
254   assign the labels to nodes and a PMS/head-end may know the entire
255   database.  The reverse path can be built from the PMS/head-end by

[major]
What for database? The LSDB? a database with the all the nodes and assigned SIDs? something else?

265   The type of segment that the head-end chooses to send in the Reply
266   Path TLV is governed by local policy.  Implementations MAY provide
267   Command Line Interface (CLI) input parameters in the form of Labels/
268   IPv4 addresses/IPv6 addresses or a combination of these which get
269   encoded in the Reply Path TLV.  Implementations MAY also provide
270   mechanisms to acquire the database of remote domains and compute the
271   return path based on the acquired database.  For traceroute purposes,
272   the return path will have to consider the reply being sent from every
273   node along the path.  The return path changes when the traceroute

[major]
I do not understand why these are uppercase MAY? no formal protocol procedures are provided in this section? consider lower case as it distracts from formal protocol procedures

[major]
The term 'database' is unclear. What for database is exactly intended? A node may have many databases

279   Some networks may consist of pure IPv4 domains and pure IPv6 domains.
280   Handling end-to-end MPLS OAM for such networks is out of the scope of
281   this document.  It is recommended to use dual-stack in such cases and
282   use end-to-end IPv6 addresses for MPLS ping and traceroute
283   procedures.

[minor]
Clarification: I suspect that it is intended to indicate that it is pure ipv4-only or ipv6-only networks?

295   The below types of Segment sub-TLVs apply to the Reply Path TLV.  The
296   code points for the sub-TLVs are taken from the IANA registry common
297   to TLVs 1, 16, and 21.  This document defines the Segment sub-TLVs
298   usage and processing when it appears in TLV 21.  If these sub-TLVs
299   appear in TLVs 1 or 16, appropriate error codes MUST be returned as
300   defined in [RFC8029].

[major]
While the text here is is not wrong, it is confusing type-A/C/D and then three code-point TLVs... The text should be more explit that code points punt towards:
1 Target FEC Stack
16 Reverse-path Target FEC Stack
21 Reply Path

and be more explicit that the new defined sub-TLVs are only to be used with TLV21 (Reply Path TLV).

327   Type: TBD1(to be assigned by IANA from the registry "Sub-TLVs for TLV
328   Types 1, 16, and 21").

[minor]
Should it not specify a field length of 2 octets?

330   Length: 2 octets.  Carries value 8.  The length excludes the length
331   of the Type and Length Fields.

[minor]
The length "value" exclude....

335   RESERVED: 3 octets of reserved bits.  MUST be set to zero when
336   sending; MUST be ignored on receipt.

[minor]
I believe that the declaration for reserved is the correct one, but want to double check. If there is any potential that in future these bits may be used, then instead Future Use may be better choice.

342   S: 1 bit Reserved.

[minor]
few lines above the RESERVED 3 octets were described directly, however the formal procedure for handling S bit is explained later in the text, which is inconsistent

390   Length: 2 octets.  Carries value 8 without SID included or 12 with
391   SID included.

[minor]
The text should be more prescriptive.
"Caries value 8 when no optional SID is included or value 12 when optional SID is included."

395   SR Algorithm: 1 octet specifying SR Algorithm as described in section
396   3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present.
397   SR Algorithm is used by the receiver to derive the Label.  When
398   A-flag is unset, this field has no meaning and thus MUST be set to
399   zero on transmission and ignored on receipt.

[major]
Is the algorithm not always used by the received to derive the used label?
the algorithm is either 0 (or 1) or one of the flex-algorithms.
Iam not sure why there is an A-flag? could the setting of AR Algorithm not implicit assume that there is an SR Algorithm? why a specific A-fleg?

404   IPv4 Node Address: 4-octet IPv4 address representing a node.

[minor]
Should it be mentioned that this should be best a stable address (e.g a loopback address?)

406   SID: optional: 4-octet field containing label, TC, S and TTL as
407   defined in Section 4.1.  When the SID field is present, it MUST be
408   used for constructing the Reply Path.

[major]
A SID can be a label or an index. Is there a reason to exclude the index type of SID? (see: https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.2 )

414   The SID is optional and specifies a 4-octet MPLS SID containing
415   label, TC, S and TTL as defined in Section 4.1.

[minor]
Seems duplicate text meanings already documented in line406-408

417   If the length is 8, then only the IPv4 Node Address is present.
419   If the length is 12, then the IPv4 Node Address and the MPLS SID are
420   present.

[minor]
Is this not already documented earlier when the Length field is described?

422 4.3.  Type D: IPv6 Node Address with Optional SID for SR MPLS

[minor]
This section has similar editorial issues as section 4.2 where some fields are explained twice. Maybe optimise the formal text

494   A-Flag: This flag indicates the presence of SR Algorithm ID in the
495   "SR-Algorithm" field applicable to various segment Types.

[major]
Why not use the existence of the SR Algorithm field instead of a A-flag?

507   This section uses the term "initiator" for the node that initiates
508   the MPLS ping or MPLS traceroute procedure.  The term "responder" is
509   used for the node that receives the echo request and sends the echo
510   reply.  The term egress node is used to identify the last node where
511   the MPLS ping or traceroute is destined to.  In an MPLS network any
512   node can be initiator or responder or egress.

[minor]
What is the difference between 'responder and the 'egress node'? should they be the same node?

516   In the inter-AS scenario, the procedures described in this document
517   are used to specify the return path, if IP connectivity to the
518   initiator is not available, and may be used in any case.  The LSP

[minor]
Readability rewrite:
"In the inter-AS scenario, the procedures outlined in this document are employed to specify the return path when IP connectivity to the initiator is unavailable. These procedures may also be utilized regardless of the availability of IP connectivity.
"

529   As described in [RFC7110], when Reply mode is set to 5 (Reply via
530   Specified Path), the echo request must contain the Reply path TLV.
531   Absence of Reply Path TLV is treated as a malformed echo request.

[minor]
In previous section uppercase RFC2119 language is used. Would using MUST here not be justified?

532   When an echo request is received, if the responder does not know the
533   Reply Mode 5 defined in [RFC7110], an echo reply with the return code
534   set to "Malformed echo request received" and the Subcode set to zero
535   must be sent back to the initiator according to the rules of
536   [RFC8029].  If the echo request message contains a malformed Segment

[minor]
instead of 'does not know' i suspect what is meant is 'does not support'?

541   When a Reply Path TLV is received, the responder that supports
542   processing it, MUST use the segments in Reply Path TLV to build the
543   echo reply.  The responder MUST follow the normal FEC validation
544   procedures as described in [RFC8029] and [RFC8287] and this document
545   does not suggest any change to those procedures.  When the echo reply

[major]
If validation fails (e.g. sid does not exist or is not reachable for example) would this cause a echo reply to be returned with some error subcode?

545   does not suggest any change to those procedures.  When the echo reply
546   has to be sent out the Reply Path TLV MUST be used to construct the
547   MPLS packet to send out.

[major]
Must the MPLS label stack created by the node be an exact copy of the sid stack encoded in the Reply Path TLV? can there be MPLS labels added (for redirecting purposes or special services)?

555   segment from the Reply Path TLV.  The remaining labels MUST follow
556   the order from the Reply Path TLV.  The responder MAY check the

[major]
What if te order of labels is kept, but some other labels are inserted for steering or other purposes?

566   if such information is available from the controller or via operator
567   input.  In such cases, the node sending the echo reply MUST derive
568   the MPLS labels based on Node-SIDs associated with the IPv4/IPv6
569   addresses or from the optional MPLS SIDs in the Type-C/Type-D
570   segments and encode the echo reply with MPLS labels.

[major]
What if the Type-C/D encoded IP address does not correspond with that nodes SID? What would happen? for example IP address 1.1.1.1 has SID 111 but in the subTLV the address 1.1.1.1 is encoded with ID222. Would that give an error or is there some validation?

636   it is RECOMMENDED to add a Type-C or a Type-D segment, but
637   implementations MAY safely use other approaches if they see benefits
638   in doing so.  If the existing segment in the Reply Path TLV is a

[minor]
I am confused by the wording of other approaches? If Type-C or D is not used, only Type-A remains. Is that 'the other' approaches? If yes, then why not just say to insert Type-A?

646   When an ASBR receives an echo request from another AS, and the ASBR
647   is configured to build the return path dynamically, the ASBR should
648   build a Reply Path TLV and include it in the echo reply.  The Reply

[major]
This is most likely a clarification item. Would this result into potentially multiple Replay Path TLVs to be appended? or to have additional subTLVs (i.e. Type-A) to be inserted into the Type 21 TLV? i believe that later in the paragraph it is indicated that subTLVs are added

674   An ASBR that receives the echo request from a neighbor belonging to
675   the same AS, MUST look at the Reply Path TLV received in the echo
676   request.  If the Reply Path TLV consists of a Type-C/Type-D segment,

[minor]
IS 'receiving' correct? it is receiving and if the local SID is the top sid of the received packet then the processing takes place. Otherwise the packet is presumably MPLS switched onwards without any processing by the local node.

701 6.  Detailed Example

[major]
This is an example of the formal procedures outlined in this document.
Examples are not formal procedures and are better placed into the Appendix.

950   IANA should assign three new sub-TLVs from the "sub-TLVs for TLV
951   Types 1, 16, and 21" sub-registry of the "Multiprotocol Label
952   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
953   registry.

[major]
These subTLVs can only be in the TLV21. Should that be mentioned on the IANA page in the registry notes?

978   New entries are assigned by Standards Action.  Initial entries in the
979   registry are as follows:

[minor]
Using standards action would not allow the allocation of flags for experimental purpose.
Maybe more appropriate is to allocate using 'IETF Review' (also known as IETF Consensus)?
2024-06-06
17 Gunter Van de Velde Ballot comment and discuss text updated for Gunter Van de Velde
2024-06-06
17 Gunter Van de Velde
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR …
[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-spring-inter-domain-oam-17

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

Many thanks for the RTG-DIR reviews from Stig Venaas and Michael Richardson.

Many thanks for this write-up. It is well written. I did find when reading the document that some parts felt written more complex as necessary.

Please find below 4 blocking DISCUSS observations followed with some generic high level observations and a set of Detailed comments that you may want to address classified as [minor] and [major] observations for which i hope you find useful to improve the document.

#DISCUSS items
#=============
##DISCUSS1
Why is there the A-flag? would the existance of an SR ALgorithm not be sufficient? It implicit suggests that there is an algorthm?

##DISCUSS2
What to do when for Type-C and D the encoded IP address does not match with the encoded SID for the node or with the correct algorithm for such node? Is there any validation or error messaging?

##DISCUSS3
section 5.3 documents that "An MPLS packet is constructed with an echo reply where the top label MUST be constructed from the first segment from the Reply Path TLV while the remaining labels MUST follow the order from the Reply Path TLV".  This text seems to allow that random segments can be inserted as long as the original ordering is kept. Is that intentional? if yes, such prescribed behavior should be explicitly documented. If not allowed, then that should be included in formal procedure rules.

##DISCUSS4
Section 6 details an example. Examples are not formal normative procedures. It seems more opportune to place the example in Appendix to reduce the formal part of the draft and to clearly identify it is informational. It makes the main part of the formal procedure of the RFC less long
2024-06-06
17 Gunter Van de Velde
[Ballot comment]
#GENERIC COMMENTS
#================
##There is some usage of RFC2119 normative language that may not be needed in some sections. Some have been flagged …
[Ballot comment]
#GENERIC COMMENTS
#================
##There is some usage of RFC2119 normative language that may not be needed in some sections. Some have been flagged in the detail review

##The SID is encoded with only a label in the Type-C/D. SR allows a SID to be an index or a label. Is there a reason why index was excluded? if so, maybe best to explicit mention that index is not supported

##with the explanation of the Type-A/C/D subTLVs there was some duplicate text for explaining the fields. I would suggest to revise and the fields and the formal procedures only once per Type. Now some fields are described twice in the same section



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

26   domains.  This document describes mechanisms to facilitate LSP ping
27   and traceroute in inter-AS and inter-domain SR-MPLS networks
28   efficiently with a simple Operations, Administration and Maintenance
29   (OAM) protocol extension which uses data plane forwarding alone for
30   forwarding echo replies on transit nodes.

[minor]
I got confused wit the wording of 'alone' and am not convinced it is used correctly.

"This document outlines mechanisms to enable efficient LSP ping and traceroute in inter-AS and inter-domain SR-MPLS networks through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes."

115   [RFC8660] specifies SR with an MPLS data plane.  [RFC8402] describes
116   BGP peering SIDs, and [RFC9087] describes Egress Peer Engineering,

[minor]
s/BGP peering SIDs/BGP Peering Segments/
s/Egress Peer Engineering/Centralized BGP Egress Peer Engineering/

117   which will help in steering packets from one AS to another.  Using
118   the above SR capabilities, paths that span across multiple ASes can
119   be created.

[minor]
slight rewrite from readability perspective:
"By utilizing these SR capabilities, it is possible to create paths that span multiple ASes."

192   SR label stack.  The return path can either be derived by a smart
193   application or controller that has a full topology view.  This
194   document also proposes mechanisms to derive the return path
195   dynamically during traceroute procedures.

[major]
I am not sure what is a 'smart' application or controller. Is a full topology view really required? a topology view of the network section being investigated seems sufficient, not?

197   The current document is focused on the inter-domain use case.
198   However, the protocol extensions described in this document may be
199   applied to indicate the return path for other use cases as well,
200   which are out-of-scope for this document and therefore not further
201   described in this document.  SRv6 data plane is not in the scope of
202   this document.

[minor]
Why is the text seems complicated constructed. What about the following:

"This document focuses on the inter-domain use case. The protocol extensions described may also indicate the return path for other use cases, which are outside the scope of this document and are not further detailed here. The SRv6 data plane is also not covered in this document."

204 1.1.  Definition of Domain

206   The term domain used in this document implies an IGP domain where
207   every node is visible to every other node for shortest path
208   computation.  The domain implies an IGP area or level.  An AS
209   consists of one or more IGP domains.  The procedures described in
210   this document apply to paths built across multiple domains which
211   include inter-area as well as inter-AS paths.  The procedures and
212   deployment scenarios described in this document apply to inter-AS
213   paths where the participating ASes belong to closely coordinating
214   administrations or to single ownership.  This document applies to SR-
215   MPLS networks where all nodes in each of the domains are SR capable.
216   It also applies to SR-MPLS networks where SR acts as an overlay
217   having SR-incapable underlay nodes.  In such networks, the traceroute
218   procedure is executed only on the overlay SR nodes.

[minor]
I found this section hard to parse. The following text proposal processes slightly better:

"In this document, the term "domain" refers to an IGP domain where every node is visible to every other node for the purpose of shortest path computation, implying an IGP area or level. An Autonomous System (AS) comprises one or more IGP domains. The procedures described herein are applicable to paths constructed across multiple domains, including both inter-area and inter-AS paths. These procedures and deployment scenarios are relevant for inter-AS paths where the participating ASes are under closely coordinating administrations or single ownership. This document pertains to SR-MPLS networks where all nodes within each domain are SR-capable. It also applies to SR-MPLS networks where SR functions as an overlay with SR-incapable underlay nodes. In such networks, the traceroute procedure is executed only on the overlay SR nodes.
"

253   Reply Path (RP) TLV is defined in [RFC7110].  SR networks statically
254   assign the labels to nodes and a PMS/head-end may know the entire
255   database.  The reverse path can be built from the PMS/head-end by

[major]
What for database? The LSDB? a database with the all the nodes and assigned SIDs? something else?

265   The type of segment that the head-end chooses to send in the Reply
266   Path TLV is governed by local policy.  Implementations MAY provide
267   Command Line Interface (CLI) input parameters in the form of Labels/
268   IPv4 addresses/IPv6 addresses or a combination of these which get
269   encoded in the Reply Path TLV.  Implementations MAY also provide
270   mechanisms to acquire the database of remote domains and compute the
271   return path based on the acquired database.  For traceroute purposes,
272   the return path will have to consider the reply being sent from every
273   node along the path.  The return path changes when the traceroute

[major]
I do not understand why these are uppercase MAY? no formal protocol procedures are provided in this section? consider lower case as it distracts from formal protocol procedures

[major]
The term 'database' is unclear. What for database is exactly intended? A node may have many databases

279   Some networks may consist of pure IPv4 domains and pure IPv6 domains.
280   Handling end-to-end MPLS OAM for such networks is out of the scope of
281   this document.  It is recommended to use dual-stack in such cases and
282   use end-to-end IPv6 addresses for MPLS ping and traceroute
283   procedures.

[minor]
Clarification: I suspect that it is intended to indicate that it is pure ipv4-only or ipv6-only networks?

295   The below types of Segment sub-TLVs apply to the Reply Path TLV.  The
296   code points for the sub-TLVs are taken from the IANA registry common
297   to TLVs 1, 16, and 21.  This document defines the Segment sub-TLVs
298   usage and processing when it appears in TLV 21.  If these sub-TLVs
299   appear in TLVs 1 or 16, appropriate error codes MUST be returned as
300   defined in [RFC8029].

[major]
While the text here is is not wrong, it is confusing type-A/C/D and then three code-point TLVs... The text should be more explit that code points punt towards:
1 Target FEC Stack
16 Reverse-path Target FEC Stack
21 Reply Path

and be more explicit that the new defined sub-TLVs are only to be used with TLV21 (Reply Path TLV).

327   Type: TBD1(to be assigned by IANA from the registry "Sub-TLVs for TLV
328   Types 1, 16, and 21").

[minor]
Should it not specify a field length of 2 octets?

330   Length: 2 octets.  Carries value 8.  The length excludes the length
331   of the Type and Length Fields.

[minor]
The length "value" exclude....

335   RESERVED: 3 octets of reserved bits.  MUST be set to zero when
336   sending; MUST be ignored on receipt.

[minor]
I believe that the declaration for reserved is the correct one, but want to double check. If there is any potential that in future these bits may be used, then instead Future Use may be better choice.

342   S: 1 bit Reserved.

[minor]
few lines above the RESERVED 3 octets were described directly, however the formal procedure for handling S bit is explained later in the text, which is inconsistent

390   Length: 2 octets.  Carries value 8 without SID included or 12 with
391   SID included.

[minor]
The text should be more prescriptive.
"Caries value 8 when no optional SID is included or value 12 when optional SID is included."

395   SR Algorithm: 1 octet specifying SR Algorithm as described in section
396   3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present.
397   SR Algorithm is used by the receiver to derive the Label.  When
398   A-flag is unset, this field has no meaning and thus MUST be set to
399   zero on transmission and ignored on receipt.

[major]
Is the algorithm not always used by the received to derive the used label?
the algorithm is either 0 (or 1) or one of the flex-algorithms.
Iam not sure why there is an A-flag? could the setting of AR Algorithm not implicit assume that there is an SR Algorithm? why a specific A-fleg?

404   IPv4 Node Address: 4-octet IPv4 address representing a node.

[minor]
Should it be mentioned that this should be best a stable address (e.g a loopback address?)

406   SID: optional: 4-octet field containing label, TC, S and TTL as
407   defined in Section 4.1.  When the SID field is present, it MUST be
408   used for constructing the Reply Path.

[major]
A SID can be a label or an index. Is there a reason to exclude the index type of SID? (see: https://datatracker.ietf.org/doc/html/rfc8402#section-3.1.2 )

414   The SID is optional and specifies a 4-octet MPLS SID containing
415   label, TC, S and TTL as defined in Section 4.1.

[minor]
Seems duplicate text meanings already documented in line406-408

417   If the length is 8, then only the IPv4 Node Address is present.
419   If the length is 12, then the IPv4 Node Address and the MPLS SID are
420   present.

[minor]
Is this not already documented earlier when the Length field is described?

422 4.3.  Type D: IPv6 Node Address with Optional SID for SR MPLS

[minor]
This section has similar editorial issues as section 4.2 where some fields are explained twice. Maybe optimise the formal text

494   A-Flag: This flag indicates the presence of SR Algorithm ID in the
495   "SR-Algorithm" field applicable to various segment Types.

[major]
Why not use the existence of the SR Algorithm field instead of a A-flag?

507   This section uses the term "initiator" for the node that initiates
508   the MPLS ping or MPLS traceroute procedure.  The term "responder" is
509   used for the node that receives the echo request and sends the echo
510   reply.  The term egress node is used to identify the last node where
511   the MPLS ping or traceroute is destined to.  In an MPLS network any
512   node can be initiator or responder or egress.

[minor]
What is the difference between 'responder and the 'egress node'? should they be the same node?

516   In the inter-AS scenario, the procedures described in this document
517   are used to specify the return path, if IP connectivity to the
518   initiator is not available, and may be used in any case.  The LSP

[minor]
Readability rewrite:
"In the inter-AS scenario, the procedures outlined in this document are employed to specify the return path when IP connectivity to the initiator is unavailable. These procedures may also be utilized regardless of the availability of IP connectivity.
"

529   As described in [RFC7110], when Reply mode is set to 5 (Reply via
530   Specified Path), the echo request must contain the Reply path TLV.
531   Absence of Reply Path TLV is treated as a malformed echo request.

[minor]
In previous section uppercase RFC2119 language is used. Would using MUST here not be justified?

532   When an echo request is received, if the responder does not know the
533   Reply Mode 5 defined in [RFC7110], an echo reply with the return code
534   set to "Malformed echo request received" and the Subcode set to zero
535   must be sent back to the initiator according to the rules of
536   [RFC8029].  If the echo request message contains a malformed Segment

[minor]
instead of 'does not know' i suspect what is meant is 'does not support'?

541   When a Reply Path TLV is received, the responder that supports
542   processing it, MUST use the segments in Reply Path TLV to build the
543   echo reply.  The responder MUST follow the normal FEC validation
544   procedures as described in [RFC8029] and [RFC8287] and this document
545   does not suggest any change to those procedures.  When the echo reply

[major]
If validation fails (e.g. sid does not exist or is not reachable for example) would this cause a echo reply to be returned with some error subcode?

545   does not suggest any change to those procedures.  When the echo reply
546   has to be sent out the Reply Path TLV MUST be used to construct the
547   MPLS packet to send out.

[major]
Must the MPLS label stack created by the node be an exact copy of the sid stack encoded in the Reply Path TLV? can there be MPLS labels added (for redirecting purposes or special services)?

555   segment from the Reply Path TLV.  The remaining labels MUST follow
556   the order from the Reply Path TLV.  The responder MAY check the

[major]
What if te order of labels is kept, but some other labels are inserted for steering or other purposes?

566   if such information is available from the controller or via operator
567   input.  In such cases, the node sending the echo reply MUST derive
568   the MPLS labels based on Node-SIDs associated with the IPv4/IPv6
569   addresses or from the optional MPLS SIDs in the Type-C/Type-D
570   segments and encode the echo reply with MPLS labels.

[major]
What if the Type-C/D encoded IP address does not correspond with that nodes SID? What would happen? for example IP address 1.1.1.1 has SID 111 but in the subTLV the address 1.1.1.1 is encoded with ID222. Would that give an error or is there some validation?

636   it is RECOMMENDED to add a Type-C or a Type-D segment, but
637   implementations MAY safely use other approaches if they see benefits
638   in doing so.  If the existing segment in the Reply Path TLV is a

[minor]
I am confused by the wording of other approaches? If Type-C or D is not used, only Type-A remains. Is that 'the other' approaches? If yes, then why not just say to insert Type-A?

646   When an ASBR receives an echo request from another AS, and the ASBR
647   is configured to build the return path dynamically, the ASBR should
648   build a Reply Path TLV and include it in the echo reply.  The Reply

[major]
This is most likely a clarification item. Would this result into potentially multiple Replay Path TLVs to be appended? or to have additional subTLVs (i.e. Type-A) to be inserted into the Type 21 TLV? i believe that later in the paragraph it is indicated that subTLVs are added

674   An ASBR that receives the echo request from a neighbor belonging to
675   the same AS, MUST look at the Reply Path TLV received in the echo
676   request.  If the Reply Path TLV consists of a Type-C/Type-D segment,

[minor]
IS 'receiving' correct? it is receiving and if the local SID is the top sid of the received packet then the processing takes place. Otherwise the packet is presumably MPLS switched onwards without any processing by the local node.

701 6.  Detailed Example

[major]
This is an example of the formal procedures outlined in this document.
Examples are not formal procedures and are better placed into the Appendix.

950   IANA should assign three new sub-TLVs from the "sub-TLVs for TLV
951   Types 1, 16, and 21" sub-registry of the "Multiprotocol Label
952   Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
953   registry.

[major]
These subTLVs can only be in the TLV21. Should that be mentioned on the IANA page in the registry notes?

978   New entries are assigned by Standards Action.  Initial entries in the
979   registry are as follows:

[minor]
Using standards action would not allow the allocation of flags for experimental purpose.
Maybe more appropriate is to allocate using 'IETF Review' (also known as IETF Consensus)?
2024-06-06
17 Gunter Van de Velde [Ballot Position Update] New position, Discuss, has been recorded for Gunter Van de Velde
2024-06-05
17 Qin Wu Assignment of request for Telechat review by OPSDIR to Qin Wu was rejected
2024-06-04
17 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2024-06-03
17 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2024-05-31
17 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-17.txt
2024-05-31
17 (System) New version approved
2024-05-31
17 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-05-31
17 Shraddha Hegde Uploaded new revision
2024-05-30
16 Carlos Pignataro Request for Telechat review by OPSDIR is assigned to Qin Wu
2024-05-27
16 Peter Yee
Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier …
Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.
2024-05-27
16 Peter Yee Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee.
2024-05-24
16 Jim Guichard Placed on agenda for telechat - 2024-06-13
2024-05-24
16 Jim Guichard Ballot has been issued
2024-05-24
16 Jim Guichard [Ballot Position Update] New position, Yes, has been recorded for Jim Guichard
2024-05-24
16 Jim Guichard Created "Approve" ballot
2024-05-24
16 Jim Guichard IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-05-24
16 Jim Guichard Ballot writeup was changed
2024-05-22
16 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-16.txt
2024-05-22
16 (System) New version approved
2024-05-22
16 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde , mpls-chairs@ietf.org
2024-05-22
16 Shraddha Hegde Uploaded new revision
2024-05-22
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-05-22
15 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-15.txt
2024-05-22
15 (System) New version approved
2024-05-18
14 Michael Tüxen Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Michael Tüxen. Sent review to list.
2024-05-17
14 Qin Wu Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Qin Wu. Sent review to list.
2024-05-17
14 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-05-16
14 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2024-05-16
14 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-spring-inter-domain-oam-14. If any part of this review is inaccurate, please let us know.

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

IANA has completed its review of draft-ietf-mpls-spring-inter-domain-oam-14. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Sub-TLVs for TLV Types 1, 16, and 21 sub-registry of the TLVs registry on 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 new registrations are to be made from the Standards Action range (0-16383) as follows:

Sub-type:[ TBD-at-Registration ]
Sub-TLV Name: SID only in the form of MPLS label
Reference: [ RFC-to-be; Section 4.1 ]
Comment:

Sub-type: [ TBD-at-Registration ]
Sub-TLV Name: IPv4 Node Address with optional SID for SR-MPLS
Reference: [ RFC-to-be; Section 4.2 ]
Comment:

Sub-type: [ TBD-at-Registration ]
Sub-TLV Name: IPv6 Node Address with optional SID for SR-MPLS
Reference: [ RFC-to-be; Section 4.3 ]
Comment:

Second, a new registry is to be created called the Segment ID sub-TLV flags registry. The new registry will be located 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/

The new registry will be maintained via Standards Action as defined by RFC 8126. There is a single, initial registration in the new registry as follows:

Bit number: 1
Name: A Flag
Reference: [ RFC-to-be; Section 4.4 ]

We understand that these are the only actions 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
2024-05-15
15 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-05-15
15 Shraddha Hegde Uploaded new revision
2024-05-15
14 Chris Lonvick Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. Sent review to list.
2024-05-15
14 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-14.txt
2024-05-15
14 (System) New version approved
2024-05-15
14 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-05-15
14 Shraddha Hegde Uploaded new revision
2024-05-13
13 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Qin Wu
2024-05-10
13 Stig Venaas Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Stig Venaas. Sent review to list.
2024-05-09
13 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2024-05-06
13 Daniam Henriques Request for Last Call review by RTGDIR is assigned to Stig Venaas
2024-05-06
13 Magnus Westerlund Request for Last Call review by TSVART is assigned to Michael Tüxen
2024-05-03
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2024-05-03
13 Jenny Bui IANA Review state changed to IANA - Review Needed
2024-05-03
13 Jenny Bui
The following Last Call announcement was sent out (ends 2024-05-17):

From: The IESG
To: IETF-Announce
CC: adrian@olddog.co.uk, draft-ietf-mpls-spring-inter-domain-oam@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org …
The following Last Call announcement was sent out (ends 2024-05-17):

From: The IESG
To: IETF-Announce
CC: adrian@olddog.co.uk, draft-ietf-mpls-spring-inter-domain-oam@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Path Monitoring System/Head-end
based MPLS Ping and Traceroute in
  Inter-domain Segment Routing Networks'
  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


  The Segment Routing (SR) architecture leverages source routing and
  can be directly applied to the use of a MPLS data plane.  An SR-MPLS
  network may consist of multiple IGP domains or multiple Autonomous
  Systems(ASes) under the control of the same organization.  It is
  useful to have the Label Switched Path (LSP) ping and traceroute
  procedures when an SR end-to-end path traverses multiple ASes or
  domains.  This document describes mechanisms to facilitate LSP ping
  and traceroute in inter-AS and inter-domain SR-MPLS networks in an
  efficient manner with a simple Operations, Administration and
  Maintenance (OAM) protocol extension which uses data plane forwarding
  alone for forwarding echo replies on transit nodes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-inter-domain-oam/


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

  https://datatracker.ietf.org/ipr/3937/
  https://datatracker.ietf.org/ipr/5234/





2024-05-03
13 Jenny Bui IESG state changed to In Last Call from Last Call Requested
2024-05-03
13 Jenny Bui Last call announcement was generated
2024-05-03
13 Jim Guichard Requested Last Call review by RTGDIR
2024-05-03
13 Jim Guichard Requested Last Call review by OPSDIR
2024-05-03
13 Jim Guichard Requested Last Call review by SECDIR
2024-05-03
13 Jim Guichard Last call was requested
2024-05-03
13 Jim Guichard Last call announcement was generated
2024-05-03
13 Jim Guichard Ballot approval text was generated
2024-05-03
13 Jim Guichard Ballot writeup was generated
2024-05-03
13 Jim Guichard IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-05-03
13 (System) Changed action holders to Jim Guichard (IESG state changed)
2024-05-03
13 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-05-03
13 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-13.txt
2024-05-03
13 (System) New version approved
2024-05-03
13 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-05-03
13 Shraddha Hegde Uploaded new revision
2024-04-22
12 Jim Guichard Initial AD review completed === https://mailarchive.ietf.org/arch/msg/mpls/c94Uo5NsKo1whCD-ESmcjNxpq78/ ===
2024-04-22
12 (System) Changed action holders to Jim Guichard, Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Nagendra Nainar (IESG state changed)
2024-04-22
12 Jim Guichard IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2024-04-01
12 Jim Guichard Changed action holders to Jim Guichard (New AD responsible for the document)
2024-03-20
12 Cindy Morgan Shepherding AD changed to Jim Guichard
2024-02-20
12 Adrian Farrel
Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused by the description of a …
Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused by the description of a "domain" (or "SR domain") in RFC 8402.
This document is not referring to that type of domain. It refers to IGP-domains
(OSPF areas or IS-IS levels) and Autonomous Systems. We have worked to make
that clear in the text, but be careful what baggage you bring to your review!

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

There was no dissent, however, it proved hard to get supporting comments from
the working group. The initial 3 week last call ran over Christmas, and was
extended for another 2 weeks because of the low response. Eventually, several
key contributors to the working group performed reviews and made supportive
comments. These led to discussions with the authors and a couple of rounds of
updates.

Thus, "strong concurrence of a few individuals, with others being silent"

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

No controversy.

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

No appeals, no discontent.

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)?

There is an RFC 7942 Implementation Status section as Section 12 of this
document. It describes a single vendor's prototype implementation.

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

This work is very much related to the work of the SPRING working group. The
working group last call was shared on the SPRING list and resulted in supportive
comments from one participant. There was no objection raised.

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.

No formal expert reviews required.
A Routing Directorate review was performed in preparation for working group last
call (https://datatracker.ietf.org/doc/review-ietf-mpls-spring-inter-domain-oam-05-rtgdir-early-richardson-2023-06-28/)
This found a lot of small issues that were fixed prior to last call.

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]?

No YANG.

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.

No formal language

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

My review of -10 led to a fair number of minor comments and nits. The authors
resolved most of these with -11. A further round of discussions led to -12 and
closure of all open comments.

I now consider the document to be clear enough and complete.

The need for the document is something of a stretch in today's immediate
deployments since multi-IGP-domain, or multi-AS SR-MPLS is likely dependent on
wider experience with single-domain. But, unlike MPLS-TE which saw very limited
multi-domain deployment, it is possible that the future holds more hope for
multi-domain SR-MPLS.

The design is acceptable (not necessarily how I would have done it, but that is
not important as there is agreement on the approach the authors have documented)

The document is ready for consideration by the 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?

Careful reviewing against the RTG Dir "common issues" by the RTG Dir reviewer
and the Shepherd. Should all be good.

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?

Proposed Standard correctly noted.
The document describes new protocol elements.

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.

All five authors and the two contributors made IPR declarations at the time of working group last call

Shraddha Hegde https://mailarchive.ietf.org/arch/msg/mpls/uQ40wG5xjMdqTBZwPjeQynz3F_I/
Kapil Arora https://mailarchive.ietf.org/arch/msg/mpls/oHG3cHeWRA7So8dd1MS6-W1lNCY/
Mukul Srivastava https://mailarchive.ietf.org/arch/msg/mpls/hNfxPtkXkTUGaevMMYQVBzt1IuE/
Samson Ninan https://mailarchive.ietf.org/arch/msg/mpls/hYFrH1xPJXk602XYUTo9SnYv7_E/
Nagendra Kumar Nainar https://mailarchive.ietf.org/arch/msg/mpls/JQk5eMrFJe7x3kJcsU3X7cdZnlw/
Carlos Pignataro https://mailarchive.ietf.org/arch/msg/mpls/IEW9yOlOWUu2HsF29yCGyYQwxxU/
Zafar Ali https://mailarchive.ietf.org/arch/msg/mpls/kGZgGI-QN2eC1tQskO_6cb4A07Y/

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.

By responding to the IPR poll (see #12) all authors and contributors were made aware
of their association with the document. None objected.

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

idnits is clean on -12 except for warnings about things that look like references
but aren't.

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

I'm OK with the split (but see #17).

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

Nope. All are IETF output.

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.

There is a normative downref to Informational RFC 9087.
It is not listed in the downref registry.
I would prefer this to remain a Normative reference, but it could be made
Informative without significant harm.

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?

Nope, everything is an RFC.

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.

No changes suggested or needed.

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]).

I took over this document as shepherd late in the cycle. Thus, my review of -10
came after all updates after WGLC.

My review uncovered a fair number of minor comments and nits, but nothing of
significant substance. It also pointed to idnits that needed to be fixed.

The authors posted -11 and -12 resolving my issues to my satisfaction.

The IANA section is clear and identifies the registries correctly. The new
registry that is requested has all the necessary information.

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.

The new registry uses "Standards Action"
2024-02-20
12 Adrian Farrel IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-02-20
12 Adrian Farrel IESG state changed to Publication Requested from I-D Exists
2024-02-20
12 (System) Changed action holders to Andrew Alston (IESG state changed)
2024-02-20
12 Adrian Farrel Responsible AD changed to Andrew Alston
2024-02-20
12 Adrian Farrel Document is now in IESG state Publication Requested
2024-02-20
12 Adrian Farrel Tag Doc Shepherd Follow-up Underway cleared.
2024-02-20
12 Adrian Farrel
Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused by the description of a …
Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused by the description of a "domain" (or "SR domain") in RFC 8402.
This document is not referring to that type of domain. It refers to IGP-domains
(OSPF areas or IS-IS levels) and Autonomous Systems. We have worked to make
that clear in the text, but be careful what baggage you bring to your review!

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

There was no dissent, however, it proved hard to get supporting comments from
the working group. The initial 3 week last call ran over Christmas, and was
extended for another 2 weeks because of the low response. Eventually, several
key contributors to the working group performed reviews and made supportive
comments. These led to discussions with the authors and a couple of rounds of
updates.

Thus, "strong concurrence of a few individuals, with others being silent"

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

No controversy.

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

No appeals, no discontent.

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)?

There is an RFC 7942 Implementation Status section as Section 12 of this
document. It describes a single vendor's prototype implementation.

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

This work is very much related to the work of the SPRING working group. The
working group last call was shared on the SPRING list and resulted in supportive
comments from one participant. There was no objection raised.

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.

No formal expert reviews required.
A Routing Directorate review was performed in preparation for working group last
call (https://datatracker.ietf.org/doc/review-ietf-mpls-spring-inter-domain-oam-05-rtgdir-early-richardson-2023-06-28/)
This found a lot of small issues that were fixed prior to last call.

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]?

No YANG.

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.

No formal language

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

My review of -10 led to a fair number of minor comments and nits. The authors
resolved most of these with -11. A further round of discussions led to -12 and
closure of all open comments.

I now consider the document to be clear enough and complete.

The need for the document is something of a stretch in today's immediate
deployments since multi-IGP-domain, or multi-AS SR-MPLS is likely dependent on
wider experience with single-domain. But, unlike MPLS-TE which saw very limited
multi-domain deployment, it is possible that the future holds more hope for
multi-domain SR-MPLS.

The design is acceptable (not necessarily how I would have done it, but that is
not important as there is agreement on the approach the authors have documented)

The document is ready for consideration by the 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?

Careful reviewing against the RTG Dir "common issues" by the RTG Dir reviewer
and the Shepherd. Should all be good.

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?

Proposed Standard correctly noted.
The document describes new protocol elements.

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.

All five authors and the two contributors made IPR declarations at the time of working group last call

Shraddha Hegde https://mailarchive.ietf.org/arch/msg/mpls/uQ40wG5xjMdqTBZwPjeQynz3F_I/
Kapil Arora https://mailarchive.ietf.org/arch/msg/mpls/oHG3cHeWRA7So8dd1MS6-W1lNCY/
Mukul Srivastava https://mailarchive.ietf.org/arch/msg/mpls/hNfxPtkXkTUGaevMMYQVBzt1IuE/
Samson Ninan https://mailarchive.ietf.org/arch/msg/mpls/hYFrH1xPJXk602XYUTo9SnYv7_E/
Nagendra Kumar Nainar https://mailarchive.ietf.org/arch/msg/mpls/JQk5eMrFJe7x3kJcsU3X7cdZnlw/
Carlos Pignataro https://mailarchive.ietf.org/arch/msg/mpls/IEW9yOlOWUu2HsF29yCGyYQwxxU/
Zafar Ali https://mailarchive.ietf.org/arch/msg/mpls/kGZgGI-QN2eC1tQskO_6cb4A07Y/

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.

By responding to the IPR poll (see #12) all authors and contributors were made aware
of their association with the document. None objected.

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

idnits is clean on -12 except for warnings about things that look like references
but aren't.

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

I'm OK with the split (but see #17).

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

Nope. All are IETF output.

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.

There is a normative downref to Informational RFC 9087.
It is not listed in the downref registry.
I would prefer this to remain a Normative reference, but it could be made
Informative without significant harm.

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?

Nope, everything is an RFC.

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.

No changes suggested or needed.

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]).

I took over this document as shepherd late in the cycle. Thus, my review of -10
came after all updates after WGLC.

My review uncovered a fair number of minor comments and nits, but nothing of
significant substance. It also pointed to idnits that needed to be fixed.

The authors posted -11 and -12 resolving my issues to my satisfaction.

The IANA section is clear and identifies the registries correctly. The new
registry that is requested has all the necessary information.

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.

The new registry uses "Standards Action"
2024-02-19
12 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-12.txt
2024-02-19
12 (System) New version approved
2024-02-19
12 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-02-19
12 Shraddha Hegde Uploaded new revision
2024-02-14
11 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-11.txt
2024-02-14
11 (System) New version approved
2024-02-14
11 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-02-14
11 Shraddha Hegde Uploaded new revision
2024-02-13
11 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-02-13
11 Shraddha Hegde Uploaded new revision
2024-02-07
10 Adrian Farrel
DRAFT  DRAFT  DRAFT  DRAFT  DRAFT


Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused …
DRAFT  DRAFT  DRAFT  DRAFT  DRAFT


Document Shepherd: Adrian Farrel (adrian@olddog.co.uk)

NOTE WELL: This document refers to "multi-domain SR-MPLS". There may be
confusion caused by the description of a "domain" (or "SR domain") in RFC 8402.
This document is not referring to that type of domain. It refers to IGP-domains
(OSPF areas or IS-IS levels) and Autonomous Systems. We have worked to make
that clear in the text, but be careful what baggage you bring to your review!

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

There was no dissent, however, it proved hard to get supporting comments from
the working group. The initial 3 week last call ran over Christmas, and was
extended for another 2 weeks because of the low response. Eventually, several
key contributors to the working group performed reviews and made supportive
comments. These led to discussions with the authors and a couple of rounds of
updates.

Thus, "strong concurrence of a few individuals, with others being silent"

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

No controversy.

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

No appeals, no discontent.

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)?

There is an RFC 7942 Implementation Status section as Section 12 of this
document. It describes a single vendor's prototype implementation.

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

This work is very much related to the work of the SPRING working group. The
working group last call was shared on the SPRING list and resulted in supportive
comments from one participant. There was no objection raised.

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.

No formal expert reviews required.
A Routing Directorate review was performed in preparation for working group last
call (https://datatracker.ietf.org/doc/review-ietf-mpls-spring-inter-domain-oam-05-rtgdir-early-richardson-2023-06-28/)
This found a lot of small issues that were fixed prior to last call.

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]?

No YANG.

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.

No formal language

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

My review of -10 led to a fair number of minor comments and nits. The authors
resolved these with -11.

I now consider the document to be clear enough and complete.

The need for the document is something of a stretch in today's immediate
deployments since multi-IGP-domain, or multi-AS SR-MPLS is likely dependent on
wider experience with single-domain. But, unlike MPLS-TE which saw very limited
multi-domain deployment, it is possible that the future holds more hope for
multi-domain SR-MPLS.

The design is acceptable (not necessarily how I would have done it, but that is
not important as their is agreement on the approach the authors have documented)

The document is ready for consideration by the 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?

Careful reviewing against the RTG Dir "common issues" by the RTG Dir reviewer
and the Shepherd. Should all be good.

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?

Proposed Standard correctly noted.
The document describes new protocol elements.

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.

All five authors and the two contributors made IPR declarations at the time of working group last call

Shraddha Hegde https://mailarchive.ietf.org/arch/msg/mpls/uQ40wG5xjMdqTBZwPjeQynz3F_I/
Kapil Arora https://mailarchive.ietf.org/arch/msg/mpls/oHG3cHeWRA7So8dd1MS6-W1lNCY/
Mukul Srivastava https://mailarchive.ietf.org/arch/msg/mpls/hNfxPtkXkTUGaevMMYQVBzt1IuE/
Samson Ninan https://mailarchive.ietf.org/arch/msg/mpls/hYFrH1xPJXk602XYUTo9SnYv7_E/
Nagendra Kumar Nainar https://mailarchive.ietf.org/arch/msg/mpls/JQk5eMrFJe7x3kJcsU3X7cdZnlw/
Carlos Pignataro https://mailarchive.ietf.org/arch/msg/mpls/IEW9yOlOWUu2HsF29yCGyYQwxxU/
Zafar Ali https://mailarchive.ietf.org/arch/msg/mpls/kGZgGI-QN2eC1tQskO_6cb4A07Y/

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.

By responding to the IPR poll (see #12) all authors and contributors were made aware
of their association with the document. None objected.

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

idnits is clean on -11 except for warnings about things that look like references
but aren't.

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

I'm OK with the split (but see #17).

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

Nope. All are IETF output.

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.

There is a normative downref to Informational RFC 9087.
It is not listed in the downref registry.
I would prefer this to remain a Normative reference, but it could be made
Informative without harm.

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?

Nope, everything is an RFC.

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.

No changes suggested or needed.

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]).

I took over this document as shepherd late in the cycle. Thus, my review of -10
came after all updates after WGLC.

My review uncovered a fair number of minor comments and nits, but nothing of
significant substance. It also pointed to idnits that needed to be fixed.

The authors posted -11 resolving my issues to my satisfaction.

The IANA section is clear and identifies the registries correctly. The new
registry that is requested has all the necessary information.

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.

The new registry uses "Standards Action"
2024-02-05
10 Adrian Farrel Changed consensus to Yes from Unknown
2024-02-05
10 Adrian Farrel Intended Status changed to Proposed Standard from None
2024-02-05
10 Adrian Farrel Notification list changed to adrian@olddog.co.uk from mach.chen@huawei.com, adrian@olddog.co.uk
2024-02-05
10 Adrian Farrel Tag Doc Shepherd Follow-up Underway set.
2024-02-05
10 Adrian Farrel IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2024-02-05
10 Adrian Farrel Notification list changed to mach.chen@huawei.com, adrian@olddog.co.uk from mach.chen@huawei.com because the document shepherd was set
2024-02-05
10 Adrian Farrel Document shepherd changed to Adrian Farrel
2024-01-29
10 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-10.txt
2024-01-29
10 (System) New version approved
2024-01-29
10 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-01-29
10 Shraddha Hegde Uploaded new revision
2024-01-28
09 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-09.txt
2024-01-28
09 (System) New version approved
2024-01-28
09 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-01-28
09 Shraddha Hegde Uploaded new revision
2024-01-25
08 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-08.txt
2024-01-25
08 (System) New version approved
2024-01-25
08 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2024-01-25
08 Shraddha Hegde Uploaded new revision
2024-01-16
07 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-07.txt
2024-01-16
07 (System) New version approved
2024-01-16
07 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde , mpls-chairs@ietf.org
2024-01-16
07 Shraddha Hegde Uploaded new revision
2024-01-08
06 (System) Document has expired
2023-12-18
06 Adrian Farrel WGLC ends 9th January 2024 at 9am GMT
2023-12-18
06 Adrian Farrel IETF WG state changed to In WG Last Call from WG Document
2023-10-30
06 Adrian Farrel Notification list changed to mach.chen@huawei.com from loa@pi.nu, mach.chen@huawei.com
2023-07-07
06 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-06.txt
2023-07-07
06 (System) New version approved
2023-07-07
06 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2023-07-07
06 Shraddha Hegde Uploaded new revision
2023-06-28
05 Michael Richardson Request for Early review by RTGDIR Completed: Ready. Reviewer: Michael Richardson. Sent review to list.
2023-06-25
05 Haomian Zheng Request for Early review by RTGDIR is assigned to Michael Richardson
2023-06-21
05 Loa Andersson Notification list changed to loa@pi.nu, mach.chen@huawei.com from loa@pi.nu because the document shepherd was set
2023-06-21
05 Loa Andersson Document shepherd changed to Mach Chen
2023-06-18
05 Loa Andersson Requested Early review by RTGDIR
2023-06-18
05 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-05.txt
2023-06-18
05 (System) New version approved
2023-06-18
05 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2023-06-18
05 Shraddha Hegde Uploaded new revision
2023-06-17
04 (System) Document has expired
2022-12-14
04 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-04.txt
2022-12-14
04 Shraddha Hegde New version accepted (logged-in submitter: Shraddha Hegde)
2022-12-14
04 Shraddha Hegde Uploaded new revision
2022-06-13
03 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-03.txt
2022-06-13
03 (System) New version approved
2022-06-13
03 (System) Request for posting confirmation emailed to previous authors: Kapil Arora , Mukul Srivastava , Nagendra Nainar , Samson Ninan , Shraddha Hegde
2022-06-13
03 Shraddha Hegde Uploaded new revision
2022-01-02
02 Loa Andersson Notification list changed to loa@pi.nu because the document shepherd was set
2022-01-02
02 Loa Andersson Document shepherd changed to Loa Andersson
2022-01-02
02 Loa Andersson This document now replaces draft-ninan-mpls-spring-inter-domain-oam instead of None
2021-12-13
02 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-02.txt
2021-12-13
02 (System) New version accepted (logged-in submitter: Shraddha Hegde)
2021-12-13
02 Shraddha Hegde Uploaded new revision
2021-12-12
01 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-01.txt
2021-12-12
01 (System) New version accepted (logged-in submitter: Shraddha Hegde)
2021-12-12
01 Shraddha Hegde Uploaded new revision
2021-12-10
00 Shraddha Hegde New version available: draft-ietf-mpls-spring-inter-domain-oam-00.txt
2021-12-10
00 (System) WG -00 approved
2021-12-09
00 Shraddha Hegde Set submitter to "Shraddha Hegde ", replaces to (none) and sent approval email to group chairs: mpls-chairs@ietf.org
2021-12-09
00 Shraddha Hegde Uploaded new revision