Re: [Rtg-yang-coord] Floating point

[Qin Wu <[e-mail]>]

Thanks Benoit.
You are right, putting tracked issues in one place is not enough,
I think we can use issue tracking system to create new ticket for each open issue and
track their status. Also we can establish connection between these YANG language issues and YANG Doctors,
track down the final solution, make them solved in the RFC6020bis, RFC6021bis.

Regards!
-Qin
发件人: Benoit Claise [mailto:[e-mail]]
发送时间: 2015年1月15日 16:21
收件人: Qin Wu; Acee Lindem (acee); Martin Bjorklund
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Re: [Rtg-yang-coord] Floating point

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#<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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/rtg-yang-coord