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]> 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. > > 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? > > 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. > > 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 Thanks, Ketan > Regards, > Samuel > > > *From: *Samuel Sidor (ssidor) <[email protected]> > *Date: *Tuesday, 27 January 2026 at 14:27 > *To: *Ketan Talaulikar <[email protected]>, > [email protected] < > [email protected]> > *Cc: *[email protected] <[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]> > *Date: *Friday, 23 January 2026 at 14:05 > *To: *[email protected] < > [email protected]> > *Cc: *[email protected] <[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]
