Thanks Samuel. Looks good to me. Dhruv (as shepherding co-chair), would you like to check/poll the WG that these updates are good to go or can I start the IETF LC already?
Thanks, Ketan On Fri, Feb 6, 2026 at 2:40 PM Samuel Sidor (ssidor) <[email protected]> wrote: > Thanks Ketan, > > Updated version 13 submitted. > > Regards, > Samuel > > *From: *Ketan Talaulikar <[email protected]> > *Date: *Wednesday, 4 February 2026 at 16:36 > *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, > > Please check inline below with KT2. > > > On Wed, Feb 4, 2026 at 3:51 PM Samuel Sidor (ssidor) <[email protected]> > wrote: > > 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]> > 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). > > > KT2> That is not the clarification which I was referring to - that part is > pretty clear already. The clarification which would be helpful is that > RFC5440 does provide the strict/loose indication for RSVP-TE but does not > cover stateful PCEP which is what this document brings. Again, I will leave > it to the authors if you think it could cause more confusion than help. > > > > 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"? > > > KT2> Yes, that works. I still don't like those 2 flags getting tied up the > way they are today - please see further responses. > > > > 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. > > > KT2> That is exactly what I meant when I said that the P flag is 'don't > care' when the F flag is set to 1. I thought that "for any reason > whatsoever" would be clear enough to indicate that it covers the scenarios > of the P flag. If that is not clear, just add that the P flag is ignored if > the F flag is set. > > > > 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. > > > KT2> Exactly, there is no value and it is contradictory and confusing. > This was my original point. The changes discussed above should eliminate > this need to cover P and F flags as combinations. And, likely there isn't a > need to complicate by treating the setting of P flag along with F flag as > an error condition - i.e., it is not an error if it is ignored? > > Thanks, > Ketan > > > > 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]
