Summary

  • The IESG-approved extension lets a BGP SR Policy candidate path carry the control-plane NRP ID associated with its intended Network Resource Partition.
  • That number names an association inside one NRP domain. It does not allocate resources, prove the local data-plane mapping, guarantee isolation or establish the service outcome.

A number arrives before the resources do

Imagine a headend learning two candidate paths for one SR Policy. The policy color and endpoint are the same. One path carries NRP ID 17; the other carries NRP ID 29. Those values can direct the headend toward different underlay resource partitions.

The update does not contain the bandwidth, queue state, interface configuration or measured isolation of either partition. It does not show that the headend installed the candidate path, translated the control-plane ID into the intended data-plane selector or steered a service into it.

This is an illustrative control-plane case, not a reported incident. Its point is narrow: a field can communicate which partition a path is associated with while leaving every executing transition to other systems.

That distinction became a standards event on 25 August. At 18:03 UTC, the IETF announced IESG approval of revision 13 of “BGP SR Policy Extensions for Network Resource Partition” as a Proposed Standard.

Approval is one state in a dependency chain

The document is a product of the Inter-Domain Routing Working Group. The announcement records debate over dependencies on TEAS and SPRING work, rough consensus to progress, and a decision to let normative-reference dependencies resolve in the RFC Editor queue.

At the 28 August evidence freeze, Datatracker still showed an Active Internet-Draft. The RFC Editor status was blocked because a reference had not been received. IANA review said the version had changed and needed review; action was still in progress. A final RFC number and completed registry state are later facts.

The announcement reports two implementations. The linked IDR report names Huawei VRP and H3C Comware surfaces, but it also contains older-version wording and feature rows still marked TBD. That is useful evidence of implementation work. It is not a fleet inventory, an interoperability result for revision 13 or proof that the feature is enabled in a service.

An NRP is more than its identifier

RFC 9543 defines a Network Resource Partition as a subset of underlay resources and associated policies that can support one or more network-slice services. RFC 9732 places NRPs inside an enhanced-VPN framework in which connectivity constructs can be mapped to those resources.

The physical and operational nouns matter. Resources include the capacity and forwarding treatment operators actually provision. Policies decide how those resources are used. Service steering decides which traffic reaches them. Measurements show whether the promised behavior occurred.

An NRP ID is not that inventory. Revision 13 uses a 32-bit control-plane identifier that is unique within an NRP domain. The identifier is linked to a data-plane NRP Selector ID by the domain's own configuration and implementation.

The document deliberately covers one design: a dedicated, domain-wide selector carried in the data plane. Other ways of selecting an NRP do not require this explicit SR Policy signal and remain outside its scope.

The sub-TLV has a small, precise job

The extension defines an NRP ID sub-TLV inside the BGP Tunnel Encapsulation Attribute when the tunnel type is SR Policy. Revision 13 records type 123. The length must be six octets: flags, reserved bits and four octets of NRP ID.

Flags and reserved bits are sent as zero and ignored on receipt. NRP ID zero is reserved. A sender must not use it, and a receiver ignores a sub-TLV that carries zero. The sub-TLV is optional and must not appear more than once for one candidate path.

Those rules establish a wire invariant. They prevent several encodings from competing for authority inside one candidate path. They do not determine whether a nonzero ID has a correct local mapping or whether the partition behind that mapping has the expected resources.

When the length is not six, or the sub-TLV is duplicated, the NRP information associated with the SR Policy NLRI is malformed. The receiver applies RFC 7606 treat-as-withdraw. That response protects routing state from an ambiguous or structurally broken association; it is not a verdict on a well-formed but semantically wrong mapping.

BGP acceptance does not finish selection

The originator must include the NRP ID when a candidate path is instantiated in an NRP and the domain uses the dedicated selector design. On receipt, the BGP speaker applies RFC 9830 validity and usability rules. Ordinary BGP best-route selection does not change.

Selected best routes for the SR Policy SAFI are then passed to the SR Policy Module. That handoff is a boundary. A route can be accepted by BGP but never become the active candidate path. An SRPM can receive the path but fail to install it. An installed path can carry the wrong selector because local mapping drifted.

The remaining chain includes candidate-path selection, segment-list installation, the mapping from NRP ID to selector, packet augmentation, service steering, the provisioned queues and links, and the result seen by traffic. Each transition has its own owner and failure mode.

This is why a controller's successful advertisement cannot be used as evidence of reserved capacity. At most, it proves that a specific control-plane association was emitted and accepted under known session and validation state.

Consistency across candidate paths is a policy decision

Revision 13 permits candidate paths inside one SR Policy to be associated with different NRPs, but calls that valid configuration not recommended. In normal scenarios, it says all candidate paths should keep the same NRP association.

The reason is operational continuity. A preference change or failure can activate another candidate path without changing the policy key observed by the service. If that path silently selects a different resource partition, the failover can also change isolation, capacity, cost and disclosure characteristics.

Consistency does not mean merely repeating the same integer. Headends must agree on what that integer maps to. The data plane must apply the selector consistently. The underlay must provision the associated resources. A uniform number over inconsistent local maps is coordinated syntax with divergent behavior.

Scale belongs at the controller and headend boundary

The draft says that as the number of NRPs grows, the number of SR Policies and candidate paths can also grow. Information exchanged between controller and headends can increase proportionally.

It does not change the SR Policy advertisement procedure or BGP best-path algorithm. Corresponding headends install the candidate paths, so the added advertisement does not place the same state on transit nodes.

That is a useful scope boundary, not a promise of zero cost. Controllers still create and reconcile state. Headends still receive, validate, hand off and install it. Monitoring systems must distinguish advertised, accepted, selected and installed cardinality or a nominally successful control plane can hide a headend bottleneck.

Wrong association can defeat the purpose of the partition

The security section inherits BGP, SR Policy and NRP protections, then states the local risk directly: an incorrect association can affect traffic isolation and resource guarantees.

Authentication of the BGP peer does not remove that risk. A trusted controller can send a wrong NRP ID. A trusted headend can map the correct ID to the wrong selector. A correct selector can point into stale resource configuration. All are authorized components producing an unauthorized outcome.

The association can also disclose sensitive network intent. An advertised NRP may reveal mission-critical or commercially significant structure. Operators are responsible for limiting senders and receivers to trusted routers and controller applications and for ensuring the association is correct.

For one policy episode, preserve controller and peer identity; NLRI key; candidate-path origin and preference; raw sub-TLV bytes; validation and best-route decision; SRPM receipt and selection; installed segment list; ID-to-selector mapping and version; resource configuration; service steering; observed packet selector; queue, loss, latency and isolation result; and the timestamps joining them.

Sources