IS-IS Traffic Engineering (TE) Metric Extensions
draft-ietf-isis-te-metric-extensions-11

Thanks for resolving my DISCUSS points.

Old COMMENT points:

(1) In Section 5:

OLD
Min and max delay MAY be the lowest and/or highest measured value
   over a measurement interval

NEW   
Min and max delay MAY be the lowest and highest measured value
   over a measurement interval, respectively,
   
(2) Section 11 says:

"It is anticipated that in most deployments, IS-IS protocol is used
   within an infrastructure entirely under control of the dame operator."
   
But Section 1 says:

"The data distributed by the IS-IS TE Metric Extensions proposed in
   this document is meant to be used as part of the operation of the
   routing protocol (e.g. by replacing cost with latency or considering
   bandwidth as well as cost), by enhancing Constrained-SPF (CSPF), or
   for other uses such as supplementing the data used by an ALTO server
   [RFC7285]."

In the ALTO case at least it would seem like the point of using this data would be to inform applications (outside the control of the operator) about the cost of routing traffic a certain way. I think this section could be more clear about the expectation that the performance data it exposes may be factored into such costs that get published outside the operator network.

I've only a couple of minor comments to add to what my colleagues have already said:

-- Section 1 --

   For links, such as Forwarding Adjacencies, care must be taken

With the first comma, the qualifier "such as Forwarding Adjacencies" is only parenthetical.  I think you're *specifically* talking about "links such as Forwarding Adjacencies" here, so you need to remove that comma.

-- Section 5 --

   Min and max delay MAY be the lowest and/or highest measured value
   over a measurement interval or MAY make use of a filter, or other
   technique, to obtain a reasonable representation of a min and max
   value representative of the interval with compensation for outliers.

Making sure this normatively says what you want it to:
What this says is that min and max delay can be anything anyone wants it to be, with no restrictions at all, because there are only 2119 "MAY" key words here, and "MAY" means optional.  Specifically, it means that min and max do NOT have to have any resemblance to any reasonable representations.

What I think you *mean* to say is that they each MUST be one of two things: either taken from measured values or be reasonable representations.  You can freely choose between those, but they have to be one or the other.  Is that correct?

If that's correct, then you need to say it in some manner such as this:

NEW
   Min and max delay MUST each be derived in one of the following ways:
   by taking the lowest and/or highest measured value over a measurement
   interval, or by makeins use of a filter or other technique to obtain
   a reasonable representation of a min and max value representative of
   the interval, with compensation for outliers.
END

I concur with Alissa's 2nd discuss point.

-11, paragraph 4:
s/"dame operator"/"same operator"

From Nevil Brownlee (OPS DIR reviewer) and Stefano Previdi's discussion: 

> I have one issue to raise: the last paragraph of section 2
> (introducing the metrics to for each of the new sub-TLVs) says that
> the values "MUST be calculated as rolling averages where the averaging
> period MUST be a configurable period of time."  This draft does not
> say how that interval will be configured.


the paragraph refers to section 5 “Announcement Thresholds and Filters” where the thresholds and average values are explained. The specifics of the configuration are not present because these are implementation specifics aspects. 

The same has been done in RFC7471 which is the OSPF version of this draft.


>  For proper operation,
> surely all participating IS-IS routers will need to use the same
> measurement interval?


Well, while it would make sense to use the same interval, it is not a requirement and it’s possible to have a network where nodes use different intervals to measure their links utilization. Also, as described in section 5, the interval may vary and advertisements may be done immediately in some cases.


>  I suggest that some text explaining this, and
> saying how a router's measurement interval can be checked by other
> routers, would be useful.


Here also there are no requirements for a router to be able to verify which interval other routers used.

=====================================

Since that triggered some questions/discussions, a few sentences around the following points would make sense from an OPS point of view:
- While it would make sense to use the same interval, it is not a requirement and it’s possible to have a network where nodes use different intervals to measure their links utilization
- There are no requirements for a router to be able to verify which interval other routers used.

Regards, Benoit

* The Introduction dismisses queuing delays. However, queue delays pose a large risk to minimizing path delay (and delay variation). How useful is a "minimal delay" path computed by IS-IS if queue delays are not accounted for?

* Does this document use the same definition of delay variation as RFC 3393? There is no clear definition of delay variation provided in this document.

* Section 4.3 states that the "delay variation advertised  by this sub-TLV MUST be the delay from the local neighbor to the remote one." I would assume that "the delay from" is really meant to be "the variation in delay from". Secondly, how does the local (transmitting?) neighbor know the variation in delay? That is typically measured by the receiving neighbor.

Nevil Brownlee perfromed the opsdir review

- Couldn't exposing these metrics (e.g. to a passive
attacker) help the attacker decide which part(s) of a network
to attack or help the attacke to measure the effectiveness of
some other attack they have mounted?  (E.g. a physical attack
on fibre) I think that is worth noting in section 11, perhaps
with guidance that sending this information in clear over
less trusted parts of the network might best be avoided, e.g.
by encrypting that traffic? Put another way... I agree with
Alissa's 2nd discuss point, but I'd argue that the proposed
re-phrasing (from mail from Stefano on Feb 2nd) ought include
the above and not only say "might be sensitive."

- Would it be worth noting that if a future specification
allows some control node or router to ask another to emit
these metrics, then that future specification will need to
consider (abuse of) that control interface as a new attack
vector?