Hi All, I've issued the IETF LC on this document after checking offline with Dhruv.
If there are any issues or further updates/tweaks needed, do bring them up during this IETF LC period as well and request the authors to address them. Thanks, Ketan On Fri, Feb 6, 2026 at 3:08 PM Ketan Talaulikar <[email protected]> wrote: > 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]
