Hi Joel,
thanks for your review. The comments of the draft editors are marked [ED] inserted in your text below.
Regards,
Ruediger
######
Minor:
[JH]
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.
[ED] Is the following text of the bulleted list ok (if you have a better term then
"large", please let us know)?
"- The system described here allows to set up an SR domain wide centralised
connectivity validation, which is useful in large network operator domains."
#####
[JH]
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.)
[ED] Thanks for pointing out. We propose to change the text reference and limit scope to link state IGPs:
"Topology awareness is an important feature of link state IGPs deployed by operators of large networks. MPLS topology awareness combined with IGP topology awareness enables a simple and scalable data plane based monitoring mechanism."
#####
[JH]
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.
[ED] Will replace "tree trace" by path trace.
#####
[JH]
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.
[ED] Yes, link or router can be faulty. What about:
"...the fault is that for some (possibly unknown) reason SR packets to be forwarded from R2 via the interface identified by Adjacency SID 663 are lost."
#####
[JH]
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.
[ED] Your comment hits the point. Prior to removing it, I'd like to offer a change (but may word it not well and I unfortunately can't check text with my operational department for the coming weeks - vacation season has started).
[ED] Let's call the symptom "not working forwarding". We know, that it occurs. If there is one counter-measure which often works and has properties allowing automated execution (i.e. the situation can't deteriorate, if a solution is executed automatically), "automation" may also be proposed here (but no discussion of solution details, rather a limited number of general requirements). If the text below is useful, we should keep it, but I will not fight for it in the draft:
[ED]
"Path Trace and Failure Notification
Sometimes forwarding along a single path indeed doesn't work, while the control plane information is healthy. Such a situation may occur after maintenance work within a domain.
An operator may perform on demand-tests, but execution of automated PMS path trace checks may be set up too (scope may be limited to a subset of important end-to-end paths crossing the router or network section after completion of the maintenance work there). Upon detection of a path which can't be used, the operator needs to be notified. A check ensuring that re-routing event is differed from a path facing whose forwarding behavior doesn't correspond to the control plane information is necessary (but out of scope of this document).
Adding an automated problem solution to the PMS features only makes sense, if the root cause of the symptom appears often, can be assumed to be non- ambiguous by its symptoms, can be solved by a pre-determined chain of commands and the automated PMS reaction not doing any collateral damage. A closer analysis is out of scope of this document.
The PMS is expected to check control plane liveliness after a path repair effort was executed. It doesn't matter whether the path repair was triggered manually or by an automated system."
############
[JH] 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".
[ED] OK, will be done in next published version.
-----Ursprüngliche Nachricht-----
Von: Joel Halpern [mailto:jmh@xxxxxxxxxxxxxxx]
Gesendet: Donnerstag, 22. Juni 2017 15:30
An: rtg-dir@xxxxxxxx
Cc: spring@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-spring-oam-usecase.all@xxxxxxxx
Betreff: Rtgdir last call review of draft-ietf-spring-oam-usecase-06
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".