Summary

  • RFC 3532 requires dynamic partitioning to preserve the existing state of an active virtual switching element, but it does not require every control protocol to notify the controller proactively. The controller may discover a reduced allocation only when a later request fails and it queries the available resources.
  • A defensible reallocation receipt must keep allocation, authorization, in-use-resource handling, controller awareness, unaffected partitions, inter-partition services and application outcome separate. “Repartition succeeded” cannot stand in for the whole chain.

The attractive property of dynamic repartitioning is continuity. Under the static alternative described by RFC 3532, controllers for affected partitions disconnect, configured state is generally released, the virtual switching element goes down and its state must be rebuilt. Dynamic partitioning changes the allocation while the partition remains active and must maintain its existing state.

That continuity is easy to overread. A session that stayed connected does not prove the controller already knows the new ceiling. State that was retained does not prove the state remains useful under less capacity. A resource table that changed does not prove traffic continued to meet an objective. RFC 3532 is most valuable as a map of those boundaries.

Published in May 2003, the memo is Informational and expressly says it does not specify an Internet standard. It defines requirements, not a complete protocol. Its primary setting is the partitioning of GSMP switches, and it warns that its requirements may be necessary but are not necessarily sufficient for other switching elements, including longest-prefix-match forwarders.

Four logical roles prevent one receipt from owning the story

The switching element, or SE, performs packet switching and exposes resources that can be divided. A partition—also called a virtual SE—is one allocation of those resources. A controller operates an active partition. A partition manager, or PM, decides how many virtual SEs exist and which resources each receives.

Those roles define three different conversations. The PM tells the SE how to allocate resources. The controller programs the active partition. The PM and controller may negotiate a reduction or increase. A database row that records only “capacity changed” loses the identity, authority and observation surface of each participant.

The entities are logical. They may be colocated in one physical system or distributed among several. Logical separation therefore does not prove hardware isolation, process isolation or an independent failure domain. Conversely, physical colocation does not erase the distinct authorities. An audit should name both the logical role and its actual runtime principal.

RFC 3532 offers a leased-partition example: an owner divides a switching element and gives third parties control of virtual elements. That example should not be stretched into evidence of a particular commercial arrangement. A lease, a PM’s authority to repartition, a controller’s authority to operate and the SE’s currently enforced allocation are four claims. None automatically proves the others.

No restart exchanges visible interruption for a subtler boundary

Static repartitioning makes the interruption obvious. An affected controller disconnects, its partition goes down, resources change and state is reconstructed. Unaffected partitions need not go down. Even the disruptive path is therefore scoped: changing one partition is not permission to cycle an entire switch or every tenant on it.

Dynamic partitioning removes that forced restart for the modified active partition. The RFC requires all existing state associated with the partition to be maintained. This is a state-preservation requirement, not a service-level guarantee. A forwarding entry can remain installed while its supporting queue, buffer, bandwidth or connection budget becomes tighter. The control channel can remain live while a new request begins failing.

The operational trade is not “downtime versus perfect continuity.” It is “explicit reconstruction versus an in-place change that needs additional evidence.” The latter can be much better, but its receipts must show what changed and who learned about it.

The memo assumes deterministic partitioning. Each active partition has an allotted quantity of each resource, and one partition’s use does not alter the amount available to another. Statistical pooling, percentage shares and oversubscribed common reservoirs are outside scope. An operator cannot cite RFC 3532 as proof that a pooled system isolates tenants merely because both systems use the word partition.

A smaller allocation is not a command to erase live work

The SE must stop a controller from using more than its current allocation. That rule defines enforcement at the new boundary. It does not authorize the SE to silently destroy resources already in use so a requested decrease can appear successful.

If the PM asks the SE to release resources allocated to an active partition and any requested resources are in use, the SE must deny the request. The denial is a correct result, not a failed implementation. It preserves a distinction between unused capacity that can be reassigned immediately and live capacity whose removal requires coordination.

