[Pce] Re: Shepherd review of draft-ietf-pce-state-sync

[Dhruv Dhody <[e-mail]>]

Hi All,

Thanks for the update in -14, I have a few comments for the authors to
consider...

On Fri, Mar 27, 2026 at 1:57 AM Andrew Stone (Nokia) <[e-mail]>
wrote:

> Hi Authors,
>
> Dhruv has asked that I take over Shepherd for this document as Dhruv is
> listed as a contributor. Thanks to Dhruv for the previous review, and to
> the authors for addressing  the previous comments which are applied in the
> latest -13 version.
>
> While re-reading the (-13) document thoroughly again to fill in the
> shepherd report, I stumbled upon items that I did not notice before.
> Apologies that I did not realize and raise this during the WGLC poll which
> I supported, as they did not become apparent to me until reading yet-again.
>
> Majority of this email content is editorial suggestions and do not change
> the content and are simply a recommendation. However, there are two topics
> (A, B) that I think need to be clarified in the functional section below. I
> don’t have content suggestions for them as I’m unclear about them.
>
>  I have the Shepherd writeup prepared to submit but will hold until a
> reply regarding the two functional items to discuss below but will not hold
> for the editorial items.
>
> Thank you!
> Andrew
>
>
>
> -------------------
> Functional
> -------------------
>
> Topic A: Section 3.5 (snippet below). what is the definition of "is
> failing" in this context? examples? Does this imply a degradation but still
> operationally connected? Flapping? PCE Overload bit received via
> Notification Object? It seems to also imply the PCC is aware that the local
> pce and highest priority pce has failed, how? and how does it actually
> signal to cause a switch over to the next highest priority PCE for the
> group if the group might be amongst multiple LSP headends? it does mention
> local policy decision, but I don't follow the mechanics for how it knows it
> needs to do something (definition of failing), especially if it's an issue
> between PCE1<->PCE2, and what action (msg) it sends.  According to text
> before this, PCC also has no need for priority awareness.  Appreciate
> clarity on this paragraph.
>
>
> *   If the highest priority PCE is failing or if the state-sync session
> between the local PCE and the highest priority PCE failed, the PCC MAY
> decide to instruct a switch-over to delegate the LSP to the next highest
> priority PCE or to take back control of the LSP. It is a local policy
> decision.*
>
>
>
Dhruv: I like the general direction in the update at
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-state-sync-13&url2=draft-ietf-pce-state-sync-14&difftype=--html
but it also made me wonder if we can avoid the term "is failing," as this
is not something we used in PCEP RFCs before (we simply used failure). Why
introduce a new term specific to state-sync only?



