Subject: Re: [netmod] Y59: what about decimal56 data type?

From: Randy Presuhn <[email-masked]>
Date: Tue, 30 Dec 2014 09:04:24 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Dec 30, 2014 1:50 AM
>To: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] Y59: what about decimal56 data type?
...
>- Sometimes people use floating point numbers when there really is no
>  need to use them. There really is no need to represent a drop
>  probability using IEEE floating point numbers. There is no need to
>  represent bandwidth using IEEE floating point numbers. This is
>  primarily an educational problem and perhaps it deserves adding text
>  to RFC 6087bis.

Yes.  This is part of the motivation for all the "applicability"
language in RFC 6340.

>- Introducing a typedef that sounds and smells like an IEEE
>  float/double but in fact is different will cause confusion. If there
>  really is a demonstrated need for floating point numbers, we better
>  use something that maps easily to other programming languages and
>  things like xpath.

Yes.  Also, it would be good to be clear on precisely which
IEEE 754 type(s) were to be supported; the (relatively new)
decimal64 and decimal128 types have the advantage of being
easily mappable to string representations without a lot of
worry about fuzz, but probably enjoy far less hardware and
software support than, say, binary64.

>It would help a lot seeing a use case that convinces me that the full
>range of floating point numbers are needed for network management. The
>argument 'protocol X uses IEEE floating point numbers => YANG has to
>support IEEE floating point' with X in { RSVP, ... } is not by itself
>convincing - I think it matters how IEEE floating point numbers are
>used and whether the whole precision needs to be available at a
>network management interface.

I think one might encounter them in performance statistics, where they'd
typically end up being configured only for setting thresholds defined in
terms of those statistics.  Experience with RFC 6340 suggests that while
the use cases may exist, the situations where floating point is the best
solution are relatively rare.  To me that suggests that if this group is
going to add floating support, the less divergence from IEEE 754 (pick a
flavor) the better.  Reinventing the wheel for corner cases makes little
sense.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 30 Dec 2014 19:11:46 +0100

On Tue, Dec 30, 2014 at 09:04:24AM -0800, Randy Presuhn wrote:
> solution are relatively rare.
>

The RFC 6340 definintions are used by the following IETF MIB modules:

- TED-MIB

  Used to model bandwidth in bytes per second (tedMaxBandwidth,
  tedMaxReservableBandwidth, tedUnreservedBandwidthPri0, ...,
  tedUnreservedBandwidthPri7).

- PSAMP-MIB

  Use for a probability (psampSampUniProbProbability).

- NHDP-MIB

  Used for a quality value between 0 and 1 (nhdpHystAcceptQuality,
  nhdpHystRejectQuality, nhdpInitialQuality).

I argue that none of them needs floating point numbers. Perhaps we do
better if we define a 'bandwidth' typedef, a 'probability' typedef and
a 'quality' typedef using the native types we have. Any MIB modules I
am missing?

/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/>