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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Thanks for your review, Joel!

Revision -07, just submitted, should address all your concerns and suggestions. Please let us know otherwise.

Thanks,

— Carlos.

On Jun 22, 2017, at 9:29 AM, Joel Halpern <[e-mail]<mailto:[e-mail]>> wrote:

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


—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."