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

["Andrew Stone (Nokia)" <[e-mail]>]

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.



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.





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