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