Skip to main content

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

Yes


No Objection

(Alissa Cooper)
(Mirja Kühlewind)

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

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

(Deborah Brungard; former steering group member) Yes

Yes (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)

(Adam Roach; former steering group member) (was Discuss) No Objection

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

(Alissa Cooper; former steering group member) No Objection

No Objection (for -11)

                            

(Ben Campbell; former steering group member) No Objection

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

(Eric Rescorla; former steering group member) No Objection

No Objection (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?

(Kathleen Moriarty; former steering group member) No Objection

No Objection (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:
https://mailarchive.ietf.org/arch/msg/secdir/HhRollkdh9Y581j7HlQys8kP4nE

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -11)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (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; former steering group member) No Objection

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