Re: [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)
Qin Wu <bill.wu@huawei.com> Mon, 12 January 2015 14:43 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF831A930A for <rtg-yang-coord@ietfa.amsl.com>; Mon, 12 Jan 2015 06:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTL044HrBrhr for <rtg-yang-coord@ietfa.amsl.com>; Mon, 12 Jan 2015 06:43:06 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288151A9252 for <Rtg-yang-coord@ietf.org>; Mon, 12 Jan 2015 06:43:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNW29897; Mon, 12 Jan 2015 14:43:00 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 Jan 2015 14:42:52 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 12 Jan 2015 22:42:50 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Benoit Claise <bclaise@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>, Martin Bjorklund <mbj@tail-f.com>
Thread-Topic: [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)
Thread-Index: AQHQLGKi3LRfdeFO202duqoB7Qw5+Zy8kpAg
Date: Mon, 12 Jan 2015 14:42:49 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8469FB63@nkgeml501-mbs.china.huawei.com>
References: <CABCOCHThwQXPYZqK_gapK4ycGfkNUrfgL_81FZU1watVm8pM=A@mail.gmail.com> <20141221213240.GA34831@elstar.local> <D0BCC95F.AC81%acee@cisco.com> <20141222.100038.719440000332847338.mbj@tail-f.com> <D0D20519.B275%acee@cisco.com> <54B061CB.2090108@cisco.com>
In-Reply-To: <54B061CB.2090108@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.180]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8469FB63nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/Ccyf9Pv6_XNPn9Frvqrk0SSOOsY>
Cc: "Rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org>, "akatlas@gmail.com" <akatlas@gmail.com>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>, "ietfc@btconnect.com" <ietfc@btconnect.com>, "andy@yumaworks.com" <andy@yumaworks.com>
Subject: Re: [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)
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 14:43:10 -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:rtg-yang-coord-bounces@ietf.org] 代表 Benoit Claise 发送时间: 2015年1月10日 7:19 收件人: Acee Lindem (acee); Martin Bjorklund 抄送: Rtg-yang-coord@ietf.org; ietfc@btconnect.com; j.schoenwaelder@jacobs-university.de; andy@yumaworks.com; akatlas@gmail.com 主题: [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" <mbj@tail-f.com><mailto:mbj@tail-f.com> wrote: "Acee Lindem (acee)" <acee@cisco.com><mailto:acee@cisco.com> wrote: On 12/21/14, 4:32 PM, "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de><mailto:j.schoenwaelder@jacobs-university.de> 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 <j.schoenwaelder@jacobs-university.de><mailto:j.schoenwaelder@jacobs-university.de> 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 Rtg-yang-coord@ietf.org<mailto:Rtg-yang-coord@ietf.org> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
- [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-ospf… Alia Atlas
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… t.petch
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Alia Atlas
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Andy Bierman
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Bill Fenner
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… t.petch
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Alia Atlas
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Andy Bierman
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Acee Lindem (acee)
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Andy Bierman
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Acee Lindem (acee)
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Martin Bjorklund
- Re: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-… Acee Lindem (acee)
- [Rtg-yang-coord] Floating point (was: Fwd: Last C… Benoit Claise
- Re: [Rtg-yang-coord] Floating point (was: Fwd: La… Qin Wu
- Re: [Rtg-yang-coord] Floating point Benoit Claise
- Re: [Rtg-yang-coord] Floating point Qin Wu
- Re: [Rtg-yang-coord] Floating point Juergen Schoenwaelder
- Re: [Rtg-yang-coord] Floating point Qin Wu