Skip to main content

Last Call Review of draft-ietf-pce-inter-layer-ext-12
review-ietf-pce-inter-layer-ext-12-rtgdir-lc-vigoureux-2017-01-21-00

Request Review of draft-ietf-pce-inter-layer-ext
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-01-24
Requested 2017-01-09
Requested by Xian Zhang
Authors Eiji Oki , Tomonori Takeda , Adrian Farrel , Fatai Zhang
I-D last updated 2017-01-21
Completed reviews Rtgdir Last Call review of -12 by Martin Vigoureux
Secdir Last Call review of -12 by Shawn M Emery
Genart Last Call review of -12 by Roni Even
Assignment Reviewer Martin Vigoureux
State Completed
Request Last Call review on draft-ietf-pce-inter-layer-ext by Routing Area Directorate Assigned
Reviewed revision 12
Result Has issues
Completed 2017-01-21
review-ietf-pce-inter-layer-ext-12-rtgdir-lc-vigoureux-2017-01-21-00
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