>
> Topic B:  Section 3.5 - what is the reason to send PcUpd to all state-sync
> sessions and not just the session in which it received the delegation or
> sub-delegation from?  To make the other PCEs aware of this inflight
> make-before break? What should the other state-sync sessions do with the
> PcUpd msg when it's not connected to the underlying PCC? Drop it? Remember
> it? my guess is: when the PCC receives the PcRpt, it will ack back to the
> PCE it received it from with the SRP-ID. That PcRpt+SRP-ID is echo'd to all
> PCEs, thus some benefit the other state sync sessions should know about the
> PcUpd. However, there appears to be a race condition risk here. Let’s
> assume PCC1 delegated to PCE1 directly. It could be possible the
> PCE1<->PCE2 communication is busy, meanwhile the PCC<->PCE1 and PCC<->PCE2
> is quiet. PCE2 could receive the PcRpt with SRPID before PCE2 learns about
> the PcUpd. It leads me to wonder exactly what is the value of PCE2 learning
> of the PcUpd if this risk exists?
>
>
> *When a PCE has the delegation for an LSP and needs to update this LSP, it
> MUST send a Path Compute Update (PCUpd) message to all state-sync sessions
> and to the PCC session on which it received the delegation.*
>
>
>
>
Dhruv: I agree with reason provided "Sending PCUpd to all state-sync
sessions keeps all PCEs aligned on in-flight control actions and avoids
transient state divergence during re-optimization" but the section 3.5
conditions PCC-side forwarding solely on the presence of an active PCEP
session ("MUST NOT forward a PCUpd to a PCC unless it has an active PCEP
session to that PCC"). This is inconsistent with RFC 8231. Per RFC 8231, an
LSP is controlled by a single PCE, and only the PCE holding the delegation
may send a PCUpd for it; a PCUpd for a non-delegated LSP MUST be rejected
by the PCC. The normative condition should therefore be delegation
ownership, e.g. "A PCE must not send a PCUpd to a PCC for an LSP unless it
currently holds the delegation for that LSP on an active PCEP session to
that PCC." The session check alone wrongly implies any session-holding PCE
may forward.

Thanks!
Dhruv


>
>
> -------------------
> Editorial
> -------------------
>
> - Section 1.2: What is "this" delay in this context? Is it the delay for
> the PCC to notify a PCE in general regardless of multi-pce deployment? or
> the delay for PCC to notify PCE2 because it's currently busy notifying PCE1
> and can't concurrently do so? Or the delay for PCE1 and PCE2 to come to the
> same eventually consistent converged state?  I think the text may benefit
> from clarifying which delay is under consideration/concern here.
> Considering the next paragraph my understanding is it's about converged
> state, so perhaps the proposed text instead?
>
>     Original: "This delay may affect the reaction time of the other PCEs
> if they need to take action after being notified of the LSP parameter
> change."
>     Proposed: "This convergence delay may hinder the reaction time of
> other PCEs that must take action after being notified of the LSP parameter
> change."
>
>
> - Section 1.2: Minor nit to avoid confusion with the PCEP "Update" message.
>
>     Original: "...PCC1 reporting the update of LSP1 to PCE2"
>     Proposed: "...PCC1 reporting the state of LSP1 to PCE2"
>
>
> -Section 1.3 Might be worth clearly saying LSP1 is on PCC1 and LSP2 is on
> PCC2.
>
>     Original: "In the example in Figure 2, we consider that by
> configuration, both PCCs will first delegate their LSPs to PCE1. So, PCE1
> is responsible for computing a path for both LSP1 and LSP2."
>     Proposed: "In the example in Figure 2, PCC1 and PCC2 are configured to
> delegate their respective LSPs (LSP1 and LSP2) to PCE1. Therefore, PCE1 is
> responsible for computing a path for both LSPs."
>
>
> - section 1.3 Minor re-wording:
>
>     Original: "When the PCC2-PCE1 session is back online, PCC2 will keep
> using PCE2 as the active PCE (consider no preemption in this example)."
>     Proposed: "Once the PCC2-PCE1 session is restored, PCC2 continues
> using PCE2 as the active PCE, assuming no preemption in this example."
>
>
> - Section 1.3 - I suspect the "unit" terminology may get found during an
> IESG review, perhaps can collapse to:
>
>     Original: "This situation is called a split-brain scenario, as there
> are multiple computation brains running at the same time, while a central
> computation unit is required in some deployments/use cases. Further, there
> are use cases where a particular LSP path computation is linked to another
> LSP path computation: the most common use case is path disjointness (see
> [RFC8800]) and Bidirectional LSPs (see [RFC9059]). The set of LSPs that are
> dependent on each other may start from different head-ends."
>
>     Proposed: This scenario is called a 'split-brain' and occurs when
> multiple PCEs operate simultaneously in a deployment requiring a single
> centralized entity for computation. Such lack of coordination is
> particularly problematic for interdependent LSPs such as those requiring
> path disjointness [RFC8800] or Bidirectional paths [RFC9059] where the
> computation of one path is strictly dependent upon the state of another
> potentially originating from a different head-end.
>
>
> - section 2.1 -
>
>     Original: "can help in some scenarios where PCEP sessions are lost
> between PCCs and PCEs"
>     Proposed: I think this sentence can be dropped. Section 1.0 already
> makes the arguments for it, and, has shown it's not just when it's lost but
> also returned.
>
>     Original: "PCE1 will be able to do state synchronization via PCRpt
> messages for its LSPs to PCE2 and PCE2 will do the same"
>     Proposed: "PCE1 will synchronize its LSP state to PCE2 via PCRpt
> messages; PCE2 will similarly synchronize its state to PCE1."
>
>
> - section 2.2 indicates "as seen in section 1" .... "may provide"...
> "computation loops". However the computation loops are in the appendix, and
> section 1 does point to Appendix examples, and B.6 is an example of a loop,
> so perhaps instead might be easier for a reader to instead have:
>
>     Original: "As seen in Section 1,..."
>     Proposed: "As seen in Section 1 and Appendix B. Scenarios, ...."
>
>
> - section 3.1.1 - Capability topic in general: let's take an example being
> Path Setup Type capability exchange (RFC8408). Do two PCEs need to support
> symmetrical capabilities in order to perform state-sync? such as path setup
> type? My understanding (and opinion) is no, and  state-sync procedures
> should continue following the rules associated with that specific
> capability. One could read between the lines (the PCE behaves like a PCC in
> 3.2) of this but might be best to be explicit:
>
>     Proposed: State synchronization procedures are independent of the
> support for other PCEP capabilities, for example, Path Setup Type (RFC
> 8408). While two PCEs MUST support state-sync extensions to perform
> synchronization, they do not need to support a symmetrical set of
> additional capabilities. In cases of asymmetry, state-sync SHOULD continue
> however, the PCE MUST handle information and behavior according to the
> specific rules defined for those capabilities (e.g., ignoring paths with an
> unsupported Path Setup Type or reporting an error as defined in the
> relevant capability's specification)"
>
>
> - Section 3.7 - The text use of "could" and "would" could be tighter:
>
>     Original: "It is possible that a PCE does not have a PCEP session with
> the headend to initiate an LSP as per [RFC8281]. A PCE could send the Path
> Compute Initiate (PCInitiate) message on the state-sync sessions to another
> PCE to request it to create a PCE-Initiated LSP on its behalf. If the PCE
> is able to initiate the LSP it would report it on the state-sync session
> via PCRpt message. If the PCE does not have a session to the headend, it
> MUST send a PCErr message with Error-type=24 (PCE instantiation error) and
> Error-value=TBD5 (No PCEP session with the headend). PCE could try to
> initiate via another state-sync PCE if available.""
>
>     Proposed: A PCE may not have a direct PCEP session to a PCC to
> initiate an LSP as per [RFC8281]. A PCE MAY send the Path Compute Initiate
> (PCInitiate) message on the state-sync sessions to another PCE to request
> it to create a PCE-initiated LSP on its behalf. If the PCE is able to
> initiate the LSP, it reports it on the state-sync session via a PCRpt
> message."
>
>
>
> - section 8.2 a few references differ from other parts in the document
>     Original: state sync
>     Proposed: state-sync
>
>
>
>
> *From: *Dhruv Dhody <[e-mail]>
> *Date: *Thursday, October 30, 2025 at 11:48 AM
> *To: *[e-mail] <
> [e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *[Pce] Shepherd review of draft-ietf-pce-state-sync
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
> Hi Authors,
>
> I have done the Shepherd review of the I-D. Once the update is posted, I
> will send this to the AD.
>
> # Shepherd review of draft-ietf-pce-state-sync
>
> ## Minor
>
> - Section 3.3, "When a PCE receives a new PCRpt from a PCC without the
> LSP-DB-VERSION, it SHOULD NOT forward the PCRpt on any state-sync sessions
> and SHOULD log such an event on the first occurrence", when can the SHOULD
> NOT be ignored? Otherwise make it a MUST NOT.
>
> - Related to above, there are a lot of SHOULD in the draft, check them
> against the IESG statement
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
>
> - Section 3.5, "The computation priority is a number...", it is important
> to go a little more in detail like an unsigned integer of range 0-7 (same
> as delegation-pref in the PCEP YANG model) with 7 reflecting the highest
> preference. Update the examples to keep the priority in this range.
>
> - Section 3.5, "the highest IP address has more priority", we need to
> handle the case for comparing IPv4 and IPv6 address as well, perhaps say
> when comparan IPv4 address MUST first be converted to its IPv4-mapped IPv6
> form [RFC4291] before comparison.
>
> - Section 3.5, "...the operator MAY decide to instruct a switch-over to
> delegate the LSP to the next highest priority PCE or to take back control
> of the LSP. It is a local policy decision", is it the operator or the PCC?
>
> - I suggest explicitly clarifying that the full mesh of PCEP sessions
> between PCEs should be okay from scalability point of view. Perhaps in
> Section 8.6? Something like - 'The “full mesh” requirement applies only
> among PCEs that participate in inter-PCE state synchronization for the same
> set of PCCs or associations. In operational deployments, this typically
> involves a small number of PCEs (e.g., two or three for redundancy), making
> a full mesh feasible for deterministic state consistency and loop
> prevention.'
>
>
> ## Nits
>
> - s/updates all PCEs/updates to all PCEs/
>
> - Add reference on first mention of association groups
>
> Thanks!
> Dhruv
>