[Pce] Re: Shepherd review of draft-ietf-pce-state-sync and Dhruv's comments

[[e-mail]]

Hi Andrew and Dhruv,

 

Thanks for the fast review of the I-D and suggestions. 

 

Re: Additional comments from Dhruv

 

Nothing looks objectionable. We will address and update shortly. 

 

Re: Additional thoughts on topic B. 

 

The text update looks great; I'm queuing it with Dhruv's comments. 

 

BR, Dan. 

 

From: Andrew Stone (Nokia) <[e-mail]> 
Sent: 10 June 2026 17:57
To: Dhruv Dhody <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [Pce] Shepherd review of draft-ietf-pce-state-sync

 

Hi Authors,

 

Thanks for the update to the document. My concern for Topic A can be considered closed from my side, but a +1 to Dhruv's comments below although I'm okay with the current text also. 

 

Regarding topic B (independent of Dhruv's comment below):  

 

Thanks for adding more details. I think the language needs a bit more tightening regarding the PcRpt "acknowledgement". PcUpd/PcRpt acks are aided with SRP Object. RFC8231 allows SRP to be optional as it only MUST be carried in response to PcUpd, and it's also scoped only to the current PCEP session. Therefore, today a PCC implementation with PCE1 and PCE2: PCE1 sends a PcUpd to PCC, when PCC sends a PcRpt to PCE2 for local state change, it is not required to carry an SRP Object and if present would not correlate with the PcUpd. So, in the context of state-sync, the "acknowledgement remains driven by the PCC-originated PCRpt" can be a bit broad or misleading if one assumes or expects it will carry the SRP, which it may not. 

 

Therefore perhaps: 

 

 

OLD

Acknowledgement remains driven by the PCC-originated PCRpt, which is then propagated according to the forwarding rules in Section 3.3.

 

NEW 

Acknowledgement remains driven by the PCC-originated PCRpt. However, the PCRpt received by a PCE that did not originate the PCUpd is not required to carry the SRP object, and where it is present the SRP-ID-number is scoped to that PCEP session (per [RFC8231]). Therefore, a PCE MUST NOT rely on the SRP object to correlate the PCRpt with the PCUpd. Any processing to handle correlation or PCUpd/PCRpt reordering is implementation specific and outside the scope of this document. The PCRpt, when received, is then propagated according to the forwarding rules in Section 3.3.

 

 

In the meantime, I have posted the Shepherd writeup. 

 

Thanks!

Andrew

 

From: Dhruv Dhody <[e-mail] <mailto:[e-mail]> >
Date: Monday, June 8, 2026 at 3:28 AM
To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >; Andrew Stone (Nokia) <[e-mail] <mailto:[e-mail]> >
Subject: Re: [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 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] <mailto:[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 <https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-state-sync-13&url2=draft-ietf-pce-state-sync-14&difftype=--html> &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] <mailto:[e-mail]> >
Date: Thursday, October 30, 2025 at 11:48 AM
To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[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 <http://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