Subject: [OSPF] AD review of draft-ietf-ospf-te-metric-extensions

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

Authors,

Thanks for your work on this document. I am acting as "responsible" AD
as Alia (the usual AD for OSPF) is a co-author.

I've done my usual review on receiving the publication request. I see a
few small issues to attend to, but these do not need to hold up the IETF
last call. I will start that last call and submit my comments as last 
call comments that you can handle along with any other comments you
receive.

Thanks,
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.