Thanks Ketan, Please check responses inline <S2>.
Regards, Samuel From: Ketan Talaulikar <[email protected]> Date: Tuesday, 3 February 2026 at 17:19 To: Samuel Sidor (ssidor) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: AD review of draft-ietf-pce-circuit-style-pcep-extensions-12 Hi Samuel, Thanks for sharing the updated version which addresses all the comments except for the two below. Please check inline below for responses. I think we are ready except for one outstanding discussion. On Mon, Feb 2, 2026 at 4:32 PM Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> wrote: Thanks a lot, Ketan for your review and comments, Picked 2 specific comments - rest of them should be already fixed in updated version (attached) - but feel free to let me know if any of them still requires discussion or additional changes. <major> Aren't all RSVP-TE paths that are computed by the PCE provided to the PCC in the hop-by-hop manner (i.e., "strict" as per this document)? Can/does the PCE provide "loose" EROs - I was not sure? I am trying to check if this loose/strict flag is applicable to the RSVP-TE (or other non-SR) path setup types. <S>There is loose flag and there was also already strict/loose flag added as part of RFC5440 for stateless PCEP for RSVP-TE, but there was no flag for stateful PCEP messages. See for example: " O (strict/loose - 1 bit)" in: https://datatracker.ietf.org/doc/html/rfc5440#section-7.4.1 So new flag is applicable to RSVP-TE as well. KT> Thanks for that clarification. Please consider adding this clarification so others might see the equivalence between these flags for RSVP-TE. <S2> We are already describing existing flag in section 4.1, but I can add some new statement to explicitly state that it is applicable to existing setup types (including RSVP-TE). 336 Default Behavior (TLV present, P=0, F=0): <major> Aren't all these behaviors only when the TLV is present? I don't believe we are trying to change the "base" behaviors. Also, I would like to confirm what is meant by "default" here. Is it the recommended behavior? An even bigger concern is how this specification is to be extended when more flags are introduced in the future. Is it not possible to specify each flag independently - this would make it simpler to extend with introduction of more flags. <S> Regarding the scope of the behavior: Yes, these definitions apply only when the TLV is present. The behavior when the TLV is absent is explicitly defined at the beginning of the section ("If the PATH-MODIFICATION TLV is not included..."). We use the term "Default Behavior" here to set the baseline behavior when the TLV is included but all flags are unset (P=0, F=0). That provides a reference point for how the specific flags modify/restrict that baseline behavior. KT> "Default behavior" is a recommendation for this setting to be used. I don't believe that is the case here since the choice of the flags are entirely dependent on the operator's desire for a particular LSP. So, can you please not use that term? <S2> What about just changing "Default Behavior (TLV present, P=0, F=0):" to "TLV present, P=0, F=0:", without using "Default Behavior"? Regarding the structure and extensibility: In previous versions (https://www.ietf.org/archive/id/draft-ietf-pce-circuit-style-pcep-extensions-10.html#name-path-recomputation), we did specify each flag independently. The draft reviews highlighted that the interaction between the 'Permanent' (P) and 'Force' (F) flags was ambiguous and reviewers recommended to rather define all combinations. While we initially shared the concern about listing combinations and we tried to avoid it, the decision based on discussions with reviewers and authors was that it will be cleaner if we all combinations are specified. KT> I am guessing this was coming from the OPSDIR review but please correct me and point to any thread if I've got it wrong. This approach of creating interdependencies between flag and building combinations becomes very complex and difficult to follow/maintain in the future. Best design is to keep it modular and easy to extend. In this case, I can see how the text in v10 actually gave rise to dependency between the two flags where there isn't one. Can I suggest the following? Please also see the next response. Permanent Flag (P=1): The PCE MUST NOT recompute the path due to a topology trigger or on its own (e.g., due to periodic reoptimization) even if the path becomes invalidated. The operator can, however, trigger a recomputation of the path. Force Flag (F=1): The PCE MUST NOT update the path for any reason whatsoever including in response to a trigger from the operator. The only path updates a PCE can initiate are to tear down the LSP (e.g., by sending an PCUpd message with an empty ERO) or to bring it up again with the same path it had before being torn down. <S2> I believe that same comment as received originally for v10 applies to you proposed text. F=1 is really defined only for case P=1 F=1 (where P flag is blocking some set of triggers and F=1 is blocking trigger from the operator on top), but P=0 F=1 is practically undefined (even if it logically does not make sense). Or is your intention that F flag is overriding P flag and value of P flag is not important as soon as F flag is set? If that is the case, then we can make it explicit in the draft. For future extensibility, this structure does not preclude independent flags. If a new flag is orthogonal to P and F, it can be defined independently. If a new flag interacts with them, explicit clarification would be necessary regardless of the structure chosen and it can be still simplified in same way (e.g. specify just combination with specific flag and not with all of them). KT> I don't see the P and F flags to be interdependent. Basically, the P flag is "don't care" if the F flag is set to 1 - that makes sense to me. What I don't get is the thought process behind the following combination: P=0, F=1: The PCE MUST NOT modify the path in response to an explicit operator trigger. However, the PCE MAY modify the path if the current path becomes invalidated. Why is PCE allowed to trigger change for something when an operator cannot trigger? Isn't the operator the ultimate (human) decision maker? At least that is what I takeaway from reading https://www.ietf.org/archive/id/draft-ietf-spring-cs-sr-policy-14.html#section-10.1.2 <S2> I personally also don't see big added value in that combination in real world, but we wanted to fill the gap in definition since it was originally not defined at all. Alternative solution may be also in disabling that combination completely and reject with PCErr if somebody will try to use it (but then we will not be able to avoid specifying behavior explicitly for at least that specific combination - P=0, F=1) or we can specify that value if P flag is not important as soon as F=1 is specified. Thanks, Ketan Regards, Samuel From: Samuel Sidor (ssidor) <[email protected]<mailto:[email protected]>> Date: Tuesday, 27 January 2026 at 14:27 To: Ketan Talaulikar <[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]>> Subject: Re: AD review of draft-ietf-pce-circuit-style-pcep-extensions-12 Thanks a lot for your review, Ketan. I’m working on your comments and I’ll get in next few days. Regards, Samuel From: Ketan Talaulikar <[email protected]<mailto:[email protected]>> Date: Friday, 23 January 2026 at 14:05 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: AD review of draft-ietf-pce-circuit-style-pcep-extensions-12 Hello Authors/WG, Please find below my review of the document. The comments and suggestions are inline in the idnits output of v12 of the draft. I would appreciate inline responses and please feel free to share diffs (or github PR pointer) of the proposed changes so we can converge faster. Thanks, Ketan PS: Please look for the tag <EoRv12> at the end to ensure you have got the complete review email. 22 to the utilization of source routing. An SR Policy can consist of 23 one or a set of candidate paths, where each candidate path is 24 represented by a segment list or a set of segment lists, which are 25 essentially instructions that define a source-routed policy. <minor> s/source-routed policy/source-routed path ? 30 transport services (Circuit-Style SR policies). They include the 31 ability to control path modification and the option to request path <nit> s/request path/request a path 101 1. Introduction 103 Segment Routing (SR) leverages the source routing paradigm, where the <minor> Please add reference to RFC8402 119 steer traffic through a network. Each candidate path is represented 120 by a segment ist or a set of segment lists, and the path can be <nit> s/ist/list 123 In connection-oriented transport services, such as those defined in <minor> s/defined in/described in 129 To support the requirements of connection-oriented transport 130 services, this document specifies extensions to PCEP to enable the 131 use of Circuit Style Policies. These extensions allow for the <minor> s/use of Circuit Style Policies./use of Circuit Style Policies [I-D.ietf-spring-cs-sr-policy]. 136 The PCEP extensions described in this document are designed to be 137 compatible with any Path Setup Type and are not limited to Circuit 138 Style SR policies, ensuring broad applicability across different 139 network environments and use cases. <major> Aren't all RSVP-TE paths that are computed by the PCE provided to the PCC in the hop-by-hop manner (i.e., "strict" as per this document)? Can/does the PCE provide "loose" EROs - I was not sure? I am trying to check if this loose/strict flag is applicable to the RSVP-TE (or other non-SR) path setup types. 149 2. Terminology 151 This document uses the following term defined in [RFC3031]: 153 * Label Switched Path (LSP) <major> Please add a note along the lines below (borrowed from RFC9862) right after the LSP term to proactively address comments expected during IESG Evaluation. "Note: The base PCEP specification [RFC4655] originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. Over time, support for additional path setup types such as SRv6 has been introduced [RFC9603]. The term "LSP" is used extensively in PCEP specifications, and in the context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented using the LSP object as specified in [RFC8231])." 181 This document uses the following term defined in 182 [I-D.ietf-spring-cs-sr-policy]: 184 * Circuit Style (CS) SR Policy <minor> s/defined in/described in 195 3. Overview of Extensions to PCEP <minor> s/Overview of Extensions/PCEP Extensions 198 to support CS SR policies. These extensions build on the base PCEP 199 [RFC5440], the Stateful PCE extensions [RFC8231], and the Segment 200 Routing (SR) Policy extensions [RFC9256]. The mechanisms defined <major> I am not sure if this is building on RFC9256. Isn't it generic? If so, please remove that RFC and its reference from the above sentence. 233 This document specifies new Strict-Path flag in the LSP-EXTENDED-FLAG <nit> s/specifies new/specifies the new 244 The PATH-MODIFICATION TLV is optional. If the TLV is included in 245 LSPA object, the PCE MUST NOT modify the path in cases specified by <nit> s/in cases/in the cases 249 0 1 2 3 250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type = 72 | Length = 4 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Reserved | Flags |P|F| 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 1: PATH-MODIFICATION TLV Format <nit> Please fix the error in the field separator in the figure at the two octet boundary - it is off by a space. 287 message sent to the PCE. It MUST NOT be set to 1 if one or both PCEP <minor> I assume when you say "set", it means "set to 1" and when you say "clear" it means "set to 0". Either just says "set" or "clear" or specify what value is being set in both operations consistently throughout the document. 288 speakers have not set the STRICT-PATH-CAPABILITY flag to 1 in the 289 STATEFUL-PCE-CAPABILITY TLV. If the PCEP peer received LSP-EXTENDED- <major> How about first describing the capability part and how it is set by both PCC/PCE and then moving on to the LSP flag? Also, not sure what is meant by "one or both PCEP speakers"? Can the flag be set in the LSP unless both PCE and PCC support the capability? 293 The O flag cleared or LSP-EXTENDED-FLAG TLV not included indicates 294 that a loose path is acceptable. <minor> I see the term "loose" is used only in this one place. Can it be instead replaced as below for more clarity (or something like that?): s/a loose path/a non-strictly hop-by-hop path Also, please consider if instead of using just "strict" we can use "strict hop-by-hop" or something like that. It is ok to keep just the 'strict' in the flag names - my point was only about the descriptive text. I am aware that these terms (strict/loose) have been around for ages, so just checking if the suggested change would improve clarity or not. 296 In PCUpd or PCInitiate messages, PCE MAY set O bit if the strict path 297 is provided. <major> The semantics above are not clear to me. What is the PCC supposed to do with this information - can it rely on it to be set accurately? Is it only relevant when the PCC is delegating with O bit set and then the PCE MUST also set it in the PCUpd to confirm back to the PCC? Is it 'don't care' in a PCInitiate? Can we tighten this up? 299 The flag is applicable only for stateful messages. Existing O flag 300 in Request Parameters (RP) object may be used to indicate similar <minor> Perhaps s/may/can ? 308 forwarding. For example, Adjacency SIDs SHOULD be used, but Prefix 309 SIDs MUST NOT be used (even if there is only one adjacency). <major> Can we remove "For example,"? Avoid using examples for conveying normative behavior. Examples are only meant to be illustrative. 321 PCErr with Error-Type = 2 (Capability not supported). The LSP path 322 MAY be modified, if the change results in a semantically equivalent 323 path representation (e.g., a different SID list) that preserves the 324 exact sequence of traversed network hops. If the same path can be <major> So, it is ok to traverse the same hops but not the same links? I got the impression that we need to stick to the same links... 336 Default Behavior (TLV present, P=0, F=0): <major> Aren't all these behaviors only when the TLV is present? I don't believe we are trying to change the "base" behaviors. Also, I would like to confirm what is meant by "default" here. Is it the recommended behavior? An even bigger concern is how this specification is to be extended when more flags are introduced in the future. Is it not possible to specify each flag independently - this would make it simpler to extend with introduction of more flags. 337 The PCE MUST NOT modify the path in response to various triggers 338 (E.g. topology updates, periodic reoptimization timers, or changes 339 in the state of other LSPs) if the current path remains valid and 340 meets all constraints. However, the PCE MAY modify the path if: <major> You mean "meets all constraints" but "may no longer be following the best optimization objective"? i.e., there may be a shorter delay path due to a topology change but the PCE will not change the path. Is my understanding correct? Can this be clarified? 366 A PCE MAY include the PATH-MODIFICATION TLV in PCInitiate and PCUpd <minor> s/MAY/can or may ... or better still "A PCE includes ..." 388 5.1. Control of Function and Policy 390 A PCE or PCC implementation MAY allow the capability of supporting 391 PCEP extensions introduced in this document to be enabled/disabled as 392 part of the global configuration. <major> Should that "MAY" be either a "SHOULD/MUST" ? 394 5.2. Information and Data Models 396 An implementation SHOULD allow an operator to view the PCEP peer 397 capability defined in this document. Section 4.1 and 4.1.1 of 398 [RFC9826] should be extended to include that capability for PCEP 399 peer. <major> The P & F flags indicate a strong requirement on the PCE (a SHOULD if not a MUST) to provide the ability to trigger the reopt of the LSP? 406 5.3. Liveness Detection and Monitoring 408 Circuit-Style Policy draft [I-D.ietf-spring-cs-sr-policy] is already 409 describing connectivity verification and path validity considerations 410 for Circuit Style Policies. <nit> s/is already describing/describes 419 5.5. Requirements On Other Protocols 421 The PCEP extensions defined in this document do not imply any new 422 requirements on other protocols. The overall concept of Circuit 423 Style policies requires interaction with other protocols, but those 424 requirements are already described in [I-D.ietf-spring-cs-sr-policy]. <nit> s/already described/described 511 Note to IANA: This document renames "PATH-RECOMPUTATION-CAPABILITY" 512 (Bit 19) to "PATH-MODIFICATION-CAPABILITY". <minor> You mean this renaming is between the older and the latest versions of this document? Such notes are not really needed as IANA will do this after the document is approved (after confirming with authors). 546 8.4. PATH-MODIFICATION TLV Flag Field 548 IANA has created a new registry named "PATH-MODIFICATION TLV Flag <major> I believe IANA is requested to create a new registry at this stage? 549 Field" within the "Path Computation Element Protocol (PCEP) Numbers" 550 registry group. New values are to be assigned by "IETF Review" <minor> s/New values/Values 679 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 680 Decraene, B., Litkowski, S., and R. Shakir, "Segment 681 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 682 July 2018, <https://www.rfc-editor.org/info/rfc8402>. <major> This becomes a normative reference <EoRv12>
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