After a denial, the PM should freeze the partition and/or ask the controller to reduce utilization. Freezing has a precise meaning. The partition relinquishes unused resources, keeps its current connections, and returns resources as those connections close. It is neither normal operation nor immediate deletion. A dashboard that labels it simply “active” hides scarcity; one that labels it “stopped” hides the continuing connections.

If a controller never releases enough resources, the PM can use virtual power-off control, making the partition inactive and disconnecting its controllers. That mechanism prevents permanent resource starvation. It is also disruptive. A forced power-off receipt cannot be reported as a successful non-disruptive dynamic decrease merely because it eventually frees the requested amount.

The evidence record should therefore contain the old allocation, measured use, requested allocation, resource types, SE decision and disposition of every in-use item. “New limit: 80” is incomplete if the system previously had 100 units allocated, 92 in use and later achieved 80 by terminating twelve live objects.

The controller can learn after the allocator has finished

RFC 3532 describes several awareness paths. A control protocol may support proactive notification: the SE tells the controller asynchronously that its resources changed. That is the clearest temporal signal, but the memo does not make it mandatory for every protocol.

Reactive notification is mandatory, either explicitly or implicitly. Under the explicit form, a later controller request fails with an error that says resources were reassigned. Under the implicit form, the request returns a generic, unknown or resource-related error; the controller must query the SE’s available resources to determine whether a reallocation caused the problem.

The PM may instead contact the controller directly. This creates another receipt path with its own authentication, delivery and acknowledgment needs. A PM message that was sent is not proof that the controller updated its scheduler. A protocol error that was returned is not proof that the controller interpreted it correctly. A resource query proves what the SE reported at that time, not how future controller decisions were made.

These paths make “reallocation time” an unsafe synonym for “controller-awareness time.” The two timestamps can differ by a control-message delay, by the interval until the next request, or by the time needed to diagnose a generic failure and issue a query. During that interval the SE can be correct to enforce the new limit while the controller is also internally consistent with its stale model.

For automation, retain the exact awareness mechanism. Record proactive notice ID, explicit error type, generic error plus follow-up query, or authenticated PM-to-controller exchange. Then record the controller’s model version, acknowledgment and retry behavior. Without that second receipt, awareness is an inference.

Inventory is necessary and deliberately insufficient

The PM must be able to query the SE for its resources, configured partitions and the allocation for each partition. For automated PM-controller interaction, it must be able to learn the addresses of controllers attached to a virtual SE. It may also learn which control protocol and version they use.

This inventory is the allocator’s ledger. It can establish that the SE now reports forty queue objects to one partition and sixty to another. It can show which controller endpoint should be contacted. It cannot establish that the endpoint received a notice, that the controller reduced demand, or that application traffic survived the smaller envelope.

The distinction matters during reconciliation. If the PM’s desired state and the SE’s reported state differ, the operator first needs a resource-allocation problem. If they agree but the controller still requests the old capacity, the problem is awareness or adaptation. If all three agree but users see loss, the problem lies farther down the outcome chain. One generic “sync failed” alert makes those investigations slower.

Inventory also has a time boundary. A successful query is an observation at one moment. The receipt should preserve SE identity, partition identity, resource schema, values, query time and response digest. A later allocation change must not silently rewrite the historical record.

Inter-partition services turn a local change into a dependency question

An SE may provide a service from one virtual SE to another, such as a virtual link. The SE must expose the available partition-to-partition services and the PM must be able to configure them. If a change adds or removes a virtual port, the SE must notify attached controllers when their control protocol supports that notification.

A resource decrease can therefore remain local in the allocation ledger while altering a dependency used by another partition. The controller of the modified partition may retain all its state, yet a virtual link can lose a port or capacity. The other partition can be “unaffected” by the direct repartition request and still depend on the changed service.

Validation needs two scopes. First, prove that partitions outside the impact set retained their allocation and process identity. Second, enumerate inter-partition services that cross the changed boundary and test them as dependencies. The first check protects unrelated tenants; the second prevents a narrow change plan from overlooking a real runtime edge.

