Hi Samuel, On Thu, Oct 30, 2025 at 10:09 AM Samuel Sidor (ssidor) <[email protected]> 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 <[email protected]> > *Date: *Thursday, 30 October 2025 at 10:40 > *To: *Samuel Sidor (ssidor) <[email protected]> > *Cc: *[email protected] <[email protected]>, > [email protected] < > [email protected]> > *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 > >
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
