Skip to main content

5. Using a Controller to Build a P2MP Tree

A controller is provisioned with the SR P2MP Policy and its CPs, computes PTIs, and instantiates them in the SR domain. Provisioning details are outside this document.

5.1. SR P2MP Policy on a Controller​

An operator, network node, or machine can provision the controller with the Root address, Leaf-node set, and CPs. The policy and CPs can then be instantiated on the Root node through a signaling protocol. Conversely, they may be provisioned on the Root node and instantiated on the controller. CP constraints and optimization objectives are based on SR Policy work, and additional P2MP-specific constraints MAY be used.

5.2. Controller Functions​

The controller generally performs:

  • Topology discovery across IGP areas, levels, or ASes.
  • Capability exchange to discover and advertise node capability for SR P2MP Policy participation.

5.3. P2MP Tree Compute​

The controller computes one or more PTIs for CPs. A CP may have no PTI if no suitable tree can be computed. The controller MUST compute a P2MP tree with no loops at steady state, as required by RFC 9524.

When topology changes affect a PTI, or when a better path is available, the controller SHOULD modify the PTI. It MAY use Make-Before-Break: create a new PTI, instantiate it, activate it, and then remove the old PTI to reduce traffic loss.

5.4. SID Management​

The controller assigns Replication-SIDs for PTI Replication segments. They may be dynamic or statically assigned by the provisioning entity.

For SR-MPLS, a Replication-SID may come from the SR Local Block (SRLB) or SR Global Block (SRGB). It is RECOMMENDED to assign it from the SRLB because Replication segments are local to each PTI node. It is NOT RECOMMENDED to allocate from the SRGB because SRGB is globally significant and can be depleted by many PTIs.

The controller may also assign a BSID, or it may allow the Root node to assign it. For SR-MPLS, assigning the BSID from the SRLB is RECOMMENDED. Reserved blocks for Replication-SIDs and BSIDs may overlap with SRLB, SRGB, or both, but deconfliction procedures are outside this document.

5.5. Instantiating P2MP Tree Instance on Nodes​

After computing trees, the controller instantiates Replication segments using PCEP, BGP, NETCONF/YANG, or other mechanisms. Nodes SHOULD report successful instantiation. If instantiation fails, for example because a Replication-SID conflicts with another SID, the node SHOULD report the failure and preferably a reason.

If instantiation fails, the controller SHOULD retry, with an upper bound on attempts. After repeated failure, it SHOULD generate rate-limited alerts. It MAY tear down a PTI if some Replication segments fail, and it is RECOMMENDED to tear down the PTI if the Root-node Replication segment fails.

A practical batch approach is to instantiate Leaf and intermediate Replication nodes first, then instantiate the Root-node Replication segment. If the Root succeeds, the controller can immediately activate the PTI.

5.6. Protection​

5.6.1. Local Protection​

Links, nodes, or replication branches in a PTI can be protected with SR Policies. Backup SR Policies are associated with replication branches and programmed in the data plane. The backup segment list is imposed on the downstream Replication-SID. Local LFA, TI-LFA, Micro-Loop, and SR Micro-Loop prevention mechanisms can also protect PTI links and nodes.

5.6.2. Path Protection​

A controller can create a disjoint backup tree instance for end-to-end tree protection when topology permits. This is commonly achieved with a backup CP whose constraints or objectives ensure that its PTIs are disjoint from the primary active CP.

Last updated on