Re: [Rtg-yang-coord] Floating point

[Benoit Claise <[e-mail]>]

Hi Qin,

Thanks Qin, this WIKI contains a lot of valuable information.

Let me rephrase my point: documenting this issue is a good first step, 
but that doesn't mean that it will magically be solved :-)

Regards, Benoit
>
> This is an open issue with YANG language . We have recorded it with 
> other open issues in the yang coordinator wiki page.
>
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord#
>
> Regards!
>
> -Qin
>
> *? ??:*Rtg-yang-coord [mailto:[e-mail]] *? ? 
> *Benoit Claise
> *? ???:*2015?1?10?7:19
> *???:*Acee Lindem (acee); Martin Bjorklund
> *??:*[e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]
> *??:*[Rtg-yang-coord] Floating point (was: Fwd: Last Call: 
> <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF Traffic 
> Engineering (TE) Metric Extensions) to Proposed Standard)
>
> Dear all,
>
> I discussed the floating point situation with the NETMOD chairs.
> Let me try to summarize the situation.
>
> There are two main options:
>   
> 1. The NETMOD WG last time once decided not to add IEEE floating point types to the base type system. The routing experts, or whoever needs the floating point types, should come and articulate why they believe this decision was wrong to make the NETMOD
> folks change their opinion. Practically, that means writing a YANG module defining IEEE float/double typedefs.
>   
> 2. We try to understand which concrete types are needed for traffic engineering and routing purposes and we define specific typedefs such as
>   
>    typedef probability {
>       type unit decimal64 {
>          fraction-digits 18;  // need to discuss precision needed
>          range "0 .. 1";
>       }
>       description
>         "[to be written, need to discuss which precision is needed]";
>    }
>   
>    typedef quality {
>       type unit decimal64 {
>          fraction-digits 18;  // need to discuss precision needed
>          range "0 .. 1";
>       }
>       description
>         "[to be written, need to discuss which precision is needed]";
>    }
>   
>    typedef bandwidth {
>       type uint64;
>       // perhaps restrict range to avoid Y59 issues.
>       // 2^^56    would still allow for ~72 peta bits per second
>       unit "bits per second"
>       description
>         "[to be written]";
>    }
>   
>    These could be additions to the common typedefs we have.
>
> So basically, my message is: if you want the solution 1, the ball is 
> your court.
>
> Regards, Benoit
>
>       
>
>       
>
>     On 12/22/14, 4:00 AM, "Martin Bjorklund"<[e-mail]>  <mailto:[e-mail]>  wrote:
>
>       
>
>         "Acee Lindem (acee)"<[e-mail]>  <mailto:[e-mail]>  wrote:
>
>               
>
>               
>
>             On 12/21/14, 4:32 PM, "Juergen Schoenwaelder"
>
>             <[e-mail]>  <mailto:[e-mail]>  wrote:
>
>               
>
>                 On Sun, Dec 21, 2014 at 08:23:46AM -0800, Andy Bierman wrote:
>
>                     On Sun, Dec 21, 2014 at 4:57 AM, Juergen Schoenwaelder
>
>                     <[e-mail]>  <mailto:[e-mail]>  wrote:
>
>                           
>
>                         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.
>
>                       
>
>                     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.
>
>                   
>
>                 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.
>
>               
>
>             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).
>
>           
>
>         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?
>
>       
>
>     I doubt that configuration API for Traffic Engineering bandwidth are
>
>     floating point. However, we have been modeling the IGP Link State
>
>     Databases in the operational state.
>
>       
>
>     Thanks,
>
>     Acee
>
>       
>
>       
>
>           
>
>         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
>
>       
>
>     _______________________________________________
>
>     Rtg-yang-coord mailing list
>
>     [e-mail]  <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord