Re: [CCAMP] Magnus Westerlund's Discuss on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with DISCUSS)

[Magnus Westerlund <[e-mail]>]

Hi,

Thanks for the response. From my perspective I think with the
clarification that the format is IEEE 754 the only thing I would ask is
to comment on the limitation of the field.

Cheers

Magnus

On 2019-04-11 17:03, Yemin (Amy) wrote:
> Hi Magnus, 
>
> Thanks for the comments, please see reply inline below. 
>
> BR,
> Amy
> ________________________________________
> 发件人: Magnus Westerlund via Datatracker [[e-mail]]
> 发送时间: 2019年4月8日 18:13
> 收件人: The IESG
> 抄送: [e-mail]; Daniele Ceccarelli; [e-mail]; [e-mail]; [e-mail]
> 主题: Magnus Westerlund's Discuss on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with DISCUSS)
>
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 3.1:
>
>       Availability (4 octets): a 32-bit floating point number describes
>       the decimal value of availability requirement for this bandwidth
>       request. The value MUST be less than 1and is usually expressed in
>       the value of 0.99/0.999/0.9999/0.99999.
>
> It appears that this format has some very clear limitations when it comes to
> store availability numbers. Assuming that this 32-bit float is an IEEE-754
> representation which should be explicitly stated.
>
> In that case representing availabilities higher than 0.999999 starts to
> introduce significant errors in relation to intended precision. Intended value
> Error                                             Actual value 0.999999
>  -1.3278961181640625E-8              0.999998986721038818359375 0.9999999
>  -1.920928955078125E-8                0.99999988079071044921875 0.99999999
> 1E-8                                                   1 (Which is not allowed)
>
> So at a minimal the limitations for what is practical to express needs to be
> provided. Secondly, are this range sufficient in all cases?
> [Amy] The floating point number may not be the perfect unit. But since the OSPF extension RFC8330 use the floating-point number, we would like to continue using it. 
> Regarding the range, normally five 9s 0.99999 is highest value in telecom network, that's 5 minutes outage in a year.
> So floating point is capable to represent this range.
>
>
>
>

-- 

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------