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

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.

---

From: t.p. <[email-masked]>
Date: Fri, 12 Dec 2014 18:08:37 +0000

On the question of Floating-Point, there is now 754-2008, which is a
tighter spec and is used in RFC6340.

At a tangent, the issue of floating-point support has surfaced a number
of times in YANG and, to date, has always been rejected, reckoning that
suppport for 64-bit decimal is adequate for data modelling.  The
interactions with XPath (which is used as a basis for YANG constraint
statements), where floating-point is allowed, have caused a number of
discussions, some ongoing, about the comparison of a floating-point
number to a 64-bit decimal one. Something to be aware of should you ever
want to model this in YANG.

Tom Petch

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 Dec 2014 18:16:18 -0000

Good catch Tom,

Acee, the trick is to go to 6340 and look in the references :-)

   [IEEE.754.2008]  Institute of Electrical and Electronics Engineers,
                    "Standard for Floating-Point Arithmetic",
                    IEEE Standard 754, August 2008.

A

> -----Original Message-----
> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: 12 December 2014 18:14
> To: t.p.
> Cc: [email-masked];
[email-masked];
> [email-masked]
> Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF
Traffic
> Engineering (TE) Metric Extensions) to Proposed Standard
> 
> Hi Tom,
> 
> On Dec 12, 2014, at 1:08 PM, t.p. <[email-masked]> wrote:
> 
> What is 754-2008?
> Thanks,
> Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 12 Dec 2014 18:14:06 +0000

Hi Tom,

What is 754-2008? 

Thanks,
Acee

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Dec 2014 18:06:26 -0000

Hi Acee,

> Can you guys indicate how you would like to see this comment reflected in the
> draft? Are you suggesting to change he encoding to 64 bits for the new
> bandwidth sub-TLVs?

There's a float-32, a float-64, and a float-128.

I think 32 bits is adequate.
All you need to change is to add the citations.

Adrian

> On Dec 12, 2014, at 1:16 PM, Adrian Farrel <[email-masked]> wrote:
> 
> > Good catch Tom,
> >

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 15 Dec 2014 16:58:47 +0000

Hi Adrian, Tom, 
Can you guys indicate how you would like to see this comment reflected in the draft? Are you suggesting to change he encoding to 64 bits for the new bandwidth sub-TLVs? 
Thanks,
Acee

---

From: t.p. <[email-masked]>
Date: Wed, 17 Dec 2014 10:14:27 +0000

Acee

Sorry that my original comment was opaque.   Partly, I was agreeing with
Adrian that a reference to a floating point standard would be a good
idea, but disagreeing with Adrain about the particular standard, that a
more recent one was available and had been used previously by an IETF
RFC.  That part I hope is now clear, thanks to the clarifications by
others.

My tangential comment was that YANG has no facility to model floating
point numbers, having looked at doing so and rejected it, several times,
reckoning that the decimal-64, defined in RFC6020 section 9.3, is
adequate for network configuration.

A consequence of this, which is understood, is that if you think of a
number, express it in YANG's decimal-64, convert it to floating point
because that is what XPath uses (and so is used by YANG's conditional
statements), convert it back to decimal-64 then you do not get the
number you first thought of (sometimes), so a test for equality will
fail, when you might expect it to succeed.

Is this an issue?  The consensus of the netmod WG (AFAICT) is that it is
not, that the use of floating point in the IETF is minimal - after all,
it took SNMP over 20 years to get round to specifying it.

But given the explosion of interest in YANG recently, I think it is a
topic to keep an eye on so when I read an I-D and find floating point, I
point{!} out that it cannot readily be modeled.  I suspect that, in this
case, consistency with what has gone before outweighs the facility to do
it in YANG.

Tom Petch

----- Original Message -----
From: "Acee Lindem (acee)" <[email-masked]>
To: <[email-masked]>
Cc: "t.p." <[email-masked]>;
<[email-masked]>;
<[email-masked]>
Sent: Monday, December 15, 2014 4:58 PM
Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt>
(OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard

Hi Adrian, Tom,
Can you guys indicate how you would like to see this comment reflected
in the draft? Are you suggesting to change he encoding to 64 bits for
the new bandwidth sub-TLVs?
Thanks,
Acee
On Dec 12, 2014, at 1:16 PM, Adrian Farrel <[email-masked]> wrote:

>>>> TLVs should be stripped from the LSA before it is propagated. I
think
>>> it

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Dec 2014 00:30:16 +0000

Tom,

John Drake will update the reference in the OSPF TE Extensions draft. I
agree that YANG should have a corresponding common data type for floating
point since, for better or worse, RFC 2210 chose IEEE 32-bit floating
point representation for bandwidth many years ago.

Thanks,
Acee 

On 12/17/14, 5:14 AM, "t.p." <[email-masked]> wrote:

>(OSPF