[Pce] Re: Shepherd Review of draft-ietf-pce-circuit-style-pcep-extensions

["Samuel Sidor (ssidor)" <[e-mail]>]

Hi Dhruv,

For “Dhruv: Yes! How about add an additional table to make it extra clear and readable (only a minor suggestion) “.

I void like to avoid having table (especially if it is supposed to have all combinations to make sure that we will not end up  listing all combinations in the future if more flags will be added), but I can still try to change that section 4.2 to make it more structured, e.g. by converting to bullets, what about something like this:

…
The PATH-RECOMPUTATION TLV defines the recomputation behavior for an LSP based on a default rule that can be further restricted by the P and F flags, as follows:

  *
Default Behavior (TLV present, no flags set): The PCE MUST NOT recompute the path in response to various triggers if the current path remains valid and meets all constraints (E.g. topology updates, periodic reoptimization timers, or changes in the state of other LSPs). However, the PCE MAY recompute the path if:

  *
The current path is invalidated (e.g., due to a topology change that makes it non-compliant with LSP constraints).
  *
An operator explicitly triggers a recomputation via an implementation-specific mechanism (e.g., a CLI or northbound API on the PCE).
  *
Permanent Flag (P=1): The PCE MUST NOT recompute the path even if it becomes invalidated. An operator-triggered recomputation is still permitted unless restricted by the F flag.


  *
Force Flag (F=1): The PCE MUST NOT update the path even if an operator explicitly triggers it. When this flag is set, the only path updates a PCE can initiate are to tear down the LSP (e.g., by sending a PCUpd message with an empty ERO) or to bring it up again with the same path it had before being torn down.

Is that better (I still may need to re-check if I included everything from original text)?

Thanks,
Samuel

From: Dhruv Dhody <[e-mail]>
Date: Thursday, 30 October 2025 at 10:40
To: Samuel Sidor (ssidor) <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Shepherd Review of draft-ietf-pce-circuit-style-pcep-extensions

Hi Samuel,

Thanks for a fast response.


<snip>

- 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.


Dhruv: Thanks for spotting the additional typo :)


- 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."


Dhruv: Yes! How about add an additional table to make it extra clear and readable (only a minor suggestion)

- 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”.


Dhruv: Ack


- 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.”


Dhruv: works for me.


- 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”."


Dhruv: Ack

Thanks!
Dhruv