ietf
[Top] [All Lists]

Rtgdir last call review of draft-ietf-spring-oam-usecase-06

2017-06-22 08:29:50
Reviewer: Joel Halpern
Review result: Has Nits

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

<Prev in Thread] Current Thread [Next in Thread>