Subject: [OSPF] Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 10 Dec 2014 15:03:06 -0800

The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPF Traffic Engineering (TE) Metric Extensions'
  <draft-ietf-ospf-te-metric-extensions-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-12-24. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   In certain networks, such as, but not limited to, financial
   information networks (e.g., stock market data providers), network
   performance criteria (e.g., latency) are becoming as critical to data
   path selection as other metrics.

   This document describes extensions to RFC 3630 'Traffic Engineering
   (TE) Extensions to OSPF Version 2' such that network performance
   information can be distributed and collected in a scalable fashion.
   The information distributed using OSPF TE Metric Extensions can then
   be used to make path selection decisions based on network
   performance.

   Note that this document only covers the mechanisms with which network
   performance information is distributed. The mechanisms for measuring
   network performance or acting on that information, once distributed,
   are outside the scope of this document.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/ballot/

The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/2442/
   http://datatracker.ietf.org/ipr/2199/

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Dec 2014 23:07:08 -0000

All,

I reviewed this document as AD and found a few small points that I have asked
the authors to address as IETF last call comments.

Adrian

===

Please look for places where you have "proposed" something and change
that to "defined".

---

It would be good to include a reference for encoding floating point
integers. The usual is (I think)...

        IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
        Standard 754-1985, 1985 (ISBN 1-5593-7653-8).

---

Section 4.2.5

   Implementations MAY also permit the configuration of a static (non
   dynamic) offset value (in microseconds) to be added to the measured
   delay value, to facilitate the communication of operator specific
   delay constraints.

On the third reading I got it! I'm slow (I have a high delay :-)

The point here is that the measured value and the static value are added
together and the sum is transmitted in this field. I'd suggest...

   Implementations MAY also permit the configuration of a static (non
   dynamic) offset value (in microseconds) to be added to the measured
   delay value before encoding into this TLV, to facilitate the 
   communication of operator specific delay constraints.

Similarly in 4.2.6.

---

4.2.7 appears out of sequence. But since it repeats the content of 
4.2.4 I suggest you merge them and talk about the plurality of fields.

---

Section 7

"Sections 6 and 7 provide" should be 5 and 6.

---

Section 10

   "As per (RFC3630), unrecognized TLVs should be silently ignored"

There has been confusion about what 3630 means by "silently ignored".
In particular, some enthusiastic implementations thought this meant the
TLVs should be stripped from the LSA before it is propagated. I think it
is worth the few words to explicitly state that this is not the case.

---

Section 13

RFC 4203 is used in a normative way, please move it to the other 
section.