Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS
draft-ietf-pce-gmpls-pcep-extensions-16

Thank you for addressing my DISCUSS and COMMENT items.

I think Section 2.1.2 needs to better explain what happens when a PCC sends extensions but the recipient does not support them.

Please respond to the Gen-ART review.

Thank you for addressing my Discuss points!

I do have some additional comments on the -15.

Section 2.3

I'm still a bit concerned that the references linked from Table 4 may not
provide a clear description of what count as Traffic Parameters for our
purposes (and how they are encoded), but not in a way that I can express
more concretely.  Perhaps this is made clear by some RSVP-TE documents
with which I am not familiar.

ection 2.5.1

   root and other endpoints TLVs are the leaves.  The root endpoint MUST
   be the same for all END-POINTS objects.  If the root endpoint is not

I'm not sure how broadly scoped this restriction is -- it is, e.g., per-LSP?

Section 2.5.2.5

   with L bit cleared.  At most 2 LABEL_SET TLVs MAY be present with the
   O bit set, with at most one of these having the U bit set and at most
   one of these having the U bit cleared.  For a given U bit value, if

This went MUST->MAY in this rev, though I think it might be fine to just use
a lowercase "may", since the requirements language doesn't map terribly well
to the restriction we're making.

Hi,

thanks for this document. I have a discuss point that shouldn't be difficult to resolve:

Why do you define a flag field in the GMPLS-CAPABILITY TLV if you don't have any flag?
I guess the easy answer is that there might be some in the future.
If so, I tend to think that creating a registry for that field would be a good thing to do now.

-m

Purely editorial comment:
I would recommend to move most of the gap analysis of section 1 (actually most of the text of the whole section) into the appendix and only summarise the extensions specified in this doc instead. 

nit:
sec 6: s/In order to protect against against the malicious PCE case/In order to protect against the malicious PCE case/ -> 2x against

* Section 2.5.2

"In this object type the order of the TLVs MUST be followed according to the object type definition."

Not sure what this means. Can you clarify?

* Section 2.7

"C-Type (8 bits): the C-Type of the included Label Object as defined in [RFC3471]."

I could not find any references to C-Types in RFC3471. Shouldn't you be referring to RFC3473 instead? I have a similar comment for the Label field.