Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS
RFC 8779
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
Alvaro Retana No Objection
Roman Danyliw (was Discuss) No Objection
Thank you for addressing my DISCUSS and COMMENT items.
(Deborah Brungard; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
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.
(Barry Leiba; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
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.
(Ignas Bagdonas; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) (was Discuss) No Objection
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
(Mirja Kühlewind; former steering group member) No Objection
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
(Suresh Krishnan; former steering group member) No Objection
* 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.