I've reviewed draft-ietf-pce-monitoring-04.txt as part of the transport area
directorate's ongoing effort to review key IETF documents. These comments were
written primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address any
issues raised. The authors should consider this review together with any other
last-call comments they receive. Please always CC tsv-dir(_at_)ietf(_dot_)org if you
reply to or forward this review.
draft-ietf-pce-monitoring-04.txt describes procedures and extensions to the
Path Computation Element Protocol (PCEP) for monitoring the state of the path
computation chain for troubleshooting and performance monitoring purposes.
It is designed specifically to carry information about PCE liveness,
processing time and congestion.
However this draft does not define any of these metrics.
As a transport person, I have several comments about the congestion metric.
First it wasn't clear from the document if "congestion" was referring to the
PCE itself or the corresponding LSPs. For clarity of discussion, I will
assume LSP congestion. Even if that is not correct, my comments are general
and there are equivalent problems for PCE case.
Second, there is not a universal definition of congestion. The relevant
feature of congestion is that it perturbs transit flows, by causing some sort
of back-pressure. This back-pressure generally comes in the form of raised
RTT and/or increased loss probability, which reduces the data rate for elastic
flows. In the operational Internet normal values for these parameters can
span many orders of magnitude. For example on research and education
backbones, loss probabilities as high as 1E-6 would be considered massively
congested. In other parts of the world loss probabilities as low as 1E-2
might be considered extremely good. There is not a standard way to determine
when the load is high enough to effect service or when the users would
perceive the network as "congested".
Without a definition of what congested means the metric is useless for such
things as choosing alternative paths. One implementation's uncongested state
might be lower performance than another implementation's congested state.
Even if you are thinking in terms of admission control (where the
back-pressure is to reject calls), your success probability might be higher on
a very congested heavily multiplexed path than another path which has a single
user is using most of the capacity, but not quite filling the link.
Although my examples are somewhat contrived, my point still stands: without a
definition of "congested" there is no value to sharing a congestion
indication. I can't imagine any global definition of congestion that would
work, and suspect that you need to add a mechanism to define a local,
organization/topology specific definition of congestion.
Third, the only parameter carried by the congestion object is "expected
congestion duration", as though the network can anticipate when the congestion
will subside. It can't. It may be that this parameter would be better
identified by something like "recommended polling interval", e.g. "please
don't ask again for x seconds."
In a similar vein neither processing time nor liveness is sufficiently
well defined.
Although this is perhaps a nit, the IANA directions are structured in a way
that forces somebody else to rewrite your text, possibly introducing errors,
and peventing full review in last call. E.g. where you have "The MONITORING
Object-Class is to be assigned by IANA (recommended value=19)" It would be
better to say "The MONITORING Object-Class is XX [Value to be provided by
IANA, recommended value=1]" The point is to clearly distinguish between 3
classes of text:
- Stuff that IANA adjusts in a clearly specified way while the document is at
the RFC editor.
- Instructions to the IANA that should be removed while at the RFC editor,
generally about the above.
- Instruction to the IANA that should be preserved in the final RFC (Registry
creation, etc), which might include some details in the previous two
categories.
It should be clear to everyone (especially the reviewers) how the IANA text is
expected to be appear in the final RFC, even when it can't match the ID.
This draft has serious issues, described in the review, and needs some
rethinking.
Thanks,
--MM--
-------------------------------------------
Matt Mathis http://staff.psc.edu/mathis
Work:412.268.3319 Home/Cell:412.654.7529
-------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf