Thanks a lot Dhruv for review and comments, Please find inline responses marked with <S> for some of them (rest of them are clear and I’ll update the draft based on those).
Regards, Samuel From: Dhruv Dhody <[email protected]> Date: Thursday, 30 October 2025 at 08:47 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: Shepherd Review of draft-ietf-pce-circuit-style-pcep-extensions Hi Authors, I have done the Shepherd review of the I-D. Once the update is posted, I will send this to the AD. # Shepherd Review of draft-ietf-pce-circuit-style-pcep-extensions ## Minor - Abstract uses the term "distinct hop requirements" where the term is not used anywhere in this or SPRING document. - In "[RFC8664] introduces the concept of Segment Routing Policy (SR Policy)" - this should be RFC 9256. If you want to talk about RFC 8664, say that it introduces SR to PCEP. - Section 2, also add SR terms like SR Policy, SID etc - Section 3, directly jumps to extension. It would benefit from some initial summary text before all the details, example - ```` This section specifies the PCEP extensions that enable a PCC and PCE to support Circuit-Style (CS) SR policies. These extensions build on the base PCEP [RFC5440], the Stateful PCE extensions [RFC8231], and the Segment Routing (SR) Policy extensions [RFC9603]. The mechanisms defined here allow a PCC or PCE to: * indicate the requirement for strict paths, * signal path persistency by disabling recomputation for specific paths, * identify and control behavior specific to Circuit-Style SR policies. Unless explicitly stated, the procedures of existing PCEP messages and objects remain unchanged. The following subsections describe the specific object formats, TLVs, and flag definitions introduced to realize this functionality. ```` - Figure 1, shift the numbers 0,1,2... to right by 1 space, they need to correspond to - and not + - Section 3.3, this text - "If this flag is cleared, then the PCE SHOULD recompute the path if the original path is invalidated."; can we add 'according to local policy' as we use in other PCE RFC? Also in section 4.2, you use MAY for this flag, be consistent. - Section 4.1, no need to use BCP14's MAY in "Existing O flag in RP object MAY be used to indicate similar behavior in PCReq and PCRep messages as described in as described in Section 7.4.1 of [RFC5440]." as this is about existing behavior. Further "If the O flag is set to 1 for both stateful and stateless messages for SR paths introduced in [RFC8664]...", this is unclear to me. Why both..and? Suppose the O flag in RP was not set during PCReq but set in PCRpt in TLV would the PCE not process it? <S> I will also fix typo in 1st statement in the comment “as described in as described”. For “both” - it was meant in a way that if O flag is set in any of them. I’ll update statement to make it clear. - Section 4.2, "The presence of the TLV blocks path recomputation.." is conflicting with Section 3.3 "the PCE MUST NOT recompute the path in cases specified by flags.." - I think flags need to be set to block recomputation and it should not be just the presence of the TLV. <S> Intended state is: * TLV included with no flag set -> re-computation is allowed if original path is invalidated or if operator explicitly requested it -> blocked otherwise (e.g. PCE cannot re-compute if better path exists, but original one is still valid) * TLV included with P flag set -> re-computation is not allowed even if path is invalidated * TLV included with F flag set -> re-computation triggered by operator is not also not allowed Will it be more clear if statement in section 3.3 is updated to something like: “If this TLV is included in the LSPA object, the PCE MUST limit path recomputation for the LSP as specified by the flags in this TLV and the procedures in Section 4.2." - Section 4.2, "For example, if the same path can be encoded using Adjacency, Binding, Prefix, or other SIDs, then PCE MAY switch between various representations of the same path", the use of MAY inside a sentence that starts for example, is not ideal. <S> I’ll drop “For example”. - Section 4.2, "The only exception is an explicit request from the operator to recompute the path." it would be clearer to explicitly state how operator request recomputation. <S> I can add something like: “The mechanism for an operator to trigger such a request (e.g., via a Command-Line Interface (CLI) or a northbound API on the PCE) is implementation-specific and outside the scope of this document.” - Section 4.2, do we need error handling in case the flags are set but PCE still tries to recompute/update a new path? <S> Sure, I can add something like this to section 4.2 and define new PCError in IANA section: “A PCC that receives a PCUpd message with a modified path for an LSP, where such an update is blocked by flags in the PATH-RECOMPUTATION TLV (e.g., the F flag is set), it MUST reject the update and maintain the existing path for the LSP. The PCC MUST also send a PCErr message to the PCE with Error-Type=19 ("Invalid Operation") and a new Error-Value, "Path update is blocked by recomputation constraint”." ## Nits - s/This document proposes a set of extensions/This document specifies a set of extensions/ - s/[RFC8664] introduces the concept of Segment Routing Policy (SR Policy) Thanks! Dhruv
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
