Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt

"Yemin (Amy)" <amy.yemin@huawei.com> Wed, 02 January 2019 11:11 UTC

Return-Path: <amy.yemin@huawei.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEE612785F; Wed, 2 Jan 2019 03:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ajJtgQKN8xUS; Wed, 2 Jan 2019 03:10:57 -0800 (PST)
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 90DEA12872C; Wed, 2 Jan 2019 03:10:57 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 288A4A314123A; Wed, 2 Jan 2019 11:10:52 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 2 Jan 2019 11:10:53 +0000
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.187]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0415.000; Wed, 2 Jan 2019 19:10:27 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt
Thread-Index: AQHUkHQMNuJZA14+IkGunO5i0q3cdKWb9bpw
Date: Wed, 2 Jan 2019 11:10:26 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFAE51E8@DGGEMM528-MBX.china.huawei.com>
References: <18E167C3-8061-46CF-9594-D8D27E8BC44F@nokia.com>
In-Reply-To: <18E167C3-8061-46CF-9594-D8D27E8BC44F@nokia.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.169.30.234]
Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461FCFAE51E8DGGEMM528MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/a57ka_F_lylm_htdHX068Sb06cM>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jan 2019 11:11:01 -0000

Hi Matthew,

The 12 version is uploaded to address all the technical issue. https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-availability/
We will further work with RFC editors to improve the draft readability.

BR,
Amy (on behalf of co-authors)
From: Bocci, Matthew (Nokia - GB) [mailto:matthew.bocci@nokia.com]
Sent: Monday, December 10, 2018 6:35 PM
To: rtg-ads@ietf.org
Cc: draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org; rtg-dir@ietf.org; ccamp@ietf.org
Subject: RtgDir review: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt
Reviewer: Matthew Bocci
Review Date: 9 December 2018
IETF LC End Date: Unknown
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved before
publication.

Comments:

The document is relatively concise, but I found that it could do with rewording in many
areas for clarity and to correct the English grammar. I have one issue that I found that I
consider major that I have listed below but that should be resolved as soon as possible. There are also some
minor issues related to the clarity of the specification that should be fixed before publication.


Major Issues:

Page 6, 3rd Paragraph: "When two LSPs request bandwidth with the same availability
   requirement, contention SHOULD/MUST be resolved by comparing the
   node IDs, .."

   Either it is a SHOULD or a MUST. The distinction between the two can make the
   difference between a document being acceptable or not to a WG and the IETF and can
   raise wider arguments about interoperability. Please resolve which of these you mean
    before proceeding.

Minor Issues:

Page 5, 1st Paragraph below figure 1: "The Availability TLV MUST come along with Ethernet
Bandwidth Profile TLV."

   I think you need to be more careful in the way this phrased. You are not saying that
   an Ethernet BW Profile TLV must always be accompanied by an Availability TLV, but rather that
   if you include an Availability TLV, the Ethernet BW Profile TLV must also be included.
   I suggest rephrasing this to "When the Availability TLV is included it MUST be present
   along with the Ethernet Bandwidth Profile TLV."

Page 3, 2nd Paragraph: I found the whole discussion here somewhat confusing. The text seems to mix
up service availability requirements (which are often specified in an SLA e.g. % of time a service is UP),
with the ability of a given service (voice/video/non-real-time data etc) to withstand fluctuations
in the bandwidth of the underlying transport. This could be fixed by always using the term 'bandwidth availability'
instead of just 'availability'.

Nits:

I found that the readability could be improved with some rewording of the text to improve
the English grammar and sentence structure. I would suggest reviewing with a native
English speaker to help with this.


Thanks,

Matthew