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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 7 Jan 2015 14:26:48 +0000

On 12/22/14, 4:00 AM, "Martin Bjorklund" <[email-masked]> wrote:

>"Acee Lindem (acee)" <[email-masked]> wrote:
>> 
>> 
>> On 12/21/14, 4:32 PM, "Juergen Schoenwaelder"
>> <[email-masked]> 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
>> >> <[email-masked]> 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

---

From: Benoit Claise <[email-masked]>
Date: Sat, 10 Jan 2015 00:18:35 +0100

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
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Qin Wu <[email-masked]>
Date: Mon, 12 Jan 2015 14:42:49 +0000

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:[email-masked]] 代表 Benoit Claise
发送时间: 2015年1月10日 7:19
收件人: Acee Lindem (acee); Martin Bjorklund
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: [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,

  typedef probability {

     type unit decimal64 {

        range "0 .. 1";

     }

     description

  }

  typedef quality {

     type unit decimal64 {

        range "0 .. 1";

     }

     description

  }

  typedef bandwidth {

     type uint64;

     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" <[email-masked]><mailto:[email-masked]> wrote:

"Acee Lindem (acee)" <[email-masked]><mailto:[email-masked]> wrote:

<[email-masked]><mailto:[email-masked]> wrote:

<[email-masked]><mailto:[email-masked]> wrote:

and TE

somewhat

questionable.

time,

Exactly.

of

that

very

well).

would decimal64 work?

Thanks,

Acee

/martin

[email-masked]<mailto:[email-masked]>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Jan 2015 09:20:45 +0100

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.
>
> *? ??:*Rtg-yang-coord [mailto:[email-masked]] *? ? 
> *Benoit Claise
> *? ???:*2015?1?10?7:19
> *???:*Acee Lindem (acee); Martin Bjorklund
> *??:[email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> *??:*[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,
>
>       // 2^^56    would still allow for ~72 peta bits per second
>       unit "bits per second"
>       description
>         "[to be written]";
>    }
>   
>     On 12/22/14, 4:00 AM, "Martin Bjorklund"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>       
>
>         "Acee Lindem (acee)"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>               
>
>               
>
>             <[email-masked]>  <mailto:[email-masked]>  wrote:
>
>               
>
>                     <[email-masked]>  <mailto:[email-masked]>  wrote:
>
>                           
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 15 Jan 2015 13:00:57 +0000

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:[email-masked]]
发送时间: 2015年1月15日 16:21
收件人: Qin Wu; Acee Lindem (acee); Martin Bjorklund
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Rtg-yang-coord] Floating point

Hi Qin,

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:[email-masked]] 代 表 Benoit Claise
发 送时间: 2015年1月10日 7:19
收件人: Acee Lindem (acee); Martin Bjorklund
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: [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,

  typedef probability {

     type unit decimal64 {

        range "0 .. 1";

     }

     description

  }

  typedef quality {

     type unit decimal64 {

        range "0 .. 1";

     }

     description

  }

  typedef bandwidth {

     type uint64;

     unit "bits per second"

     description

       "[to be written]";

  }

Regards, Benoit

and TE

somewhat

questionable.

time,

Exactly.

of

that

very

well).

would decimal64 work?

Thanks,

Acee

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Jan 2015 14:42:15 +0100

> track down the final solution, make them solved in the RFC6020bis, RFC6021bis.

The YANG language is maintained by the NETMOD working group and this
is where discussions concerning YANG features need to take place. If
people create tickets or discussions outside NETMOD, there is a good
chance that NETMDO will ignore them. Also note that the NETMOD WG is
following a structured process for the YANG 1.1 activity in order to
try to deliver on time.

/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: Qin Wu <[email-masked]>
Date: Fri, 16 Jan 2015 02:45:04 +0000

Juergen:
I agree we should bring these issues up on the NETMOD list, I am not proposing to slow down YANG 1.1 activity, but we need to find a way to address these open issues which may be obstacles to the future yang model development.

Regards!
-Qin
-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2015年1月15日 21:42
收件人: Qin Wu
抄送: Benoit Claise; [email-masked]
主题: Re: [Rtg-yang-coord] Floating point

On Thu, Jan 15, 2015 at 01:00:57PM +0000, Qin Wu wrote:
> 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.
>

The YANG language is maintained by the NETMOD working group and this is where discussions concerning YANG features need to take place. If people create tickets or discussions outside NETMOD, there is a good chance that NETMDO will ignore them. Also note that the NETMOD WG is following a structured process for the YANG 1.1 activity in order to try to deliver on time.

/js