This is why a shared chassis, PM or protocol does not by itself place every partition in the impact set. Impact follows changed executable inputs, allocations and service dependencies. The RFC’s own distinction between affected and unaffected partitions supports a minimal, evidence-based blast radius.

Authorization does not prove capacity or outcome

Only an authorized PM may dynamically repartition an SE. The SE must use a secure process through which an authorized entity selects the controlling PM, either explicitly or through authorized discovery. Only that PM or its authorized agent may ask controllers to reduce resources or tell them about increases.

The reverse direction also needs protection. A PM must authenticate that a request for more or fewer resources came from a controller authorized for the specified virtual SE. Otherwise one tenant could attempt to reshape another tenant’s envelope or trick the PM into reallocating shared capacity.

Authentication answers who presented a credential under a configured trust process. Authorization answers whether that principal could perform this operation on this partition. Neither proves that the requested allocation is commercially entitled, operationally safe, actually enforced or sufficient for the service. Those facts need separate policy, SE and outcome evidence.

The selection process for the PM deserves its own immutable record. If authority can move between managers, a later valid credential should not retroactively legitimize an earlier change. Bind each request to the PM-selection state, credential, policy version, partition and payload digest that existed at decision time.

Later architecture does not retroactively complete this memo

RFC 3654 and RFC 3746 later described requirements and a framework for separating forwarding and control elements. RFC 5810 and RFC 5812 specified the ForCES protocol and forwarding-element model, and RFC 7121 addressed ForCES high availability. They provide useful history for control/forwarding separation.

They do not convert RFC 3532 into a standard, supply a missing deployment receipt or prove that a particular switching element used ForCES. RFC 3654 and RFC 3746 are Informational; RFC 5810, RFC 5812 and RFC 7121 are Proposed Standards. Each retains its own status, scope and date.

Protocol lineage is context, not adoption evidence. The same rule applies to bibliography metadata, document history and errata pages. They help identify the document and its record. They do not observe a running partition.

Build a receipt chain that follows the change

Begin with identity and authority: exact SE, PM, controller, partition, physical mapping, PM-selection record, credentials, policy version and requested change digest. Record the deterministic resource types, previous allocation, observed use and desired allocation.

Next record the SE decision. Distinguish immediate release of unused capacity, denial because resources remain in use, freeze, negotiated controller release and virtual power-off. Preserve existing-state checks and the enforcement response when the controller reaches the new ceiling.

Then capture awareness. Name the proactive notice, explicit reactive error, implicit error and query, or direct PM contact. Link the controller’s refreshed model and subsequent retry. Query the SE again for post-change allocation, but do not let that inventory substitute for the controller receipt.

Finally test inter-partition services, representative unaffected partitions, forwarding capacity and the application objective. Every owner should attest only to its surface. The PM can prove it requested a change; the SE can prove its allocation; the controller can prove its model; service telemetry can prove behavior; the application owner can prove the user result.

The compact executive statement is not “repartition succeeded.” It is: “The authorized allocator changed these unused resources at this time; the SE maintained these states; the controller learned by this path and accepted this model; these dependencies and outcomes were then observed.” Anything shorter should disclose which links remain unknown.

Evidence boundary

This Article identifies no implementation, vendor, operator, switching element, partition manager, controller, tenant, lease, resource pool, partition, deployment, incident, outage, security event or customer outcome. It reports no current adoption, capacity value, utilization level, packet loss, latency or service result.

RFC 3532 is treated as a May 2003 Informational requirements document, not an Internet Standard or a complete protocol. Its deterministic-partition assumptions are not generalized to statistical pooling or oversubscription. Later GSMP, Megaco and ForCES materials keep their own dates, status and scope and do not prove conformance by any live system.

Heng Lu’s disclosed notes provide an editorial lens: authority should stay bounded to the operation it controls, and running-code evidence should close a claimed result. They do not establish IETF intent, implementation behavior or deployment fact.

The bounded conclusion is that an active partition can be reallocated without restart while its controller remains unaware until a later notification, error, query or direct contact. Preserved state and an updated allocator inventory are necessary evidence, but neither proves service outcome.

Sources