Thanks a lot, Luis for your review and comments. We are handling them and we'll respond to you soon with some inline responses.
Regards, Samuel From: Luis Contreras via Datatracker <[email protected]> Date: Monday, 17 November 2025 at 11:14 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: draft-ietf-pce-circuit-style-pcep-extensions-10 early Opsdir review Document: draft-ietf-pce-circuit-style-pcep-extensions Title: Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies Reviewer: Luis Contreras Review result: Has Issues Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: draft-ietf-pce-circuit-style-pcep-extensions-10 - Reviewer: Luis Contreras - Review Date: 17/11/2025 - Intended Status: Standards Track --- ## Summary - Has Issues: I have some minor concerns about this document that I think should be resolved before publication. ## General Comments from OPS perspective - Section 3.3, PATH-RECOMPUTATION TLV. When describing P flag, it is stated that “If this flag is cleared, then the PCE MAY recompute the path according to local policy if the original path is invalidated.” How such local policy is expressed/configured? This also applies to the 1st paragraph in section 4.2. - Section 3.3. I think it is not clear the behavior for all the possible combinations. This is my understanding: --- P=0 | F=0 – recomputation MAY be possible if the original path is invalidated when there is a local policy allowing that (as described for P) or if there is an explicit request from the operator (as described for F) --- P=0 | F=1 – despite the fact that recomputation MAY be possible if the original path is invalidated, the PCE MUST NOT update the path (unless any exception described in Section 4.2 applies) --- P=1 | F=0 - the PCE MUST NOT recompute path even if the current path does not satisfy path computation constraints, but the PCE can update the path towards the PCC. --- P=1 | F=1 - the PCE MUST NOT recompute path even if the current path does not satisfy path computation constraints, and the PCE MUST NOT update the path (only tear it down or bring it up again, according to description in Section 4.2). Please, confirm if this is correct, otherwise clarify the text for a good understanding of the behavior. - Section 4.1. It states: “PCC MAY set the O flag in LSP-EXTENDED-FLAG TLV in a PCRpt message sent to the PCE to indicate that a path exclusively made of strict hops is required.” Is it actually MAY the proper work here? Should not it be MUST? I mean, for indicating that a path exclusively made of strict hops is required, it is required that the PCC signal it (i.e., not to be a possibility, but a fact). - Section 4.1. Regarding “For example, Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if there is only one adjacency).” Would it not be more precise and concise refer to “Only Adjacency SIDs MUST be used (even if there is only one adjacency)”? - Section 4.2. It states: “PCC MAY set flags in PATH-RECOMPUTATION TLV to control path computation behavior on the PCE side.” Is the usage of MAY correct here? I mean, it seems that not including the PATH-RECOMPUTATION TLV is equivalent to including it with P=0 | F=0 (default behavior). For efficiency, it would be maybe better to include PATH-RECOMPUTATION TLV only of either P or F or both are set. - Section 4.2. Not clear the implications of “The LSP path MAY be modified if forwarded packets will still use the same path”. What are the reasons for that in the context of this section? The paragraph refers to the support of PATH-RECOMPUTATION TLV by PCEP speakers, not about any issue in the LSP. - Section 5.2: “Section 4.2 of [RFC9826] module should be extended to add notification for blocked recomputation ”. Is it here should or SHOULD? - Section 7. It is already mentioned in Section 3.3 that “Only the first instance of this TLV MUST be processed, subsequent instances MUST be ignored.” Thinking on security considerations it could be the case that distinct instances of PATH-RECOMPUTATION TLV have different flag settings. So maybe it could be good to reinforce on the security part the fact that subsequent instances MUST be ignored so to prevent attacks in this sense. Just in case. ## Editorial - Abstract: s / ”They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation” / ”They include the ability to control path recomputation and the option to request path with strict hops only, being also applicable for generic SR policy use cases where controlling path recomputation” - Terminology: there is no reference to Circuit Style. For completeness, since it is the focus of the draft, it would be convenient to either define here or to point out to any other document where Circuit Style is defined. ---
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
