Re: [RTG-DIR] Rtgdir last call review of draft-ietf-spring-oam-usecase-06

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

Thank you, Joel, well spotted. Apologies we changed all instances except for two. This is now fixed in -08.

Thanks!

— Carlos.

On Jul 1, 2017, at 5:07 PM, Joel M. Halpern <[e-mail]<mailto:[e-mail]>> wrote:

Almost.
I believe the earlier email had agreed to replace pre-SR with non-SR. There are two uses of pre-SR stil in the document.

Otherwise, yes, these address my comments.

Yours,
Joel

On 7/1/17 4:52 PM, Carlos Pignataro (cpignata) wrote:
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]> <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]> <mailto:[e-mail]>
/“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."/

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

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