Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-inter-layer-req-15

From: Lou Berger <[email-masked]>
Date: Fri, 18 Feb 2011 16:37:41 -0500

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. The purpose 
of the review is to provide assistance to the Routing ADs. For more 
information about the Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

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-req-15.txt
Reviewer: Lou Berger
Review Date: 2/18/2011
IETF LC End Date: 2011-01-07 (requested review by 2/18/2011)
Intended Status: Informational

Summary:

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

Comments:

      I found this to be a solid draft overall with no major 
deficiencies or nits.  I do have a number of minor points/questions that 
I think are worth resolving before publication.  The draft passes ID 
nits with warnings that I believe can be disregarded.

Line numbers obtained from 
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-pce-inter-layer-req-15.txt 
will be used in this review.

Major Issues:

      No major issues found.

Minor Issues:

I'll start with general comments/questions and then move into 
text/section specific points.

- General comment/question: In reading the document I found a number of 
places where the text seemed to imply that the PCC was always the 
layer/region boundary, which is inconsistent with RFC5623.  Is this 
intentional?

Examples from the document include:
257 An ingress LSR for the higher-layer LSP, or a PCC, needs to
258 know whether triggered signaling is required or not.

While this is true for the boundary LSR, I'm not sure how it fits into 
this document.  Isn't such determination made by the boundary LSR per 
RFCs 4206 and 6001?  If so, the sentence is out of scope of this 
document.  If you do keep it, I suggest replacing " An ingress LSR for 
the higher-layer LSP, or a PCC," with something along the lines of "A 
layer boundary LSR".

275   Also note that an ingress LSR may be present in multiple layers.

Is "ingress LSR" mean "a layer boundary LSR", or "the PCC LSR"?

299  3.1.4. Adaptation Capability

301  It MUST be possible for the path computation request to indicate the
302  desired adaptation function at the end points of the lower-layer LSP
303  that is being computed. This will be particularly important where the
304  ingress and egress LSR participate in more than one layer network but
305  may not be capable of all associated adaptations.

This section cases me concern a number of levels.  The first is that 
"adaptation function" is not defined in this document, nor is it used in 
the other MRN documents.  Furthermore, is it reasonable to have 
adaptation  indicated by a PCC when the layer/region boundary is at an 
intermediate LSR?  Perhaps this paragraph is only intended to apply to a 
multi-layer PCC/LSR?  In either case, the scope and intent of this 
paragraph really needs to be clarified.

- Now on to specific points/comments:

126 [RFC4657] and [RFC4674].

Suggest adding ", and the framework provided in [RFC5623]."

271   virtual TE links from regular TE links, it MUST be understood that a

Who MUST understand this? If this is the reader/implementer/user then 
this should be "must".  If there are protocol implications, they should 
be made more explicit, i.e., they're not clear.

276  Thus, when a mono-layer path is requested or supplied, PCEP MUST be
277  able to indicate the required/provided path layer.

Doesn't this requirement also apply to multi-layer paths? (Consider case 
where ingress/PCC is present in multiple layers.)

330 purpose, the PCE discovery mechanism MAY support the disclosure of

As this applies to the mechanism and not a particular implementation, 
shouldn't this be a "MUST"?

333	   path-computation-related PCE capabilities:

Should supported layers be included in the advertised capability list?

350	4.1. Control of Function and Policy

Do you want to add a reference to 5394?

That's it!
Lou