Tom,
John Drake will update the reference in the OSPF TE Extensions draft. I
agree that YANG should have a corresponding common data type for floating
point since, for better or worse, RFC 2210 chose IEEE 32-bit floating
point representation for bandwidth many years ago.
Thanks,
Acee
On 12/17/14, 5:14 AM, "t.p." <daedulus@xxxxxxxxxxxxx> wrote:
>Acee
>
>Sorry that my original comment was opaque. Partly, I was agreeing with
>Adrian that a reference to a floating point standard would be a good
>idea, but disagreeing with Adrain about the particular standard, that a
>more recent one was available and had been used previously by an IETF
>RFC. That part I hope is now clear, thanks to the clarifications by
>others.
>
>My tangential comment was that YANG has no facility to model floating
>point numbers, having looked at doing so and rejected it, several times,
>reckoning that the decimal-64, defined in RFC6020 section 9.3, is
>adequate for network configuration.
>
>A consequence of this, which is understood, is that if you think of a
>number, express it in YANG's decimal-64, convert it to floating point
>because that is what XPath uses (and so is used by YANG's conditional
>statements), convert it back to decimal-64 then you do not get the
>number you first thought of (sometimes), so a test for equality will
>fail, when you might expect it to succeed.
>
>Is this an issue? The consensus of the netmod WG (AFAICT) is that it is
>not, that the use of floating point in the IETF is minimal - after all,
>it took SNMP over 20 years to get round to specifying it.
>
>But given the explosion of interest in YANG recently, I think it is a
>topic to keep an eye on so when I read an I-D and find floating point, I
>point{!} out that it cannot readily be modeled. I suspect that, in this
>case, consistency with what has gone before outweighs the facility to do
>it in YANG.
>
>Tom Petch
>
>
>----- Original Message -----
>From: "Acee Lindem (acee)" <acee@xxxxxxxxx>
>To: <adrian@xxxxxxxxxxxx>
>Cc: "t.p." <daedulus@xxxxxxxxxxxxx>;
><draft-ietf-ospf-te-metric-extensions.all@xxxxxxxxxxxxxx>;
><ietf@xxxxxxxx>
>Sent: Monday, December 15, 2014 4:58 PM
>Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt>
>(OSPF Traffic Engineering (TE) Metric Extensions) to Proposed Standard
>
>
>Hi Adrian, Tom,
>Can you guys indicate how you would like to see this comment reflected
>in the draft? Are you suggesting to change he encoding to 64 bits for
>the new bandwidth sub-TLVs?
>Thanks,
>Acee
>On Dec 12, 2014, at 1:16 PM, Adrian Farrel <adrian@xxxxxxxxxxxx> wrote:
>
>> Good catch Tom,
>>
>> Acee, the trick is to go to 6340 and look in the references :-)
>>
>> [IEEE.754.2008] Institute of Electrical and Electronics Engineers,
>> "Standard for Floating-Point Arithmetic",
>> IEEE Standard 754, August 2008.
>>
>> A
>>
>>> -----Original Message-----
>>> From: Acee Lindem (acee) [mailto:acee@xxxxxxxxx]
>>> Sent: 12 December 2014 18:14
>>> To: t.p.
>>> Cc: adrian@xxxxxxxxxxxx;
>> draft-ietf-ospf-te-metric-extensions.all@xxxxxxxxxxxxxx;
>>> ietf@xxxxxxxx
>>> Subject: Re: Last Call: <draft-ietf-ospf-te-metric-extensions-08.txt>
>(OSPF
>> Traffic
>>> Engineering (TE) Metric Extensions) to Proposed Standard
>>>
>>> Hi Tom,
>>>
>>> On Dec 12, 2014, at 1:08 PM, t.p. <daedulus@xxxxxxxxxxxxx> wrote:
>>>
>>>> On the question of Floating-Point, there is now 754-2008, which is a
>>>> tighter spec and is used in RFC6340.
>>>
>>> What is 754-2008?
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>>
>>>> At a tangent, the issue of floating-point support has surfaced a
>number
>>>> of times in YANG and, to date, has always been rejected, reckoning
>that
>>>> suppport for 64-bit decimal is adequate for data modelling. The
>>>> interactions with XPath (which is used as a basis for YANG
>constraint
>>>> statements), where floating-point is allowed, have caused a number
>of
>>>> discussions, some ongoing, about the comparison of a floating-point
>>>> number to a 64-bit decimal one. Something to be aware of should you
>ever
>>>> want to model this in YANG.
>>>>
>>>> Tom Petch
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Adrian Farrel" <adrian@xxxxxxxxxxxx>
>>>> To: <draft-ietf-ospf-te-metric-extensions.all@xxxxxxxxxxxxxx>
>>>> Cc: <ospf@xxxxxxxx>; <ietf@xxxxxxxx>
>>>> Sent: Wednesday, December 10, 2014 11:07 PM
>>>>
>>>>> All,
>>>>>
>>>>> I reviewed this document as AD and found a few small points that I
>>>> have asked
>>>>> the authors to address as IETF last call comments.
>>>>>
>>>>> Adrian
>>>>>
>>>>> ===
>>>>>
>>>>> Please look for places where you have "proposed" something and
>change
>>>>> that to "defined".
>>>>>
>>>>> ---
>>>>>
>>>>> It would be good to include a reference for encoding floating point
>>>>> integers. The usual is (I think)...
>>>>>
>>>>> IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
>>>>> Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
>>>>>
>>>>> ---
>>>>>
>>>>> Section 4.2.5
>>>>>
>>>>> Implementations MAY also permit the configuration of a static (non
>>>>> dynamic) offset value (in microseconds) to be added to the
>measured
>>>>> delay value, to facilitate the communication of operator specific
>>>>> delay constraints.
>>>>>
>>>>> On the third reading I got it! I'm slow (I have a high delay :-)
>>>>>
>>>>> The point here is that the measured value and the static value are
>>>> added
>>>>> together and the sum is transmitted in this field. I'd suggest...
>>>>>
>>>>> Implementations MAY also permit the configuration of a static (non
>>>>> dynamic) offset value (in microseconds) to be added to the
>measured
>>>>
>>>>> delay value before encoding into this TLV, to facilitate the
>>>>> communication of operator specific delay constraints.
>>>>>
>>>>> Similarly in 4.2.6.
>>>>>
>>>>> ---
>>>>>
>>>>> 4.2.7 appears out of sequence. But since it repeats the content of
>>>>> 4.2.4 I suggest you merge them and talk about the plurality of
>fields.
>>>>>
>>>>> ---
>>>>>
>>>>> Section 7
>>>>>
>>>>> "Sections 6 and 7 provide" should be 5 and 6.
>>>>>
>>>>> ---
>>>>>
>>>>> Section 10
>>>>>
>>>>> "As per (RFC3630), unrecognized TLVs should be silently ignored"
>>>>>
>>>>> There has been confusion about what 3630 means by "silently
>ignored".
>>>>> In particular, some enthusiastic implementations thought this meant
>>>> the
>>>>> TLVs should be stripped from the LSA before it is propagated. I
>think
>>>> it
>>>>> is worth the few words to explicitly state that this is not the
>case.
>>>>>
>>>>> ---
>>>>>
>>>>> Section 13
>>>>>
>>>>> RFC 4203 is used in a normative way, please move it to the other
>>>>> section.
>>>>>
>>>>>
>>>>>
>>>>
>>
>