Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)
draft-ietf-pce-pcep-service-aware-13

I am concerned that the 24 bit values of microseconds are being represented in IEEE 32-bit floating point.
A quick look at conversions indicates that all integers will up to 6 significant figures can be converted without
loss of precision.  That implies that values of over 1 second may not be accurately sent.  It would be useful to
at least refer to the precision issue in the document.  I don't expect that the loss of precision at the microsecond
level is critical.

A few minor, mostly editorial comments:

- Abstract: The abstract seems unnecessarily long.  The point is to describe very briefly what the document is about. The more “motivating” text could be left to the intro.

-3: Will this section have value to readers of the RFC, once the RFC is published?

- General:  A lot (if not most) of the instances of “MAY” would better serve as “can”. They seem to be saying that it is possible for an element to do something, rather than offering permission to do that thing.

The authors and the OPS DIR reviewers (Jouni and Al) agreed on some new text.

ALFRED MORTON <acmorton@att.com> performed the opsdir review.

subject to the discussion on the caculation of the path delay variation metric coming to a close, I have no objections.

The security sections of the referenced documents look very good.  The one thing I don't see mentioned is use of these metrics to perform network reconnaissance to perform other attacks.  I'm also interested to see the responses to Stephen's questions.

Thanks.

I have quite a few comments and some parts really need fixing as things seems wrong to me. However, all these things are no big issues in itself that do not justify a discuss. I strongly recommend to discuss these points and apply changes where appropriate to make these metrics useful by providing the right information.

- This doesn't seem right to mean:
"The link bandwidth utilization (the total
   bandwidth of a link in current use for the forwarding)"
Especially the word "current" is irritating as I strongly assume you'd be interested in something like the average utilization...?

- In general I would clarify that you always talk about averages and not the current values because those change too dynamically to use them for path computation.

- section 3 could be removed. It didn't really help me and the normative language here is actually a little bit confusing to me.

- section 4.2.1: This also doesn't seem to be fully correct:
"An implementation,
   therefore, MAY use the sum of the average delay variation of links
   along a path to derive the average delay variation of the Path."
I would assume that the average path delay variation is NOT the sum of the link variation.
What you get is the maximum variation of the average link delay variation... not sure if that's the best metric to provide for path computation.
Maybe it would be more useful to use the maximum of the average link delay variation as an extimate for the path delay variation?

Also not sure what exactly the next sentence should tell me:
"An implementation MAY also use some enhanced composition function for
   computing the average delay variation of a path."

- OLD:
"The value for the P2MP path delay metric type (T) = TBD8 is to be
   assigned by IANA."
NEW:
"The value for the P2MP path delay metric type (T) is TBD8."
Also in the next two sections...

- The term "Link Bandwidth Utilization (LBU)" is really confusing because I thought that utilization always is a value in percentage. I would propose to go inline with [RFC7471] and [RFC7810] and call it "Utilized Link Bandwidth"! (Similar for next section)

- section 4.2.2.: Really?
"The actual bandwidth by non-RSVP-TE
   traffic can be calculated by subtracting the available Bandwidth from
   the residual Bandwidth ([RFC7471] and [RFC7810]).  Once we have the
   actual bandwidth for non-RSVP TE traffic, subtracting this from LBU
   would result in LRBU."
Isn't the bandwidth utilization/ulilized bandwidth inculding the Link Reserved Bandwidth Utilization...? Not sure if I get this part correctly...

- section 4.2.3.1:
OLD
"A PCE that supports this object MUST ensure that no link on
   the computed path has bandwidth utilization (LBU or LRBU percentage)
   exceeding the given value."
NEW
"A PCE that supports this object MUST compute a path with LBU or LRBU percentage that does not
   exceed the given value."
I don't think the thing stated in the original sentence is possible based on the given information in the LBU/LRBU.

- "If, for a given request, two or more instances
   of a BU object with the same type are present, only the first
   instance MUST be considered and other instances MUST be ignored."
Maybe it's better to consider the lowest value instead of the first instance?

- "If a PCE receives a PCReq message containing a BU object, and the PCE
   does not understand or support the BU object, and the P bit is clear
   in the BU object header then the PCE SHOULD simply ignore the BU
   object."
  Isn't this the default behavior? How should a PCE that does support this draft/understand the BU object do any actions...?
Similar, the next part:
"If the PCE does not understand the BU object, and the P bit is set in
   the BU object header, then the PCE MUST send a PCErr message
   containing a PCEP-ERROR Object with Error-Type = 3 (Unknown object)
   and Error-value = 1 (Unrecognized object class) as per [RFC5440]."
Just remove those two paragraphs...?

- In general, had the feeling that the order of the document is a little up-side-down. However, I'm not sure if changing the order helps. Maybe double-check (also to avoid redunancy)!

- You're missing a reference for TCP-AO (RFC5925 I
guess)

- My understanding is that TCP-AO is not widely
deployed. If it is expected that PCEPS will be, then
it'd maybe be good to indicate that in section 9. 

- I would have thought that these extensions would
provide new ways in which networks could lie about
things in order to influence what paths are chosen.
Is that new or was it already considered in the
referenced RFCs? (Sorry, didn't have time to check
right now.) If it is new, maybe it's worth a mention?
Note: I'm not suggesting that this document specify
the one true way to deal with that, just that it be
noted, if it's useful to do that, but given one
motivation offered is financial services, presumably
not everyone trusts everyone to be entirely honest;-)