Last Call Review of draft-ietf-spring-oam-usecase-06
review-ietf-spring-oam-usecase-06-rtgdir-lc-halpern-2017-06-22-00

Request Review of draft-ietf-spring-oam-usecase
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-06-30
Requested 2017-06-16
Requested by Alvaro Retana
Other Reviews Opsdir Last Call review of -06 by Joel Jaeggli (diff)
Genart Last Call review of -06 by Pete Resnick (diff)
Secdir Last Call review of -06 by Takeshi Takahashi (diff)
Secdir Telechat review of -09 by Takeshi Takahashi (diff)
Review State Completed
Reviewer Joel Halpern
Review review-ietf-spring-oam-usecase-06-rtgdir-lc-halpern-2017-06-22
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/XI6TFsjJHxpTiINOSq6lmR-yr8A
Reviewed rev. 06 (document currently at 10)
Review result Has Nits
Draft last updated 2017-06-22
Review completed: 2017-06-22

Review
review-ietf-spring-oam-usecase-06-rtgdir-lc-halpern-2017-06-22

This is a rtg-dir requested review.

Summary: Ready for publication as an Informational RFC with some minor items that should be considered.

Major: N/A

Minor:
    The introduction treats having a single centralized monitoring system as an unalloyed positive.  To set context properly, it would seem more appropriate to note that many operators find such central systems useful, and the approach described here enables that when desired.

    The reference in the introduction to IGP topology discovery is very confusing. "Adding MPLS topology awareness to an IGP speaking device hence enables a simple and scalable data plane based monitoring mechanism."  As noted later in the document, link-state IGPs provide topology awareness.  So what is this part of the introduction trying to say?  (Side-note, not all IGPs are link state, although the applicability of Babel or RIP to MPLS Segment Routing is clearly outside the scope of this document.)

    In section 5.1 in discussing path trace the reference is to RFC 4379 which is a clear source for path trace.  However, the text refers to "tree trace".  While that may have become a common phrase for the usage, it is not used in RFC 4379.  The term should either be explain, include a suitable reference, or not be used.

   In section 5.3 on fault isolation, the text notes that the only difference between the test which succeeds and that which fails is the difference the the adjacency SID.  The text then goes on to say "Assuming the second probe has been routed correctly, the fault must have been occurring in R2 which didn't forward the packet to the interface identified by its Adjacency SID 663."  That does not follow.  If the link as failed in an undetected fashion (either in one direction or both), R2 would be functioning fine and the symptom would be the same.  Remotely detecting the difference between R2 failing to forward and the link not working seems a much harder task.

    The claim that the PMS can / should (intent is ambiguous) notify the router when it detects a path failure raises a number of issues.   It is not at all clear what the router would do with the notification.  (e.g. If it removed the link from service, then future monitoring would not be able to detect that the link was working.)  Either this needs to become a significantly larger section, or (more likely) the text needs to be removed.

Editorial:
    Chapter 7 is titled dealing with non-SR environments.  Which makes sense.  The text then switches to using "pre-SR" instead of "non-SR".  I would recommend that all uses of "pre-SR" be changed to "non-SR".