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

"Yemin (Amy)" <amy.yemin@huawei.com> Fri, 14 December 2018 06:03 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 07A20131073; Thu, 13 Dec 2018 22:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GTXocM7zo-d2; Thu, 13 Dec 2018 22:03:30 -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 0B922131071; Thu, 13 Dec 2018 22:03:30 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 20974B8305710; Fri, 14 Dec 2018 06:03:27 +0000 (GMT)
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 14 Dec 2018 06:03:27 +0000
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.187]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0415.000; Fri, 14 Dec 2018 14:03:15 +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+IkGunO5i0q3cdKV9fQdw
Date: Fri, 14 Dec 2018 06:03:15 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFAD8FCA@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_9C5FD3EFA72E1740A3D41BADDE0B461FCFAD8FCADGGEMM528MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/FaZ2YNe7TMmz0IAKDHXmB2va7pg>
Subject: Re: [CCAMP] RtgDir review: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt
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: Fri, 14 Dec 2018 06:03:33 -0000

Hi Matthew,

Thanks for your review comments.
Please see my reply inline below.

BR,
Amy
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.
[Amy] Sorry for the English grammar problems, I hope this could be improved with the help from RFC editors.

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.
[Amy] Thanks for pointing it out. I fully agree that it should be clearly defined to avoid interoperability problem.
 I prefer to use MUST, to align with RFC3471.

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."
[Amy] Will update the draft as you suggested.

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'.
[Amy] Will update the draft as you suggested.

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