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

["Stefano Previdi (sprevidi)" <[e-mail]>]

On Feb 3, 2016, at 2:54 PM, Brian Haberman <[e-mail]> wrote:
> 
> 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?


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.


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


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 


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


yes.


> Secondly, how does the local (transmitting?) neighbor
> know the variation in delay? That is typically measured by the receiving
> 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.


> 
>