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

[Dhruv Dhody <[e-mail]>]

Hi Samuel,

On Thu, Oct 30, 2025 at 10:09 AM Samuel Sidor (ssidor) <[e-mail]>
wrote:

> 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)?
>
>
Yes! I like it, just make it clear what happens when P=0, F=0 as well!

Thanks!
Dhruv



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