Hi Samuel, Thanks so much for the updates. All are Ok for me.
Just one nit in section 3.3: s/"The PATH-RECOMPUTATION TLV optional."/ "The PATH-RECOMPUTATION TLV is optional." Thanks again, Best regards Luis De: Samuel Sidor (ssidor) <[email protected]> Enviado el: viernes, 28 de noviembre de 2025 9:47 Para: LUIS MIGUEL CONTRERAS MURILLO <[email protected]>; Samuel Sidor (ssidor) <[email protected]> CC: [email protected]; [email protected]; [email protected] Asunto: Re: draft-ietf-pce-circuit-style-pcep-extensions-10 early Opsdir review AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Luis, Please check updated version in attachments. In section 3.3 - I modified it to describe all combinations of flags. In section 5.2 - I updated "should" -> "SHOULD", but I'm also not sure, which one is correct in that case, so I'll discuss that with other co-authors. Thanks, Samuel From: LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>> Date: Wednesday, 26 November 2025 at 16:52 To: Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>>, Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: draft-ietf-pce-circuit-style-pcep-extensions-10 early Opsdir review Hi Samuel, Thanks for your clarifications. Please, see my response in-line (marked with lmcm). Thanks Luis De: Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> Enviado el: miércoles, 26 de noviembre de 2025 11:36 Para: Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>>; LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>> CC: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Asunto: Re: draft-ietf-pce-circuit-style-pcep-extensions-10 early Opsdir review AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Luis, Sorry for delayed response. Please find my responses inline, marked with <S>. Thanks, Samuel From: Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> Date: Tuesday, 18 November 2025 at 15:53 To: LUIS MIGUEL CONTRERAS MURILLO <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[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]<mailto:[email protected]>> Date: Monday, 17 November 2025 at 11:14 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[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. [lmcm>>] Ok, clear. - 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.") [lmcm>>] I think it is good if you can clarify these points, thanks. - 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. [lmcm>>] ok to me, thanks. - 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. [lmcm>>] Ok, clear. - 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). [lmcm>>] ok, clear - 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." [lmcm>>] thanks, I think is better in this way so that more clarification is provided. - 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. [lmcm>>] ok, but note that my question was for understanding if "should" was written as such and not with capital letters intentionally. Please, ensure the proper form is the final one. - 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. [lmcm>>] ok, clear. You are totally right that there would be more serious attacks in that 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. [lmcm>>] ok - 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. [lmcm>>] ok, but maybe for completeness it could be worthy add it in terminology. --- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
