I
am the assigned Gen-ART reviewer for this
draft. The General Area
Review Team (Gen-ART) reviews all IETF
documents being processed
by the IESG for the IETF Chair. Please
treat these comments just
like any other last call comments.
Document: draft-ietf-teas-te-express-path-03
Reviewer: Robert Sparks
Review Date: 28 Sep 2015
IETF LC End Date: 30 Sep 2015
IESG Telechat date: 1 Oct 2015
Summary: Ready for publication as
Informational, with nits
Nits/editorial comments:
This document is all about considerations.
Specifically, it discusses what to consider
if you were to build a path computation
function that uses the kind of information
you get from the TE metric extensions in
RFC7471 and
draft-ietf-isis-te-metric-extensions. It
does not appear to be requirements for
standardization work - rather, it is
information for operators to use when
building functions that don't necessarily
need standardization.
However, it looks as if the document may
have once contemplated actually specifying a
path computation function, and has legacy
text from that thought?
No - it was always about how one could
use the information and isn't trying to
standardize a particular function.
The
abstract says "This specification uses
network performance data ... to perform such
path selections." But this document doesn't
perform such path selections (or specify how
to do them).
Would you prefer
"This specification describes how a path
computation function may use network
performance data, such as is advertised via
the OSPF and ISIS TE metric extensions
(defined outside the scope of this document)
to perform such path selections."
Yes, thanks!
Section
1.1 says "The following are the requirements
that motivate this solution." But this draft
doesn't actually specify a "solution". It
discusses what to consider if you were to
build a path computation function. Could
this be framed as a set of goals to keep in
mind while building your own such function?
Would you be ok with changing it to "..
that motivate this document?"
They were used to drive the document contents
(that's not obvious) and not to inform what an
implementation should achieve?
Perhaps the sentence could be replaced with
"As these considerations were assembled, care was taken
to discuss points relevant to an implementation's
ability to:"
?
What about "The following are the requirements
considered for a path computation function that uses
network performance criteria."
OK
Alia
The
third paragraph of section 1.2 could use
clarification. I suspect the word "even" in
the 4th sentence should be removed, and the
judgement in "There may be legitimate use"
is out of place. Consider rewriting the
paragraph using simpler sentences.
I've removed the word "even" and changed
the last sentence about "There may be
legitimate use..." to be
"However, there may be uses of a..."
Section
2.3 appears to be considerations
specifically for interpreting the anomalous
bit in one specific extension? If so, the
introduction to the section should call that
out. If not, the section's structure needs
improvement. The section also calls out two
questions, but only discusses one of them
explicitly.
In Sec 2.3.1, the anomalous bit behavior
is described for latency, loss, and jitter.
On double-checking, I see that the Anomalous
Bit was removed for jitter in RFC7471 and
draft-ietf-isis-te-metric-extensions. I've
removed the last sentence in the second
paragraph of 2.3.1 that discussed how to
handle that case.
Sec 2.3.2 discusses the second question
and how to handle it in detail.
Thanks again for the review! The changes
will be in 04.