Summary
draft-ietf-teas-ns-ip-mpls-10says control-plane NRP mode isolates at admission time, but without per-packet enforcement traffic can contend at runtime and the guarantee remains soft.- Executives should keep service intent, slice-to-aggregate mapping, reservation, oversubscription, selector treatment, incapable segments and measured customer outcome as separate evidence coordinates.
Two premium services entered the controller with different names, separate customers and green admission records. They left it inside one Slice-Flow Aggregate. At the busy hour, both met the same physical queue. One burst; the other missed its delay target.
Nothing in that sequence necessarily contradicts the controller's ledger. It exposes a more consequential distinction: a system can correctly decide that demand is admissible without proving that each packet will receive isolated treatment when demand arrives differently from the model.
Revision 10 of Realizing Network Slices in IP/MPLS Networks is an active TEAS Working Group Internet-Draft dated September 2026 and expiring on 2 April 2027. It is not an RFC, a deployment report, an interoperability result, a certification or proof that a live operator meets an SLA. It has no IANA actions. Its value is architectural: it names the places where a commercial promise becomes a mapping, a policy, a reservation and eventually a packet treatment.
One aggregate can carry several promises
The draft introduces a Slice-Flow Aggregate: packets mapped to an NRP and given the same forwarding treatment. By definition, multiple IETF Network Slices may be mapped into one aggregate. A controller maintains the association, but the method for deciding that association is local and outside the document.
That is the first governance boundary. Customer contracts may distinguish low latency, loss, availability or geography more finely than the aggregate does. If two services share an aggregate, the network is not necessarily wrong; leadership has chosen a common enforcement class. The receipt should name which slices were collapsed, why their SLOs were compatible, who approved the policy and when the mapping must be reconsidered.
A dashboard that shows only the customer slice name hides this compression. A dashboard that shows only the aggregate hides the promises that were compressed into it. Both identifiers are needed.
A reservation is a model of capacity
An NRP Policy can associate topology, resource reservations, sharing rules and per-hop behaviour with an NRP. In control-plane mode, admission is constrained so reserved bandwidth across NRPs does not exceed physical capacity, subject to configured oversubscription.
The qualification matters. The NRP topology may represent less than, equal to or more than physical capacity. Maximum reservable bandwidth can exceed the underlying link where oversubscription is intended. The ledger can therefore be internally valid while relying on a statistical assumption about concurrent use.
Reservations also describe admitted demand, not the exact packet arrival process. Microbursts, customer misclassification, failed paths, queue coupling and stale utilization can turn a sound planning model into runtime contention. The draft states the result plainly: control-plane-only isolation is soft because there is no per-packet enforcement. Monitoring and path reoptimisation can compensate, but they react to an observed condition; they do not retroactively make the initial admission a forwarding guarantee.
The strongest mode joins two different controls
Data-plane NRP mode carries a selector that capable nodes use to identify the aggregate and apply an NRP per-hop behaviour. Dedicated hardware can create strict isolation. Shared hardware provides statistical isolation dependent on configured scheduling and allocation.
The document calls combined control- and data-plane partitioning the strongest form. That is not because either record becomes more authoritative. Admission controls how much demand is accepted; packet treatment controls what happens during runtime contention. The two protect different failure surfaces.
Operational evidence should retain them separately. Record the admitted bandwidth and oversubscription assumption. Then record the selector seen at ingress, the queue or scheduler selected at each capable hop, actual utilization, drops and delay. A controller acknowledgement cannot substitute for those observations.
The label may survive where treatment stops
Slice traffic may traverse NRP-incapable nodes. The selector can remain in the packet, or traffic can be tunnelled around incapable equipment, so NRP treatment can resume later. That continuity of marking is useful, but it is not continuity of enforcement.
The evidence path must mark the start and end of every incapable segment. It must say whether that segment offered ordinary best effort, another traffic class or a tunnel with its own resource controls. Static capability declarations deserve expiry and reconciliation because the draft notes that they do not adapt automatically to topology or capability changes.
An unrecognised selector creates another branch. A node may drop it, give it best-effort service or send it to a fallback NRP under local policy. A packet that was classified correctly at the edge can therefore receive a materially different treatment downstream. A service proof needs the actual branch, not the preferred diagram.
Domain seams are translations, not inheritance
Across NRP domains, selectors may be stacked or remapped. Stacking preserves an outer identity while an intermediate domain adds its own selector. Remapping replaces the incoming selector with the downstream domain's equivalent and requires coordinated mappings. The boundary must also condition traffic to the downstream allocation.
Correct translation proves only that the next domain received the intended local class. Each domain is responsible for its portion of the service. End-to-end satisfaction depends on their combined allocations and behaviour. Nine local green lights do not automatically form one global guarantee if delay budgets, loss accounting, clocks, measurement windows or exception handling do not compose.
The accountable record needs the incoming and outgoing selector, mapping owner, policy version, conditioning result, accepted traffic profile and the downstream domain's commitment. It also needs a measurement that spans the seam. Otherwise the boundary is a hand-off of labels, not a hand-off of proof.
A selector is not entitlement
The security section warns that an attacker may inject packets carrying an NRP Selector to consume privileged resources. Theft of service can become denial of service. Unknown selectors can also be aimed at fallback capacity, while manipulated NRP Policy can reroute traffic or deprive legitimate partitions.
This makes boundary conditioning an authority check. The network must establish that the arriving traffic is entitled to the resource class, not merely that the packet contains a syntactically valid value. Management-plane authentication, authorization and integrity protect who may alter the policy; routing-session controls limit disclosure of sensitive resource state.
The deeper leadership point is that every coordinate has a different owner. Product teams own the customer promise. Controllers map it. Capacity teams set reservations. routers execute queue policy. Security teams defend selectors and management state. Operations observes the outcome. Combining their status into a single “slice healthy” badge removes the very distinctions an incident review needs.
The useful claim is narrower: this demand was admitted under this resource model; these packets were classified into this aggregate; these capable nodes applied this treatment; these gaps and domain translations occurred; and these measurements show what the customer received. Only the complete chain can support an isolation claim.
Sources
- https://www.ietf.org/archive/id/draft-ietf-teas-ns-ip-mpls-10.txt
- https://www.ietf.org/archive/id/draft-ietf-teas-ns-ip-mpls-10.html
- https://www.ietf.org/archive/id/draft-ietf-teas-ns-ip-mpls-10.xml
- https://datatracker.ietf.org/doc/draft-ietf-teas-ns-ip-mpls/
- https://datatracker.ietf.org/doc/draft-ietf-teas-ns-ip-mpls/history/
- https://datatracker.ietf.org/doc/draft-ietf-teas-ns-ip-mpls/references/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-teas-ns-ip-mpls/
- https://www.rfc-editor.org/rfc/rfc9543.txt
- https://www.rfc-editor.org/info/rfc9543
- https://www.rfc-editor.org/rfc/rfc2475.txt
- https://www.rfc-editor.org/rfc/rfc3209.txt
- https://www.rfc-editor.org/rfc/rfc5440.txt
- https://www.rfc-editor.org/rfc/rfc6241.txt
- https://www.rfc-editor.org/rfc/rfc7752.txt
- https://www.rfc-editor.org/rfc/rfc8040.txt
- https://www.rfc-editor.org/rfc/rfc8402.txt
- https://datatracker.ietf.org/wg/teas/documents/
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
