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

From: "Brian Haberman" <[email-masked]>
Date: Wed, 03 Feb 2016 05:54:00 -0800

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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 8 Feb 2016 16:28:01 +0000

> https://datatracker.ietf.org/doc/draft-ietf-isis-te-metric-extensions/

Introduction section specifies:

   While this document does not specify
   how the performance information should be obtained, the measurement
   of delay SHOULD NOT vary significantly based upon the offered traffic
   load.  Thus, queuing delays SHOULD NOT be included in the delay
   measurement. 

it has been agreed in the WGs (ospf and isis) to intentionally leave the queueing delay in order not to vary the measurements significantly.

> 3393? There is no clear definition of delay variation provided in this

the following paragraph is in the Introduction section:

   Note that the mechanisms described in this document only disseminate
   performance information.  The methods for initially gathering that
   performance information, such as [RFC6375], or acting on it once it
   is distributed are outside the scope of this document.  Example
   mechanisms to measure latency, delay variation, and loss in an MPLS
   network are given in [RFC6374].  

This 

> in delay from”.

yes.

> Secondly, how does the local (transmitting?) neighbor

well, nothing prevents a probe to be used so to collect one-way delay in  both directions. Intentionally, due to the unidirectional nature of ls protocols, it has been scoped on the local->remote direction.

s.