Re: [CCAMP] Warren Kumari's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)

[Warren Kumari <[e-mail]>]

On Thu, Apr 11, 2019 at 8:27 AM Yemin (Amy) <[e-mail]> wrote:

> Hi Warren,
>
> Thanks for the comments, please see reply inline below.
>
> BR,
> Amy
> ________________________________________
> 发件人: Warren Kumari via Datatracker [[e-mail]]
> 发送时间: 2019年4月10日 7:44
> 收件人: The IESG
> 抄送: [e-mail]; Daniele
> Ceccarelli; [e-mail]; [e-mail];
> [e-mail]
> 主题: Warren Kumari's No Objection on
> draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: No Objection
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I must admit that I'm having a hard time understanding the utility of
> this, and
> how exactly systems are supposed to make a reasonable decision based upon
> the
> information -- I don't **really** care that the probability of the link
> being
> at 100Mbps is 99.995%, what I care about is what the available bandwidth is
> *now*. When my device has a 123Mbps flow, it needs to decide what to do
> with it
> -- I get that this document describes how the bandwidth probability can be
> transmitted, but how should my device use this information?
> [Amy] The OSPF extension RFC8330 defines how the information is
> distributed by OSPF.
> This draft defines the signaling, how much bandwidth and corresponding
> availability level a flow would like to have.
>
> I'm also confused by the table:
> Sub-bandwidth (Mbps)   Availability
>    ------------------     ------------
>    200                    99.99%
>    100                    99.995%
>    100                    99.999%
>
> Is there an error here?
> [Amy] The table will be modified as following:
>    400                    99.99%
>    200                    99.995%
>    100                    99.999%
>
>
Cool, thanks.



> I also support the DISCUSS on the floating-point issue -- perhaps this
> could be
> much more simply encoded with a table and some bits? E.G: 25%, 50%, 75%,
> 80%,
> 90%, 91%, 92%.. 99%. If > 99%, then the remaining gets used to encode the
> "number of nines" availability (5 == 5 nines).
> [Amy] Since the OSPF extension RFC8330 use the floating-point number, here
> we would like to continue using it.
>

Ah, ok, fair enough.

Thanks,
W



> Reference to IEEE754 will be added.
>



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf