Summary
- RFC 9504 permits a stateful PCE and a PCC to exchange capabilities, state, updates and initiation requests for GMPLS LSPs; each record has a bounded protocol meaning.
- Delegation can authorize a PCE to update specified LSP attributes while it lasts, but the PCC retains state ownership, local-policy judgment and the ability to withdraw delegation.
The seductive word in a controller diagram is usually delegation. It sounds final. A team sees that a PCE has received LSP state, a delegated flag, an update request or a PCInitiate message, and concludes that the network has been handed over. That conclusion skips every operational surface that makes the word useful rather than theatrical.
RFC 9504 extends stateful PCEP into GMPLS-controlled networks. The protocol lets a PCE and a path computation client, or PCC, speak about LSP capability, state synchronization, path updates and initiation. Those are valuable acts. They make a relationship inspectable and may make a control loop possible. They are not a universal power of attorney over an operator, a device estate, an optical fabric or a customer service.
The first boundary is capability. RFC 9504 requires the relevant capabilities to be advertised and allowed at both ends before GMPLS reporting, updating or instantiation is enabled. A capability exchange says that two protocol participants have declared support for a function. It does not say that a particular change passed local policy, that a scarce resource was reserved, or that a cross-connect was made. Treating declared support as completed operation erases the difference between an interface and its use.
The second boundary is state. RFC 8231 requires a stateful PCE to learn the PCC's LSP state before computing or updating attributes. That is a restraint, not a claim of ownership. A State Report is a report; an Update Request asks for a modification. In its delegation rules, RFC 8231 is unusually clear: the PCC grants authority to update attributes of one or more LSPs, remains the owner of the state, may apply local policy, and may withdraw delegation. The PCE can be authoritative for the delegated attributes while the delegation exists. The qualifier is the whole point.
This is why a delegated LSP is neither a delegated network nor an observed result. It names a scoped relationship around a record and its attributes. It does not establish who may approve a maintenance window, whose policy admits a request, which device commits it, whether a GMPLS resource becomes available, or whether the installed forwarding and cross-connect state matches the intended route. It certainly does not establish that traffic chose the path, that protection worked, or that a service met its commercial commitment.
PCInitiate needs the same discipline. RFC 8281 describes a PCE-initiated LSP as one instantiated as a result of a PCE request; RFC 9504's GMPLS extension carries that vocabulary forward. A request can trigger the end node to set up an LSP. The word “trigger” identifies an interface event, not proof that every later action succeeded. A serious operations record therefore preserves the request, the PCC's acceptance or refusal, the resource and device evidence, the installed-state evidence, and independent traffic or service observation as different facts.
The temptation to collapse them is understandable. A PCEP log is machine-readable and close to the controller. It looks authoritative because it is specific. But specificity is not completeness. A protocol message may be excellent evidence of what a participant reported or requested at a time. It is poor evidence of facts it was never designed to observe.
The useful operating model is a ladder, not a verdict. At the bottom sit registries and negotiated capability. Above them are synchronized LSP records and a grant of limited attribute-update authority. Above that sit messages asking for a change or setup. Then come the PCC's policy decision and actual device/resource actions. Only after installed path evidence can a team ask a separate question about traffic, protection and customer effect. Each rung can support the next; no rung silently contains the rest.
That separation is not bureaucratic caution. It is how a network keeps a reversible control-plane experiment from becoming an unreviewable assertion of power. Heng Lu's minimum-initial-specification principle is useful here: shared machinery should define the smallest interoperable fact, while adoption and consequential decisions remain local. His running-code test adds a second check: functioning machinery matters, but functioning machinery is still not a substitute for an explicit record of who accepted which consequence.
For a PCE owner, the practical question is not “do we have delegation?” It is “which LSP attributes, which PCC, which duration, which local policy, and what evidence proves the next state?” For an operator receiving a controller report, the question is not whether the report is impressive. It is whether its claim has been kept within the message type's jurisdiction. That framing leaves automation intact and makes accountability sharper.
Sources
- https://www.rfc-editor.org/rfc/rfc9504.html
- https://www.rfc-editor.org/rfc/rfc8231.html
- https://www.rfc-editor.org/rfc/rfc8281.html
- https://www.rfc-editor.org/rfc/rfc8174.html
- https://www.iana.org/assignments/pcep
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
