[Isis-wg] Brian Haberman's No Objection on draft-ietf-isis-te-metric-extensions-09: (with COMMENT)

["Brian Haberman" <[e-mail]>]

Brian Haberman has entered the following ballot position for
draft-ietf-isis-te-metric-extensions-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-te-metric-extensions/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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