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

Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.

Adam Roach Discuss

Discuss (2017-10-11 for -11)
Section 5.3 indicates that "Advertising Node Identifier" and "Receiving Node Identifier" are "4 or 6 octets." There are two issues that arise with the way this is currently specified, both of which can lead to a lack of interoperability:

1. While implementors might infer that "Protocol=1" results in a 4-byte value, and that "Protocol=2" results in a 6-byte value, it's a bit unclear what length is to be used here for "Protocol=0."

2. The descriptions for both of these fields include: "When Protocol is set to 1, then the 32 rightmost bits represent OSPF Router ID."  This implies that the field is *wider* than 32 bits when Protocol=1, which leaves deep ambiguity about the circumstances under which the field is allowed to be 4 octets.

I would strongly recommend that this section add clear language that unambiguously spells out how implementations are expected to select the field width for the four variable-width fields in this Sub-TLV (the two I cite above as well as the interface ID fields).
Comment (2017-10-11 for -11)
Sections 5.1, 5.2, and 5.3 define "Reserved" fields without indication of how these fields should be treated. Recommend each of these be defined to "MUST be set to 0 on send, MUST be ignored on receipt" -- this is the scheme that maximizes the ability to use them in the future.

Section 5.3 sefines three values for "Adj Type": 0, 4, and 6. Please either state that all other values are and will always be an error, or create an IANA registry for this field.

Section 5.3 sefines three values for "Protocol": 0, 1, and 2. Please either state that all other values are and will always be an error, or create an IANA registry for this field.

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

Alia Atlas No Record

Benoit Claise No Record

Warren Kumari No Record

Terry Manderson No Record

Alexey Melnikov No Record