Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes

Note: This ballot was opened for revision 11 and is now closed.

Deborah Brungard Yes

Comment (2017-10-11 for -11)
Authors have identified corrections:
- 5.1 requires reference to ietf-spring-segment-routing for definition
- 5.2 requires reference to ietf-spring-segment-routing for definition
- 5.3 need to remove reference to section 3.5 and only reference ietf-spring-segment-routing
(as section in document is being renumbered, best not to reference)
- change ietf-spring-segment-routing from normative reference to informative reference
for consistency with RFC8029 and other MPLS Ping documents which do as informative reference
to definitions (will consult with SPRING AD (Alvaro) before making change)

Ben Campbell No Objection

Comment (2017-10-11 for -11)
I share Kathleen's and Ekr's question about using this for reconnaissance.

Alissa Cooper No Objection

Spencer Dawkins No Objection

Comment (2017-10-10 for -11)
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.

Suresh Krishnan No Objection

Comment (2017-10-11 for -11)
Agree with Adam's DISCUSS. I had the same concerns as well.

Mirja Kühlewind No Objection

(Kathleen Moriarty) No Objection

Comment (2017-10-10 for -11)
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:

Eric Rescorla No Objection

Comment (2017-10-10 for -11)
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?

Alvaro Retana No Objection

Comment (2017-10-11 for -11)
(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).

Adam Roach (was Discuss) No Objection

Comment (2017-10-19)
Thank you for addressing my discuss and comments.