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(_at_)joelhalpern(_dot_)com]
Gesendet: Donnerstag, 22. Juni 2017 15:30
An: rtg-dir(_at_)ietf(_dot_)org
Cc: spring(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
draft-ietf-spring-oam-usecase(_dot_)all(_at_)ietf(_dot_)org
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".