Summary

  • draft-ietf-spring-resource-aware-segments-20 lets existing SR-MPLS SIDs and SRv6 locators/SIDs identify a Network Resource Partition or local resource subset as well as a forwarding action.
  • The identifier selects intended treatment. It does not prove that every node allocated the resources, that bindings agree, that traffic avoided best-effort fallback, or that the service met its SLA.

A packet arrives bearing a SID that means more than “go there”. It also means “use this slice of bandwidth, these buffers and these queues”. The route is valid, the identifier is recognized and the packet reaches the far end. Somewhere in the middle, however, the selected resource set was never built. The packet may be dropped or quietly moved into best effort. The SID did its job. The resource promise did not.

That separation is the operational story in revision 20 of Introducing Resource Awareness to SR Segments, posted on 30 September 2026. The active SPRING Working Group Internet-Draft is intended for Proposed Standard and sits in IESG Evaluation / AD Followup with a DISCUSS still recorded. It is not an RFC, a final IETF decision or proof of interoperable deployment.

The identifier carries a choice, not inventory

Base Segment Routing gives a SID a forwarding instruction. Revision 20 adds an association with network resources without defining a new SID type. A resource-aware Adj-SID can name the next hop and a local subset of link resources. A resource-aware Prefix-SID can identify a route toward a node and the resources of an NRP. In SRv6, a resource-aware locator supplies the NRP context while End.X or other SIDs can select local behavior and resources.

This is economically useful. Operators need more than DiffServ's coarse class count when several customers or services require isolation. A controller can build an SR Policy from resource-aware SIDs and steer traffic through a chosen partition without installing per-path state at every transit node.

But the bit pattern is an index into local state. It is not the state. It cannot show whether a scheduler reserved the requested weight, whether a queue survived reboot, whether a link joined the correct NRP, or whether the same label maps to the same operational promise on the next router. A packet proves that an identifier was carried. Only node evidence can prove what each node did with it.

Global meaning is assembled from local acts

The draft distinguishes local and global resource-aware segments. Local SIDs bind a set of resources on a particular node or link. Global SIDs associate with the resources of an NRP across participating nodes and links. That global appearance can obscure the physical truth: the partition exists only if a series of local allocations and bindings agree.

Revision 20 now says an NRP must not carry a service until it is fully provisioned. An update is not complete until every involved node has been changed successfully. Partial allocation must be reported, and the controller or management system should be able to roll back. If a node detects inconsistent binding, affected SIDs must not be used for forwarding and the error should be logged and reported.

Those are commit semantics, not a commit protocol. Detailed allocation, YANG augmentation and several control-plane extensions remain outside the document. The operator still needs a transaction record: intended NRP membership; authorized resource amount; exact SID or locator; per-node acceptance; applied configuration; hardware state; activation time; rollback result; and the version against which consistency was checked.

A controller's “success” must therefore be decomposed. Did it deliver configuration? Did every node accept it? Did hardware allocate the resource? Did all nodes expose the same binding? Did activation occur only after the last receipt? A green orchestration job cannot lend proof to steps it did not observe.

Failure can look like reachability

The most revealing behavior is what happens when the selected resources are absent. For both SR-MPLS and SRv6, revision 20 says a transit node that cannot find local resources for the identified NRP should discard the packet by default. An operator can change that behavior to best-effort forwarding.

Reachability can therefore survive while the service contract fails. A packet that takes the grey lane may still reach the application, masking loss of isolation, latency or jitter guarantees. The draft says best-effort fallback should be logged and reported. That log is not optional operational decoration: it is the evidence that distinguishes a delivered premium service from ordinary delivery after downgrade.

Excess traffic creates a related choice. The operator may drop it, lower its priority or treat it as best effort. Each policy has different commercial and security consequences. An availability dashboard may celebrate successful delivery while an SLA ledger records failure. Both can be correct because they measure different claims.

A secured controller can still receive a false world

Revision 20 strengthens the control boundary. Allocation, SID association and distribution must use channels with mutual authentication, authorization, integrity and replay protection; sensitive topology or capacity data should also be confidential. Admission control must stop resource-aware allocations from starving the base SR forwarding plane.

Those controls protect commands and distribution. They do not make a compromised node honest. The security section explicitly considers a node that fails to allocate claimed resources, overstates capacity or selectively degrades an NRP. An authenticated report proves who sent the report and that it was not altered. It does not prove that the reported queue or bandwidth existed.

The draft lists several Huawei router families as implementations reported to be in production as of 28 August 2025. Its RFC 7942 notice also says such information is contributor-supplied, unverified and not IETF endorsement. The frozen evidence contains no multi-vendor interoperability result or measured SLA trace. The claim should remain exactly that narrow.

The receipt chain has to reach the application

The defensible evidence chain begins with authorized service intent and the exact draft/profile. It then records NRP membership, resource quantities, SID and locator assignments, per-node admission, actual allocation, consistent binding, all-node commit, packet classification, discard or fallback counters, performance measurement and application outcome. Maintenance and failure response need the same chain again because resources and topology can move while the identifier remains stable.

Heng Lu's minimum-initial-specification doctrine is useful here. A shared standard can define the smallest portable meaning of the identifier and the failure defaults. It should not centralize the local decisions about resource sizing, admission, pricing, fallback or remediation. Running-code primacy adds the harder rule: a standards-track draft and a recognized SID are not adoption evidence. Receipts from routers, controllers and applications are.

Revision 20 makes intended resource treatment addressable. That is real progress. Its discipline is clearer when the identifier is denied a power it does not have. The SID can choose the lane. Only an end-to-end record can show that the lane existed, remained consistent and delivered what was sold.

Sources