Hi all, Please find below my review of draft-ietf-pce-gmpls-pcep-extensions, dug out of the backlog. Let us discuss the main identified issues first, we will look at the minor comments and nits afterwards.
Generally speaking, the main items to improve are related to clarification. Normative behavior and especially error handling often need more accurate descriptions to limit ambiguities. Sorting error values may also be deserved, especially with respect to existing error types. ------ Section 2.2 --- - s/The PCE MAY try to follow/The PCE SHOULD try to follow - s/Otherwise, the PCE MAY use/Otherwise, the PCE MUST use/ ------ Section 2.3 --- - The bidirectional symmetric bandwidth is defined with 2 MUST's and a MUST NOT: the error case is not specified if the 3 requirements are not followed. I guess a sentence pointing to Error-Type 10/Value TBA-14 would address this. - s/asymmetric bandwidth, it SHOULD/asymmetric bandwidth, it MUST/ ------ Section 2.4 --- - The following text is unnecessary and should be dropped: "A PCC SHOULD be allowed to request a set of TE-LSP also in case of GMPLS bandwidth specification. The LOAD-BALANCING has the same limitation as the BANDWIDTH for GMPLS networks." - Like above, the bidirectional symmetric bandwidth with LOAD-BALANCING is defined with 2 MUST's and a MUST NOT: the error case is not specified if the 3 requirements are not followed. I guess a sentence pointing to a relevant error (Type 10, new Value?) would address this. - s/while specifying load balancing constraints, it SHOULD/while specifying load balancing constraints, it MUST/ - About the last paragraph ("For example [...] corresponding request"): * Have you considered moving into appendix? * Codepoints are mentioned instead of TBA-2, -4... ------ Section 2.5.1 --- - s/restriction are not always/restriction may not be/ OLD: Endpoint type 0 MAY be accepted by the PCE, other endpoint type MAY be supported if the PCE implementation supports P2MP path calculation. A PCE not supporting a given endpoint type MUST respond with a PCErr with error code "Path computation failure", error type "Unsupported endpoint type in END- POINTS Generalized Endpoint object type". NEW: A PCE may accept only Endpoint Type 0: Endpoint Types 1-4 apply if the PCE implementation supports P2MP path calculation. A PCE not supporting a given Endpoint Type SHOULD respond with a PCErr with Error Type 4, Value TBD "Unsupported endpoint type in END-POINTS Generalized Endpoint object type". As per [RFC5440], a PCE unable to process Generalized Endpoints may respond with Error Type 3 or 4, Value 2. OLD: A PCE not supporting one of those TLVs in a PCReq MUST respond with a PCRep with NO-PATH with the bit "Unknown destination" or "Unknown source" in the NO-PATH-VECTOR TLV, the response SHOULD include the ENDPOINT object in the response with only the TLV it did not understood. NEW: When receiving a PCReq, a PCE unable to resolve the identifier in one of those TLVs MUST respond using a PCRep with NO-PATH and set the bit "Unknown destination" or "Unknown source" in the NO-PATH-VECTOR TLV. The response SHOULD include the ENDPOINT object with only the TLV it did not understand. - s/error type="Path computation failure"/Error Type 4/ ------ Section 2.5.2.5. --- - The I-D has chosen to allocate 2 TLV codepoints for LABEL-SET and SUGGESTED-LABEL-SET. Any reason not to use just one including a strict/loose bit to distinguish them? - s/allocated on the first link/allocated on the first endpoint/ - The text "has the same encoding as the LABEL-SET TLV, it" is redundant and should be dropped. OLD: This Bit SHOULD be set to 0 in a SUGGESTED-LABEL-SET TLV Set and ignored on receipt. This Label MAY be reused. The R bit of the RP object MUST be set. NEW: The R bit of the RP object MUST be set to 1. In a SUGGESTED-LABEL-SET TLV, this bit SHOULD be set to 0 and ignored on receipt. - In the 1st paragraph on page 19 ("Several LABEL_SET TLVs [...] be ignored"), it seems that SHOULD's should be MUST's. ------ Sections 2.6. & 2.7 --- - To be consistence with RFC 7896, both sentences about the L bit should be dropped. ------ Sections 3 & 5.5 --- - Several errors (e.g., TBD-15, -28, -29...) may be moved to Type 4. --- Best regards, Julien _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce