IETF Logo Mail Archive

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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 07 January 2015 14:26 UTC

Return-Path: <acee@cisco.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 ECB171A904E for <rtg-yang-coord@ietfa.amsl.com>; Wed, 7 Jan 2015 06:26:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 iXRfZ5pYfoqi for <rtg-yang-coord@ietfa.amsl.com>; Wed, 7 Jan 2015 06:26:49 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB001A904B for <Rtg-yang-coord@ietf.org>; Wed, 7 Jan 2015 06:26:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3130; q=dns/txt; s=iport; t=1420640809; x=1421850409; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iT60nXwyJQOOF3rpLcuN4cOFIdBEppvs/mOxXcEPmks=; b=J8fI5T5PaEXixNBnZBY4zRj4JaC0/uLeSqMhiAQv/kjPAgiRE9i/dgGd O6CIMC6YtbDWgER+iC6zFQiq4imlSh7RtUVZ5+np1y3fgo0Sm6HgGKmuT 5hwUcq2yp7mscAte0mMt0IrMt5Qyc25N0eT0itHcCllIBjCeQv1Nv5QR5 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArIFAI5BrVStJV2d/2dsb2JhbABcgwZSWASDAsMwhSlKAhxzQwEBAQEBfYQNAQEENEUQAgEIDgIIBB8JAgIwJQIEDgUJEogRDZJinGAGkzYBAQEBAQEBAQEBAQEBAQEBAQEagRuMIYFrAQFPB4JigUcFji6JAIEOhSKLNCKCMoE8bwGBCzl+AQEB
X-IronPort-AV: E=Sophos;i="5.07,714,1413244800"; d="scan'208";a="385376511"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jan 2015 14:26:49 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t07EQn0U028884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Jan 2015 14:26:49 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.144]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 08:26:48 -0600
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
Thread-Topic: [Rtg-yang-coord] Fwd: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt> (OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard
Thread-Index: AQHQFjbHi9X/7NLXKEiSKgwlpJ6WzJyMpteAgAAAwwCABKFMgIACYezSgADtGACAAV+AAP//vz0CgABlKACAAKZDPoAAoMCAgAHDBYCAAEOEAIABCgWAgAA5xACAAFZOAP//1zmAgADo/gCAGGbsAA==
Date: Wed, 07 Jan 2015 14:26:48 +0000
Message-ID: <D0D20519.B275%acee@cisco.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>
In-Reply-To: <20141222.100038.719440000332847338.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.197]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <EF46FDCF53585C4291CEC4ABE796C4E9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/phTa4NGUJIzAt3KGSKHPdUh0m0M
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>, "andy@yumaworks.com" <andy@yumaworks.com>, "ietfc@btconnect.com" <ietfc@btconnect.com>
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
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: Wed, 07 Jan 2015 14:26:52 -0000


On 12/22/14, 4:00 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

>"Acee Lindem (acee)" <acee@cisco.com> wrote:
>> 
>> 
>> On 12/21/14, 4:32 PM, "Juergen Schoenwaelder"
>> <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> 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

v2.23.0 | Report a Bug | By Email