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

"Yemin (Amy)" <amy.yemin@huawei.com> Thu, 11 April 2019 12:27 UTC

Return-Path: <amy.yemin@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716C71201D7; Thu, 11 Apr 2019 05:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Ou7l5QjXgSLq; Thu, 11 Apr 2019 05:27:00 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C32F120048; Thu, 11 Apr 2019 05:27:00 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 891E9C5C0B78A0FE36AB; Thu, 11 Apr 2019 13:26:58 +0100 (IST)
Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Apr 2019 13:26:58 +0100
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.72]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0415.000; Thu, 11 Apr 2019 20:26:55 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: Warren Kumari <warren@kumari.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org>, "Daniele Ceccarelli" <daniele.ceccarelli@ericsson.com>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: Warren Kumari's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)
Thread-Index: AQHU7y4huJoB2xZ570i9+lwrZRWjJKY24sos
Date: Thu, 11 Apr 2019 12:26:54 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFBDC1BD@DGGEMM528-MBX.china.huawei.com>
References: <155485344540.19678.965634240652575034.idtracker@ietfa.amsl.com>
In-Reply-To: <155485344540.19678.965634240652575034.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.156]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/1SBjtEpHPfGXcXAPBEDDBX8rpTk>
Subject: Re: [CCAMP] Warren Kumari's No Objection on draft-ietf-ccamp-rsvp-te-bandwidth-availability-14: (with COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 12:27:03 -0000

Hi Warren, 

Thanks for the comments, please see reply inline below. 

BR,
Amy
________________________________________
发件人: Warren Kumari via Datatracker [noreply@ietf.org]
发送时间: 2019年4月10日 7:44
收件人: The IESG
抄送: draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org; Daniele Ceccarelli; ccamp-chairs@ietf.org; daniele.ceccarelli@ericsson.com; ccamp@ietf.org
主题: 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%

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. 
Reference to IEEE754 will be added.