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

From: Alia Atlas <[email-masked]>
Date: Thu, 18 Dec 2014 11:28:18 -0500

Are there routing YANG models that are running into concerns around
floating point?

Regards,
Alia

---------- Forwarded message ----------
From: Acee Lindem (acee) <[email-masked]>
Date: Wed, Dec 17, 2014 at 7:30 PM
Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF
Traffic Engineering (TE) Metric Extensions) to Proposed Standard
To: "t.p." <[email-masked]>, "[email-masked]" <
[email-masked]>
Cc: "[email-masked]" <
[email-masked]>, "[email-masked]" <
[email-masked]>

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:

>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:
>
>> 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:
>>>
>>>> On the question of Floating-Point, there is now 754-2008, which is a
>>>> tighter spec and is used in RFC6340.
>>>
>>> What is 754-2008?
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Adrian Farrel" <[email-masked]>
>>>> To: <[email-masked]>
>>>> Cc: <[email-masked]>; <[email-masked]>
>>>> Sent: Wednesday, December 10, 2014 11:07 PM
>>>>
>>>>> 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.petch <[email-masked]>
Date: Thu, 18 Dec 2014 18:05:43 +0000

----- Original Message -----
From: "Alia Atlas" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 18, 2014 4:28 PM

Alia

24Apr14 netmod WG list Robert Varga
"while modeling some protocols (notably RSVP), we came across the need
to represent IEEE754-2008 floating types without losing precision. I'd
like
to ask what is the group's sentiment regarding extending the base types
with at least binary{32,64} (which have their counterparts in XML schema
datatypes)."

which suggests that the answer is yes.

I might have posed a slightly different question, such as - does
anyone outside a few on the netmod WG list realise that YANG has no
support for floating point, just decimal-64?

In passing, YANG did have floating point support in 2008/2009, which led
to Martin saying

"Here's a proposal for solving our float problem, which is one of the
few remaining open issues in the YANG document.
I suggest we remove the float types, and instead replace them with a
fix point decimal type, much like xs:decimal. "

which duly happened.  Details in the archives.

Interestingly, for me, this preceded the addition of floating point to
SMI with RFC6340 in August 2011; one of the arguments for removing
floating point from YANG was that SMI had never needed it in all its
years.

Tom Petch

(OSPF
> >>> Subject: Re: Last Call:
<draft-ietf-ospf-te-metric-extensions-08.txt>
> >>>>> RFC 4203 is used in a normative way, please move it to the other

------------------------------------------------------------------------
--------

> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 18 Dec 2014 13:38:34 -0500

Tom,

> which suggests that the answer is yes.

Indeed it does.  Assuming these TE extensions are modeled, there'll be at
least
4 models with issues then - OSPF, ISIS, RSVP-TE, and probably PCE.

> support for floating point, just decimal-64?

If they didn't before, they should be aware now.

Alia

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Dec 2014 10:49:43 -0800

> If they didn't before, they should be aware now.

I think some vendors objected to mandatory support for floating point
since not all their platforms supported it.  Rather than have an
optional base type, it was removed.

You might have to define a string-based typedef for encoding
float32 or float64.

> Alia

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Dec 2014 19:53:04 +0100

> floating point from YANG was that SMI had never needed it in all its

I think the following questions are important:

a) Does network gear use floating point arithmetic internally in their
   implementations or are numbers just represented as floating point
   numbers but internally treated as fixed poined anyway?

b) Is the large range that is possible using floating point numbers
   needed or desirable?

It is instructive to see how FLOAT-TC-MIB is used. In some cases, it
is modeling a quality number between 0 and 1. Is IEEE floating point
needed for that? In other cases, they are used to model bandwidth.
Again, are IEEE floating point numbers needed for that? If we would
model link distances between integrated circuits and between planets
in different galaxies, then a floating point type may make a lot of
sense.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Bill Fenner <[email-masked]>
Date: Thu, 18 Dec 2014 20:57:24 -0500

> On Dec 18, 2014, at 1:53 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

We use floating point extensively, including for TimeTicks where fixed point would do. Turns out that you don't need a floating-point co-processor any more when you are designing systems with modern CPUs.

  Bill

---

From: t.petch <[email-masked]>
Date: Fri, 19 Dec 2014 10:08:07 +0000

----- Original Message -----
From: "Alia Atlas" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 18, 2014 6:38 PM

> 4 models with issues then - OSPF, ISIS, RSVP-TE, and probably PCE.

...  to which might be added IDR's flow spec (RFC5575) along with
GMPLS's ted-mib (which cites RFC6340 - but I expect that that is your
OSPF and ISIS)

Historically, MEF's CIR has been expressed in floating point but I don't
think that that is part of current CCAMP work.

Tom Petch

---

From: Alia Atlas <[email-masked]>
Date: Fri, 19 Dec 2014 09:08:59 -0500

Juergen,

It sounds like the lack of floating point is a gap.

For values such as bandwidth, we do need to express rather wide ranges.
I do agree that fixed point can work well - but that is not what is
configured
or carried in the protocols.

In particular, given that converting to/from fixed-point may not give
the same starting values, the lack of support seems like it will
cause difficulties and confusion.

Alia

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Dec 2014 08:11:17 -0800

> cause difficulties and confusion.

http://www.ietf.org/mail-archive/web/netmod/current/msg02685.html

This describes a typedef replacement for float that was discussed in
the NETMOD WG in 2009.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 20 Dec 2014 18:03:15 +0100

On Fri, Dec 19, 2014 at 09:08:59AM -0500, Alia Atlas wrote:
> configured or carried in the protocols.

Can you tell the range? I would assume that even a simple unsigned
64-bit number might do the job if the unit is bits per second.

1 Tbps = 1000000000000 bps
2^64 bps = 18446744073709551616 bps = 18446744 Tbps

Are you sure you need a float? And for probabilities between 0 and 1,
are you sure you need a float?

> cause difficulties and confusion.

I been told there are boxes shipping values as floats and converting
them back and forth to an internal representation that is not using
floats (because of custom linecard hardware that did not do floating
point math).

Anyway, if a WG really believes they need floating point numbers to
represent a probability or bandwidth, simply define a typedef.

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 21 Dec 2014 02:04:59 +0000

>are you sure you need a float?

The question isn¹t whether we need a float for the range of value. The
RSVP and TE protocol representation has been float for many values has
been float since RFC 2210. Why is it a big deal to add a YANG type?

Acee

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 21 Dec 2014 13:57:01 +0100

> been float since RFC 2210. Why is it a big deal to add a YANG type?

It is not a big deal. I just wanted to point out that what RSVP and TE
protocols do is, from a viewpoint of accuracy and efficiency, somewhat
questionable.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sun, 21 Dec 2014 08:23:46 -0800

> protocols do is, from a viewpoint of accuracy and efficiency, somewhat

It is a big deal to add a base type.  It can only be used in the new
language version which will not be available in tools for a long time,
and could create compatibility issues.

However, a typedef can be added now and will work with YANG 1.0.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 21 Dec 2014 22:32:40 +0100

> and could create compatibility issues.

Yes, and note that I did not write 'base type'.
 
> However, a typedef can be added now and will work with YANG 1.0.

Exactly.

I still remain unconvinced that IEEE floats are technically the
correct solution for token buckets and the like. I doubt that the
Linux netlink interface into the kernel uses floats. But then TE must
decide whether they like to see a float, even though they may give a
false sense of precision.

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 22 Dec 2014 00:06:44 +0000

>false sense of precision.

I agree that IEEE Float-32 is not an optimal choice for representation of
bandwidth and other integrated services values in RSVP. My point was that
this was the choice that was made (although I didn¹t articulate this very
well). 

Thanks,
Acee

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Dec 2014 09:53:31 +0100

> this was the choice that was made (although I didn¹t articulate this very

A certain protocol encodes the values in IEEE floating point format
but that does not mean that implementations or other interfaces have
to use IEEE floating point format (and I would not be surprised if a
number of implementations do _not_ use IEEE floating point format).
Encoding and internal representation are sometimes different things.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Dec 2014 10:00:38 +0100 (CET)

> this was the choice that was made (although I didn¹t articulate this very

Ok, it is clear that the protocol uses floats internally.  Does it
follow that the configuration model has to use floats as well?  Or
would decimal64 work?

For the interested reader, the following mail threads may be useful to
read.  Background: from the start YANG had floats, but we removed them
when we couldn't get them to work nicely.

http://www.ietf.org/mail-archive/web/netmod/current/msg01855.html

http://www.ietf.org/mail-archive/web/netmod/current/msg02216.html

/martin