[RTG-DIR] RtgDir review: draft-ietf-pce-inter-layer-ext-12.txt

Martin Vigoureux <martin.vigoureux@nokia.com> Fri, 20 January 2017 14:04 UTC

Return-Path: <martin.vigoureux@nokia.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 3DE7A129451; Fri, 20 Jan 2017 06:04:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.057
X-Spam-Level:
X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, 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 tXRsvBIqJ-G0; Fri, 20 Jan 2017 06:04:56 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 23047129434; Fri, 20 Jan 2017 06:04:53 -0800 (PST)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 956EFA513491A; Fri, 20 Jan 2017 14:04:46 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0KE4mST012876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2017 14:04:49 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0KE4SHt012212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jan 2017 14:04:47 GMT
Received: from [135.224.216.124] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 20 Jan 2017 15:04:39 +0100
From: Martin Vigoureux <martin.vigoureux@nokia.com>
To: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Message-ID: <524a6dfd-9164-1788-bd52-96cb9b429ffe@nokia.com>
Date: Fri, 20 Jan 2017 15:04:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [135.239.27.40]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/IXCmNTRCYgISxBtXeMVftq_ez8A>
Cc: draft-ietf-pce-inter-layer-ext.all@ietf.org, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, pce@ietf.org
Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-inter-layer-ext-12.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 20 Jan 2017 14:04:58 -0000

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-pce-inter-layer-ext-12.txt
Reviewer: Martin Vigoureux
Review Date: 2017-01-20
IETF LC End Date: n/a
Intended Status: Standards Track


Summary:
This document is ready for publication.
I have found couple of items that made me raise questions, though.

Comments:
The Document is very well written. Great care has been taken to provide 
the reader with all the necessary information and pointers for him/her 
to apprehend the technology elements which are specified. Both protocol 
specification and clear elements of procedure are provided which is good.

Minor Issues:
    It is important to optimize network resource utilization globally,
    i.e., taking into account all layers, rather than optimizing resource
    utilization at each layer independently.  This allows better network
    efficiency to be achieved.
Would the authors know at least a publication, which could be 
referenced, in support of that statement? I don't necessarily disagree 
with it but I find that it would nicely complement the view.

    [RFC4206] defines a way to signal ...
    [RFC5623] describes models for inter-...
    [RFC6457] describes two sub-options ....
HTMLization does not work on references when they are the first element 
of a paragraph. Maybe something for the tools' team. In any case, not 
critical and not worth reworking the sentences unless you are as maniac 
as me :-)

You state:
    If the I flag is clear (zero), the M flag has no meaning and MUST be
    ignored.
But you don't have any similar statement regarding I and T. Is that on 
purpose or would one be useful?
Somehow related to that, I was wondering if there is any value in 
sending the INTER-LAYER object when I=0?
As a corollary, is the I bit really useful?

    The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono-
    layer network to specify a requested adaptation capability for both
    ends of the LSP.  In this case, it MAY be carried without an INTER-
    LAYER Object.
Reading the last sentence makes me think that in the other cases an 
INTER-LAYER Object MUST/SHOULD be present. I am going too far or would 
some clarification on that aspect be valuable?
For example Section 4.1 is very clear about SWITCH & INTER -LAYER Objects.

I guess it wouldn't hurt to expand OF on its first use:
    multiple OF objects

I am not sure to understand this request:
    IANA is further requested to update the registry to show an
    assignment action of "IETF Consensus" as already documented in
    [RFC5440].
Could you elaborate? Are you asking IANA to change the assignment policy 
from "IETF Review" to "IETF Consensus"? If so I doubt this will happen 
since rfc5226, which you cite just above, says:
    IETF Review - (Formerly called "IETF Consensus" ....

Regards,
Martin