Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes
draft-ietf-mpls-spring-lsp-ping-13

Thank you for addressing my discuss and comments.

(1) I’m surprised that there’s not even a passing reference to draft-ietf-spring-oam-usecase, given that it points to this draft in several places, among other things as “adding functionality to the use cases described by this document”.  I'm not advocating for a web of references, just surprised.

(2) The definition of a field with the name “Protocol” in Section 5. (Segment ID sub-TLV) got me a little confused when I went looking for a registry and found the values corresponding to the Downstream Detailed Mapping TLV (Section 6).  The name is ok, but I was wondering:  Can you reuse the existing registry for the values used on the Segment ID sub-TLV?  If so, then the values for OSPF/ISIS would change.  If not, then please have IANA set one up.

(3) What happens if there’s any error (invalid length, unknown protocol, etc.) in the sub-TLVs defined in Section 5?  I’m assuming that the action is specific to the TLV that contains them, or that there is something already specified in rfc8029 — please include a pointer, or specifics if needed.  I see that Section 7.4. (Segment ID Check) says that other values (for Protocol) “MUST be treated as Protocol value of 0” — that’s ok for now, but when/if other values are used this document would have to be Updated.  It may be better to say “any other unassigned value” (or maybe unrecognized, or something along those lines).

(4) I would really like to see a registry definition for Adj. Type (in 5.3).

I share Kathleen's and Ekr's question about using this for reconnaissance.

I share Kathleen's concern. A related issue is the trust model: this allows one endpoint to potentially learn a lot about the MPLS topology. Is that an issue?

I don't see mention of the possibility of the new LSP Ping and traceroute being used for reconnaissance. Is there a reason that i snot applicable or should it be added as a consideration?  Thanks.

Thanks for addressing the SecDir review:
https://mailarchive.ietf.org/arch/msg/secdir/HhRollkdh9Y581j7HlQys8kP4nE

I can't emphasize strongly enough that my understanding of segment routing is neophyte-level on a good day, but I do have a question about Section 8.

I'm understanding that on a network path where some network elements support segment routing while others do not, what you can measure is a ping or traceroute to the first network element that doesn't support segment routing (or is it to the last network element that does support segment routing?), but you don't have any visibility along the path beyond that - do I have that right?

Assuming so ... 

I didn't see anything about this topic before Section 8/page 16. Perhaps it's worth mentioning whether this works earlier in the document, perhaps in the Introduction?

My last point might not be in scope for this document, or even the SPRING working group, but if this is a limitation, any suggestions you could make to network operators with mixed networks (which I could imagine would be the rule, rather than the exception, as the technology is deployed) about what they can do to benefit most from this technology might be appreciated.

Agree with Adam's DISCUSS. I had the same concerns as well.