Hi Luis, Sorry for delayed response.
Please find my responses inline, marked with <S>. Thanks, Samuel From: Samuel Sidor (ssidor) <[email protected]> Date: Tuesday, 18 November 2025 at 15:53 To: LUIS MIGUEL CONTRERAS MURILLO <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [Pce] Re: draft-ietf-pce-circuit-style-pcep-extensions-10 early Opsdir review 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. <S> local-policy -> implementation specific behavior. See for example “local policy” in base PCEP RFCs, e.g. https://datatracker.ietf.org/doc/html/rfc8231 So intention is not to define whether implementation should/should not allow operator to specify what should happen - note that is same as current behavior before this draft was written. - 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. <S> Thanks for great summary. Your understanding is almost correct with 2 small comments: 1. “P=0 | F=1” -> Original intention was to allow update if path is invalidated, but do not allow operator triggered update, but I agree that text is not clear, so I’ll try to update it. 2. “P=1 | F=0” -> Your explanation is correct, but update is allowed if triggered by operator (as already specified in section 4.2 - statement “An operator-triggered recomputation is still permitted unless restricted by the F flag.”) - 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). <S>Are you fine with following statement? It may be better that specifying it as a MUST requirement: “To indicate that a path exclusively made of strict hops is required, the PCC sets the O flag in the LSP-EXTENDED-FLAG TLV in a PCRpt message sent to the PCE. - 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)”? <S>”For example” is used, because we are intentionally not describing behavior for all SID types (e.g. BSID is allowed as well) to also make it future proof. There is statement “the PCE MUST use only Segment Identifiers (SIDs) that explicitly specify adjacencies for packet forwarding” just before one you quoted, which is enforcing behavior already. - 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. <S> P=0 | F=0 is not same as not including TLV. * If TLV is not included, PCE is behaving based on local policy (existing behavior), so it can re-compute any time - e.g. if path is not optimal * If P=0 | F=0, -> PCE MUST NOT re-compute if current path is valid and satisfying constraints. This is described in existing statement in section 4.2: The PCE MUST NOT recompute the path in response to various triggers if the current path remains valid and meets all constraints (E.g. topology updates, periodic reoptimization timers, or changes in the state of other LSPs). - 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. <S> The intention of this statement is to clarify that even when path recomputation is forbidden, modifications to the representation of the path are allowed as long as they do not change the effective forwarding path that packets will traverse. For example, a PCE might perform: * Path Normalization: Replacing a single SID with an equivalent sequence of SIDs that results in the same physical router. * SID Substitution: Swapping one type of SID for another (e.g., an Adjacency SID for a Node SID) that still forwards traffic over the exactly same link. What about changing that statement to: “The LSP path MAY be modified, if the change results in a semantically equivalent path representation (e.g., a different SID list) that preserves the exact sequence of traversed network hops." - Section 5.2: “Section 4.2 of [RFC9826] module should be extended to add notification for blocked recomputation ”. Is it here should or SHOULD? <S> Sure, I can change it. - 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. <S> If attacker can update PCEP messages between PCC and PCE, then they have significantly simpler ways to attach available - for example changing endpoints of LSP and move traffic to completely different destination. That’s why we are already recommending encryption in section 7. In this case, it would have to be combination of implementation which is not complaint with this draft already (not following MUST statement in section 3.3) and not following recommendation from section 7, so I’m not sure if any reinforcement would help in such 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” <S> Thanks, I’ll update it. - 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. <S> We have reference to Circuit-Style policy in Introduction section and reference to “I-D.ietf-spring-cs-sr-policy”, but I can add it to Terminology as well. ---
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
