RFC 9960

Segment Routing Point-to-Multipoint Policy

📅 published April 2026, from ietf

RFC 9960: Segment Routing Point-to-Multipoint Policy ✨

okay bestie, let's get into this one 💖 It's an IETF Standards Track doc (so it's the real deal, not just an idea), published April 2026, and it's the ISSN 2070-1721 kind of RFC 🎀

Quick title-block tea ☕:

  • Editor(s): R. Parekh (Arrcus) and D. Voyer (Cisco Systems, Inc.) 🦋
  • Co-authors: C. Filsfils (Cisco Systems, Inc.), H. Bidgoli (Nokia), Z. Zhang (Juniper Networks) 🌸
  • Category: Standards Track
  • Date: April 2026
  • Updates: RFC 9524 💅 (so it's tweaking RFC 9524's stuff, not replacing it)
  • Obsoletes: nothing ✨

The whole vibe here is making multipoint delivery efficient inside a Segment Routing domain 🧚 Instead of one long ingress-to-egress replication path that keeps sending the same traffic over the same links (inefficient, lowkey wasteful 💀), you build a proper P2MP tree 🌳

1. Introduction 🌈

Okay so, RFC 9524 defines a Replication segment. It lets an SR node replicate traffic to multiple downstream nodes in an SR domain (see [RFC8402]) 💜 A P2MP service can be done with one Replication segment that runs from the ingress node all the way to the egress nodes. Iykyk, that's ingress replication, and it's inefficient because the same nodes and links can carry the same traffic over and over 😭

A multipoint service is way better with a P2MP tree 🌳 The tree starts at a Root node and fans out to a bunch of Leaf nodes, with Replication nodes in the middle doing the splitting. The Root has a Replication segment, and that gets stitched to Replication segments between the Leaf nodes and the Replication nodes. A Bud node (from [RFC9524]) is both a Replication node and a Leaf node 🎀 Anywhere this doc says "Leaf node(s)," it should be read as "Leaf or Bud node(s)" 🫶

An SR P2MP Policy is what defines the Root and Leaf nodes of a P2MP tree 🦋 It can have one or more CPs, with optional constraints and/or optimization objectives ✨

A controller computes the PTIs of the CPs using the constraints and objectives from the CP, then instantiates a PTI by signaling Replication segments to the Root, Replication, and Leaf nodes 💅 A Path Computation Element (PCE) [RFC4655] is one example of a controller 👑 Other times, a PTI can get installed using NETCONF / YANG or the CLI on the Root, Replication, and Leaf nodes 🌸

The Replication segments of a PTI can be instantiated for SR-MPLS [RFC8660] and SRv6 [RFC8986] data planes, which means efficient packet replication inside the SR domain 🧚

This document updates the Replication-ID portion of the Replication segment identifier (Replication-SID) specified in Section 2 of [RFC9524] 💖

1.1. Terminology 📚

This section defines the terms this doc uses a lot. For the definitions of Replication segment and other related terms, plus Root, Leaf, and Bud nodes, check the Terminology section of [RFC9524] 🌈

SR P2MP Policy: An SR P2MP Policy is a framework for building P2MP trees in an SR domain by specifying Root and Leaf nodes 🎀

Tree-ID: An identifier of an SR P2MP Policy in the context of the Root node 🦋

Candidate path (CP): A CP of the SR P2MP Policy defines topological or resource constraints and optimization objectives that get used to compute and construct PTIs 💅

P2MP tree instance (PTI): A PTI of a CP is constructed by stitching Replication segments between the Root and Leaf nodes of an SR P2MP Policy. Its topology is decided by the constraints and optimization objective of the CP 🌳

Instance-ID: An identifier of a PTI in the context of the SR P2MP Policy 🌸

Tree-SID: The Replication-SID of the Replication segment at the Root node of a PTI 👑

1.2. Requirements Language 🔥

Here's the official key-word stuff 🫶 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜

2. SR P2MP Policy 🎀

An SR P2MP Policy is used to instantiate P2MP trees between Root and Leaf nodes in an SR domain 🌳 Heads up, multiple SR P2MP Policies can have identical Root nodes and identical sets of Leaf nodes 👀 An SR P2MP Policy has one or more CPs [RFC9256] 🦋

2.1. SR P2MP Policy Identification ✨

An SR P2MP Policy is uniquely identified by the tuple <Root, Tree-ID>, where:

  • Root: The IP address of the Root node of P2MP trees instantiated by the SR P2MP Policy 🧚
  • Tree-ID: A 32-bit unsigned integer that uniquely identifies the SR P2MP Policy in the context of the Root node 💅

2.2. Components of an SR P2MP Policy 🌸

An SR P2MP Policy consists of the following elements:

  • Leaf nodes: A set of nodes that terminate the P2MP trees of the SR P2MP Policy 🌈
  • Candidate paths: A set of possible paths that define constraints and optimization objectives for PTIs of the SR P2MP Policy 👑

An SR P2MP Policy and its CPs are provisioned on a controller (see Section 5) or the Root node or both, depending on the provisioning model 🫶 After provisioning, the Policy and its CPs get instantiated on the Root node or the controller using a signaling protocol 💖

That's the end of part 1 💜 Part 2 is coming up next, bestie 🦋✨

2.3. Candidate Paths and P2MP Tree Instances 🌸

okay so an SR P2MP Policy has one or more CPs (candidate paths) 💅 The tuple <Protocol-Origin, Originator, Discriminator>, as specified in Section 2.6 of [RFC9256], uniquely identifies a CP inside a given SR P2MP Policy. The Protocol-Origin, Originator, and Discriminator fields mean the same thing here as they do in Sections 2.3, 2.4, and 2.5 of [RFC9256], respectively. Consistency is giving ✨

The Root node picks the active CP using the tiebreaking rules in Section 2.9 of [RFC9256]. 👑

A CP can come with topological and/or resource constraints and optimization objectives, and those shape how the PTIs (P2MP Tree Instances) of that CP get computed. 🎀

A CP can have zero or more PTIs. Zero is a real option! If the controller can't compute a P2MP tree from the network topology given the CP's constraints and/or optimization objectives, the CP just doesn't have a PTI. 💀 A CP can also have more than one PTI at once, like during the Make-Before-Break procedure (see Section 5.3) when the network state changes. BUT one and only one PTI MUST be the active instance of the CP. If more than one PTI of a CP is active at the same time, and that CP is the active CP of the SR P2MP Policy, then duplicate traffic may be delivered to the Leaf nodes. Not the vibe 😭

Each PTI is identified by an Instance-ID. This is an unsigned 16-bit number that's unique in the context of the CP's SR P2MP Policy. 🧚

PTIs are instantiated using Replication segments. Section 2 of [RFC9524] specifies the Replication-ID of the Replication segment control plane identifier tuple as a variable-length field that can be modified depending on how the Replication segment is used. Length is an imprecise indicator of the actual structure, though, so this document updates the Replication-ID of the control plane identifier of a Replication segment [RFC9524] to be the tuple <Root, Tree-ID, Instance-ID>. Here, <Root, Tree-ID> identifies the SR P2MP Policy, and Instance-ID identifies the PTI within that policy. The Replication segments used to instantiate a PTI are therefore identified in the control plane by <Root, Tree-ID, Instance-ID, Node-ID>. As per Section 2 of [RFC9524], for a simple use case the Replication-ID is a 32-bit number. To map that use case onto the tuple defined here, the Root MUST be zero (0.0.0.0 for IPv4 and :: for IPv6), the Instance-ID MUST be zero, and the 32-bit Tree-ID effectively makes the tuple <[0.0.0.0 or ::], Tree-ID, 0, Node-ID>. 🧩

PTIs may have different tree topologies because the CPs in an SR P2MP Policy (and across different policies) may have differing constraints and optimization objectives. Even within a given CP, two PTIs of that CP, say during the Make-Before-Break procedure, are likely to have different tree topologies because the network state changed. Since the PTIs may have different tree topologies, their replication states also differ at various nodes in the SR domain. So each PTI has its own Replication segment and a unique Replication-SID in the data plane at a given node in the SR domain. 🦋

A controller designates the active instance of a CP at the Root node of the SR P2MP Policy by signaling this state through the protocol used to instantiate the Replication segment of that instance. 🫶

This document focuses on using a controller to compute and instantiate PTIs of SR P2MP Policy CPs. It's also feasible to provision an explicit CP in an SR P2MP Policy with a static tree topology using NETCONF/YANG or CLI. Just note that a static tree topology will not adapt to any changes in the network state of an SR domain. Explicit CPs may be provisioned on the controller or on the Root node. When an explicit CP is provisioned on the controller, the controller bypasses the compute stage and directly instantiates the PTIs in the SR domain. When an explicit CP is provisioned on the Root node, the Root node instantiates the PTIs in the SR domain. The exact procedures for provisioning an explicit CP and for the signaling from the Root node to instantiate the PTIs are outside the scope of this document. 📦

3. Steering Traffic into an SR P2MP Policy 🚦

The Replication-SID of the Replication segment at the Root node is referred to as the Tree-SID of a PTI. It is RECOMMENDED that the Tree-SID also be used as the Replication-SID for the Replication segments at the intermediate Replication nodes and the Leaf nodes of the PTI, because it simplifies operations and troubleshooting. However, the Replication-SIDs of the Replication segments at the intermediate Replication nodes and the Leaf nodes MAY differ from the Tree-SID. For SRv6, the Replication-SID is the FUNCT portion of the SRv6 segment ID (SID) [RFC8986] [RFC9524]. Even if the Tree-SID is the Replication-SID of all the Replication segments of a PTI, the locator (LOC) portion of the SRv6 SID [RFC8986] differs for the Root node, the intermediate Replication nodes, and the Leaf nodes of the PTI. 🌈

An SR P2MP Policy has a Binding SID (BSID). The BSID is used to steer traffic into an SR P2MP Policy, as described below, when the Root node is not the ingress node of the SR domain where the traffic arrives. Packets are steered from the ingress node to the Root node using a segment list with the BSID as the last segment in the list. In this case, it is RECOMMENDED that the BSID of an SR P2MP Policy SHOULD be constant throughout the lifetime of the policy, so the steering of traffic to the Root node remains unchanged. The BSID of an SR P2MP Policy MAY be the Tree-SID of the active P2MP instance of the active CP of the policy. In this case, the BSID of an SR P2MP Policy changes when the active CP or the active PTI of the SR P2MP Policy changes. Note that the BSID is not required to steer traffic into an SR P2MP Policy when the Root node of an SR P2MP Policy is also the ingress node of the SR domain where the traffic arrives. 🧭

The Root node can steer an incoming packet into an SR P2MP Policy using one of the following methods:

  • Local-policy-based forwarding: The Root node maps the incoming packet to the active PTI of the active CP of an SR P2MP Policy based on local forwarding policy, and the packet is replicated with the encapsulated Replication-SIDs of the downstream nodes. The procedures to map an incoming packet to an SR P2MP Policy are out of scope of this document. It is RECOMMENDED that an implementation provide a mechanism to examine the result of applying the local forwarding policy, i.e., provide information about the traffic mapped to an SR P2MP Policy and the active CP and active PTI of the policy. 🔍
  • Tree-SID-based forwarding: The BSID in an incoming packet, which may be the Tree-SID of the active PTI, is used to map the packet to the active PTI. The BSID in the incoming packet is replaced with the Tree-SID of the active PTI of the active CP, and the packet is replicated with the Replication-SIDs of the downstream nodes. 🌟

For local-policy-based forwarding with SR-MPLS, the Root node SHOULD set the TTL in the encapsulating MPLS header so that the replicated packet can reach the furthest Leaf node. The Root MAY set the TTL in the encapsulating MPLS header from the payload. In this case, the TTL may not be sufficient for the replicated packet to reach the furthest node. For SRv6, Section 2.2 of [RFC9524] provides guidance for setting the IPv6 Hop Limit of the encapsulating IPv6 header. ⏱️

4. P2MP Tree Instance 🌳

A PTI within an SR domain establishes a forwarding structure that connects a Root node to a set of Leaf nodes via a series of intermediate Replication nodes. The tree consists of:

  • A Replication segment at the Root node.
  • Zero or more Replication segments at intermediate Replication nodes.
  • Replication segments at the Leaf nodes.

4.1. Replication Segments at Leaf Nodes 🍃

A specific service is identified by a service context in a packet. A PTI is usually associated with one and only one multipoint service. On a Leaf node of such a multipoint service, the transport identifier (the Tree-SID or the Replication-SID of the Replication segment at a Leaf node) is also associated with the service context. That's because it's not always feasible to separate the transport and the service context with efficient replication in the core, since a) multipoint services may have differing sets of endpoints and b) downstream allocation of a service context cannot be encoded in packets replicated in the core. 🧠

A PTI can be associated with one or more multipoint services on the Root and Leaf nodes. In SR-MPLS deployments, if it is known a priori that the multipoint services mapped to an SR-MPLS PTI can be uniquely identified with their service label, a controller MAY opt to not instantiate Replication segments at Leaf nodes. In such cases, Replication nodes upstream of the Leaf nodes can remove the Tree-SID from the packet before forwarding it. A multipoint service context allocated from an upstream assigned label or a Domain-wide Common Block (DCB), as specified in [RFC9573], is an example of a globally unique context that facilitates this optimization. 🪄

In SRv6 deployments, Replication segments of a PTI MUST be instantiated on the Leaf nodes of the tree, since behavior like Penultimate Hop Popping (PHP) is not feasible because the Tree-SID is carried in the IPv6 Destination Address field of the outer IPv6 header. If two or more multipoint services are mapped to one SRv6 PTI, an SRV6 SID representing the service context is assigned by the Root node or assigned from the DCB. This SRv6 SID MUST be encoded as the last segment in the Segment List of the Segment Routing Header [RFC8754] by the Root node, so that the packet processing context (PPC) for the service can be derived at a Leaf node, as described in Section 2.2 of [RFC9524]. 💖

4.2. Shared Replication Segments 🤝

A Replication segment MAY be shared across different PTIs. One simple use of a shared Replication segment is local protection on a Replication node. Picture a Replication node, say node X, that has multiple PTIs. Assume the Replication segments of these PTIs replicate to a downstream node, say node Y, amongst other downstream nodes. Node Y is a common downstream node of these Replication segments at node X. A Replication segment is established to protect the adjacency or path between node X and node Y, and this Replication segment can be shared across all the Replication segments of the PTIs replicating from node X to node Y. 🛡️

A shared Replication segment MUST be identified using a Root set to zero (0.0.0.0 for IPv4 and :: for IPv6), an Instance-ID set to zero, and a Tree-ID that is unique within the context of the node where the Replication segment is instantiated. The Root is zero because a shared Replication segment is not associated with a particular SR P2MP Policy or PTI. Note that the shared Replication-SID conforms with the updated Replication-ID definition in Section 2.3. 🫧

It is possible for different PTIs to share a P2MP tree at a Replication node. This allows a common sub-tree to be shared across PTIs whose tree topologies are identical in some portion of an SR domain. The procedures to share a P2MP tree across PTIs are outside the scope of this document. 🌷

4.3. Packet Forwarding in a P2MP Tree Instance 🦋

okay so when a packet gets steered into a PTI, the Replication segment at the Root node is the one doing the replicating 💅 it makes copies and sends them on to its downstream nodes ✨

  • Every replicated packet carries the Replication-SID of the Replication segment at the downstream node 🎀
  • A downstream node can be one of two things:
    • a Leaf node 🍓, and then the replication process just ends right there, or
    • an intermediate Replication node 🌸, which keeps replicating the packet through its own Replication segments until it reaches all the Leaf nodes 😭

A Replication node and a downstream node don't have to be neighbors 👀 when they aren't adjacent, the replicated packet has to travel a path to get there. For SR-MPLS, that happens by inserting one or more SIDs in front of the downstream Replication-SID 🧚. For SRv6, the LOC [RFC8986] of the downstream Replication-SID can guide the packet to the downstream node, or you can use an optional segment list to steer the copy onto a specific path to that node 🛤️. If you want the deets on SRv6 replication to a non-adjacent downstream node and the IPv6 Hop Limit stuff, check Section 2.2 of [RFC9524] 🤓

5. Using a Controller to Build a P2MP Tree 👑

A controller gets instantiated or provisioned with the SR P2MP Policy and its CPs, and then it computes and instantiates PTIs in an SR domain 🧠 how the provisioning or instantiation actually works on a controller is out of scope for this doc, so we're not diving into that here 🙈

5.1. SR P2MP Policy on a Controller 🎀

An SR P2MP Policy gets provisioned on a controller by an entity that can be an operator, a network node, or even a machine 🤖. That entity specifies the addresses of the Root, the set of Leaf nodes, and the CPs. In this case, the policy and its CPs get instantiated on the Root node using a signaling protocol 📡. It also works the other way around: the SR P2MP Policy, its Leaf nodes, and the CPs can be provisioned on the Root node and then instantiated on the controller with a signaling protocol. The procedures and mechanisms for provisioning and instantiating an SR P2MP Policy and its CPs on a controller or a Root node are outside the scope of this document 💅

The possible constraints and optimization objectives of a CP are described in Section 3 of [SR-POLICY]. Other constraints and optimization objectives MAY be used for P2MP tree computation ✨

5.2. Controller Functions 🧚

A controller does the following things in general:

  • Topology Discovery 🗺️: a controller discovers network topology across Interior Gateway Protocol (IGP) areas, levels, or Autonomous Systems (ASes).
  • Capability Exchange 🤝: a controller discovers a node's capability to participate in an SR P2MP Policy, and it also advertises its own capability to support the SR P2MP Policy.

5.3. P2MP Tree Compute 🌳

A controller computes one or more PTIs for the CPs of an SR P2MP Policy. A CP may not have any PTIs if a controller can't compute a P2MP tree for it 😬

A controller MUST compute a P2MP tree so that there are no loops in the tree at steady state, as required by [RFC9524]. No loops, no drama 🙅‍♀️

A controller SHOULD modify a PTI of a CP when it detects a change in the network topology, if the change affects the tree instance or when a better path can be found based on the new network state. Alternatively, the controller MAY decide to implement a Make-Before-Break approach to minimize traffic loss 🦋. The controller can do this by creating a new PTI, activating the new instance once it's instantiated in the network, and then removing the old PTI. Smooth transition era ✨

5.4. SID Management 🪪

The controller assigns the Replication-SIDs for the Replication segments of the PTI 💖

The Replication-SIDs of a PTI of a CP of an SR P2MP Policy can be either dynamically assigned by the controller or statically assigned by the entity provisioning the SR P2MP Policy 🌈

For SR-MPLS, a Replication-SID may be assigned from the SR Local Block (SRLB) or the SR Global Block (SRGB) [RFC8402]. It is RECOMMENDED to assign a Replication-SID from the SRLB, since Replication segments are local to each node of the PTI 🎯. It is NOT RECOMMENDED to allocate a Replication-SID from the SRGB, since this block is globally significant in the SR domain and it may get depleted if a significant number of PTIs are instantiated in the SR domain 😱

Section 3 recommends that the Tree-SID be used as the Replication-SIDs for all the Replication segments of a PTI. It may be feasible to allocate the same Tree-SID value for all the Replication segments if the blocks used for allocation are not identical on all the nodes of the PTI, or if the particular Tree-SID value in the block is assigned to some other SID on some node 🧩

A BSID is also assigned for the SR P2MP Policy. The controller MAY decide to not assign a BSID and allow the Root node of the SR P2MP Policy to assign the BSID. It is RECOMMENDED to assign the BSID of an SR P2MP Policy from the SRLB for SR-MPLS 💜

The controller MAY be provisioned with a reserved block or multiple reserved blocks for assigning Replication-SIDs and/or BSIDs for SR P2MP Policies. A single block may be reserved for the whole SR domain, or dedicated blocks can be reserved for each node or a group of nodes in the SR domain. These blocks MAY overlap with either the SRGB, the SRLB, or both. The procedures for provisioning these reserved blocks, and for deconflicting assignments from these reserved blocks with overlapping SRLB or SRGB blocks, are outside the scope of this document 🙃

A controller may not be aware of all the assignments of SIDs from the SRGB or the SRLB of the SR domain. If reserved blocks are not used, the assignment of Replication-SIDs or BSIDs of SR P2MP Policies from these blocks may conflict with other SIDs 😬

5.5. Instantiating P2MP Tree Instance on Nodes 🚀

After computing P2MP trees, the controller instantiates the Replication segments that compose the PTIs in the SR domain using signaling protocols such as the Path Computation Element Communication Protocol (PCEP) [SR-P2MP-PCEP], BGP [P2MP-BGP], or other mechanisms such as NETCONF/YANG [SR-P2MP-YANG], etc. The procedures for the instantiation of the Replication segments in an SR domain are outside the scope of this document.

A node SHOULD report a successful instantiation of a Replication segment. The exact procedure for reporting this is outside the scope of this document.

Instantiation of a Replication segment on a node may fail, e.g., when the Replication-SID conflicts with another SID on the node. The node SHOULD report this, preferably with a reason for the failure, using a signaling protocol. The exact procedure for reporting this failure is outside the scope of this document 😤

If the instantiation of a Replication segment on a node fails, the controller SHOULD attempt to re-instantiate the Replication segment. There SHOULD be an upper bound on the number of attempts. If the instantiation of a Replication segment ultimately fails after the allowed number of attempts, the controller SHOULD generate an alert via mechanisms like syslog. These alerts SHOULD be rate-limited to protect the logging facility in case Replication segment instantiation fails on multiple nodes. The controller MAY decide to tear down the PTI if the instantiations of some of the Replication segments of the instance fail. The controller is RECOMMENDED to tear down the PTI if the instantiation of the Replication segment on the Root node fails. The controller can employ different strategies to retry instantiating a PTI after a failure. These are out of scope of this document.

A PTI should be instantiated within a reasonable time, especially if it is the active PTI of an SR P2MP Policy. One approach is for the controller to instantiate the Replication segments in a batch. For example, the controller instantiates the Replication segments of the Leaf nodes and the intermediate Replication nodes first. If all of these Replication segments are successfully instantiated, the controller then proceeds to instantiate the Replication segment at the Root node. If the Replication segment instantiation at the Root node succeeds, the controller can immediately activate the instance if it needs to carry traffic of the SR P2MP Policy. A controller can adopt a similar approach when instantiating the new PTI for the Make-Before-Break procedure ✨

5.6. Protection 🛡️

5.6.1. Local Protection 🔒

A network link, node, or replication branch on a PTI can be protected using SR Policies [RFC9256]. The backup SR Policies are associated with replication branches of a Replication segment and are programmed in the data plane in order to minimize traffic loss when the protected link/node fails. The segment list of the backup SR Policy is imposed on the downstream Replication-SID of a replication branch to steer the traffic on the backup path.

It is also possible to use a node local Loop-Free Alternate [RFC5286] or Topology Independent Loop-Free Alternate (TI-LFA) [RFC9855] protection, and a Micro-Loop [RFC5715] or SR Micro-Loop [SR-LOOP] prevention mechanism, to protect the links/nodes of a PTI 🧯

5.6.2. Path Protection 🧭

A controller can create a disjoint backup tree instance for providing end-to-end tree protection if the topology permits. This can be achieved by having a backup CP with constraints and/or optimization objectives that ensure its PTIs are disjoint from the PTIs of the primary/active CP. Backup tree, main character backup 💜

6. IANA Considerations 📋

Good news: this document has no IANA actions, so there's nothing to register here 🎀

7. Security Considerations 🔐

This section is seriously important, so pay attention, bestie 😤

This document describes how a PTI can be created in an SR domain by stitching Replication segments together. Some security considerations for Replication segments outlined in [RFC9524] are also applicable to this document. Following is a brief reminder of those security considerations.

An SR domain needs protection from outside attackers as described in [RFC8402], [RFC8754], and [RFC8986] 🚨

Failure to protect the SR-MPLS domain by correctly provisioning MPLS support per interface permits attackers from outside the domain to send packets to receivers of the multipoint services that use the SR P2MP Policies provisioned within the domain 🚨

Failure to protect the SRv6 domain with inbound Infrastructure Access Control Lists (IACLs) on external interfaces, combined with failure to implement the method described in RFC 2827 [BCP38] or apply IACLs on nodes provisioning SIDs, permits attackers from outside the SR domain to send packets to the receivers of multipoint services that use the SR P2MP Policies provisioned within the domain 🚨

Incorrect provisioning of Replication segments by a controller that computes SR PTI can result in a chain of Replication segments forming a loop. In this case, replicated packets can create a storm until MPLS TTL (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero 🌪️ a packet storm, truly unhinged

The control plane protocols (like PCEP, BGP, etc.) used to instantiate Replication segments of SR PTI can leverage their own security mechanisms such as encryption, authentication filtering, etc.

For SRv6, [RFC9524] describes an exception for the ICMPv6 Parameter Problem message with Code 2. If an attacker is able to inject a packet into a multipoint service with the source address of a node and with an extension header using an unknown option type marked as mandatory, then a large number of ICMPv6 Parameter Problem messages can cause a denial-of-service attack on the source node 💀

8. References 📚

8.1. Normative References

Okay bestie, these are the must-read ones 📚✨ The whole spec leans on them, so no skipping 💅

8.2. Informative References

These ones are the extra reading. Helpful, not strictly required, but so worth a peek 🦋

Appendix A. Illustration of the SR P2MP Policy and P2MP Tree 🎀

Okay, let's look at a little topology together 🧚 Here's the setup:

                                  R3------R6
                     Controller--/         \
                         R1----R2----R5-----R7
                                 \         /
                                  +--R4---+

                       Figure 1: SR Topology

In these examples, the Node-SID of a node Rn is N-SIDn, and the Adjacency-SID from node Rm to node Rn is A-SIDmn. The interface between Rm and Rn is Lmn. Easy peasy 💖

For SRv6, you'll need to be familiar with SRv6 Network Programming [RFC8986] to follow along 🌸

  • 2001:db8::/32 is an IPv6 block allocated by a Regional Internet Registry (RIR) to the operator.
  • 2001:db8:0::/48 is dedicated to the internal address space.
  • 2001:db8:cccc::/48 is dedicated to the internal SRv6 SID space.
  • We assume a location is expressed in 64 bits and a function is expressed in 16 bits.
  • Node k has a classic IPv6 loopback address 2001:db8::k/128, which is advertised in the IGP.
  • Node k has 2001:db8:cccc:k::/64 for its local SID space. Its SIDs will be explicitly assigned from that block.
  • Node k advertises 2001:db8:cccc:k::/64 in its IGP.
  • Function :1:: (function 1, for short) represents the End function with Penultimate Segment Pop (PSP) support.
  • Function :Cn:: (function Cn, for short) represents the End.X function to node n.
  • Function :C1n: (function C1n for short) represents the End.X function to node n with Ultimate Segment Decapsulation (USD).

Each node k has:

  • An explicit SID instantiation 2001:db8:cccc:k:1::/128 bound to an End function with additional support for PSP
  • An explicit SID instantiation 2001:db8:cccc:k:Cj::/128 bound to an End.X function to neighbor J with additional support for PSP
  • An explicit SID instantiation 2001:db8:cccc:k:C1j::/128 bound to an End.X function to neighbor J with additional support for USD

Now the setup 👑 Assume a controller is provisioned with the following SR P2MP Policy at Root R1 with Tree-ID T-ID:

SR P2MP Policy <R1,T-ID>:
 Leaf nodes: {R2, R6, R7}
 candidate-path 1:
   Optimize: IGP metric
   Tree-SID: T-SID1

The controller is responsible for computing a PTI of the CP. In this example, we assume one active PTI with Instance-ID I-ID1. Assume the controller instantiates PTIs by signaling Replication segments, i.e., the Replication-ID of these Replication segments is <Root, Tree-ID, Instance-ID>. All Replication segments use the Tree-SID T-SID1 as the Replication-SID. For SRv6, assume the Replication-SID at node k, bound to an End.Replicate function, is 2001:db8:cccc:k:fa::/128.

A.1. P2MP Tree with Non-Adjacent Replication Segments

Assume the controller computes a PTI with Root node R1, Intermediate and Leaf node R2, and Leaf nodes R6 and R7. The controller instantiates the instance by stitching Replication segments at R1, R2, R6, and R7. The Replication segment at R1 replicates to R2. The Replication segment at R2 replicates to R6 and R7. Note that nodes R3, R4, and R5 do not have any Replication segment state for the tree 🙈

A.1.1. SR-MPLS

The Replication segment state at nodes R1, R2, R6, and R7 is shown below. Let's go node by node 🦋

Replication segment at R1:

Replication segment <R1,T-ID,I-ID1,R1>:
 Replication-SID: T-SID1
 Replication State:
   R2: <T-SID1->L12>

Replication to R2 steers a packet directly to the node on interface L12.

Replication segment at R2:

Replication segment <R1,T-ID,I-ID1,R2>:
 Replication-SID: T-SID1
 Replication State:
   R2: <Leaf>
   R6: <N-SID6, T-SID1>
   R7: <N-SID7, T-SID1>

R2 is a Bud node. It performs the role of a Leaf as well as a transit node replicating to R6 and R7. Replication to R6, using N-SID6, steers a packet via IGP shortest path to that node. Replication to R7, using N-SID7, steers a packet via IGP shortest path to R7 via either R5 or R4 based on ECMP hashing. ✨

Replication segment at R6:

Replication segment <R1,T-ID,I-ID1,R6>:
 Replication-SID: T-SID1
 Replication State:
   R6: <Leaf>

Replication segment at R7:

Replication segment <R1,T-ID,I-ID1,R7>:
 Replication-SID: T-SID1
 Replication State:
   R7: <Leaf>

When a packet is steered into the active instance CP 1 of the SR P2MP Policy at R1, here's the tea ☕

  • Since R1 is directly connected to R2, R1 performs the PUSH operation with just the <T-SID1> label for the replicated copy and sends it to R2 on interface L12.
  • R2, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload. For replication to R6, R2 performs a PUSH operation of N-SID6 to send the <N-SID6,T-SID1> label stack to R3. R3 is the penultimate hop for N-SID6; it performs PHP, which corresponds to the NEXT operation, and the packet is then sent to R6 with <T-SID1> in the label stack. For replication to R7, R2 performs a PUSH operation of N-SID7 to send the <N-SID7,T-SID1> label stack to R4, which is one of the IGP ECMP next hops (R5 is other) towards R7. R4 is the penultimate hop for N-SID7; it performs PHP, which corresponds to the NEXT operation, and the packet is then sent to R7 with <T-SID1> in the label stack. 💅
  • R6, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload. 🫶
  • R7, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload. 🌈

A.1.2. SRv6 🦋

okay so for SRv6, the replicated packet from R2 to R7 has to go through R4 using an SR Policy called Policy27 💅 That policy has one SID in its segment list: the End.X function with USD of R4 to R7. Here's the Replication segment state at R1, R2, R6, and R7, lowkey so pretty 🎀

Policy27: <2001:db8:cccc:4:c17::>

Replication segment at R1:

Replication segment <R1,T-ID,I-ID1,R1>:
 Replication-SID: 2001:db8:cccc:1:fa::
 Replication State:
   R2: <2001:db8:cccc:2:fa::->L12>

Replication to R2 steers a packet directly to the node on interface L12. Simple and clean ✨

Replication segment at R2:

Replication segment <R1,T-ID,I-ID1,R2>:
 Replication-SID: 2001:db8:cccc:2:fa::
 Replication State:
   R2: <Leaf>
   R6: <2001:db8:cccc:6:fa::>
   R7: <2001:db8:cccc:7:fa:: -> Policy27>

R2 is a Bud node, which means it's doing two jobs at once 🫶 It acts as a Leaf and also as a transit node replicating to R6 and R7. Replication to R6 steers a packet via the IGP shortest path to that node. Replication to R7, via an SR Policy, first encapsulates the packet using H.Encaps and then steers the outer packet to R4. The End.X USD on R4 decapsulates the outer header and sends the original inner packet on to R7. Main character energy, honestly 👑

Replication segment at R6:

Replication segment <R1,T-ID,I-ID1,R6>:
 Replication-SID: 2001:db8:cccc:6:fa::
 Replication State:
   R6: <Leaf>

Replication segment at R7:

Replication segment <R1,T-ID,I-ID1,R7>:
 Replication-SID: 2001:db8:cccc:7:fa::
 Replication State:
   R7: <Leaf>

Now the fun part, the packet journey 🧚 When a packet (A,B2) gets steered into the active instance of CP 1 of the SR P2MP Policy at R1 using the H.Encaps.Replicate behavior:

  • Since R1 is directly connected to R2, R1 sends the replicated copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on interface L12.
  • R2, as a Leaf, removes the outer IPv6 header and delivers the payload. R2, as a Bud node, also replicates the packet.
    • For replication to R6, R2 sends (2001:db8::1, 2001:db8:cccc:6:fa::) (A,B2) to R3. R3 forwards the packet using the 2001:db8:cccc:6::/64 packet to R6.
    • For replication to R7 using Policy27, R2 encapsulates and sends (2001:db8::2, 2001:db8:cccc:4:C17::) (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R4. R4 performs the End.X USD behavior, decapsulates the outer IPv6 header, and sends (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R7.
  • R6, as a Leaf, removes the outer IPv6 header and delivers the payload.
  • R7, as a Leaf, removes the outer IPv6 header and delivers the payload.

A.2. P2MP Tree with Adjacent Replication Segments 🌸

okay this one is giving clean geometry 📐 Let's say the controller computes a PTI with Root node R1, Intermediate and Leaf node R2, Intermediate nodes R3 and R5, and Leaf nodes R6 and R7. The controller instantiates the PTI by stitching Replication segments at R1, R2, R3, R5, R6, and R7. The Replication segment at R1 replicates to R2. The Replication segment at R2 replicates to R3 and R5. The Replication segment at R3 replicates to R6. The Replication segment at R5 replicates to R7. Note that node R4 does not have any Replication segment state for the tree. R4 is literally not involved, and that's iconic 🙈

A.2.1. SR-MPLS 🍓

The Replication segment state at nodes R1, R2, R3, R5, R6, and R7 is shown below.

Replication segment at R1:

Replication segment <R1,T-ID,I-ID1,R1>:
 Replication-SID: T-SID1
 Replication State:
   R2: <T-SID1->L12>

Replication to R2 steers a packet directly to the node on interface L12.

Replication segment at R2:

Replication segment <R1,T-ID,I-ID1,R2>:
 Replication-SID: T-SID1
 Replication State:
   R2: <Leaf>
   R3: <T-SID1->L23>
   R5: <T-SID1->L25>

R2 is a Bud node. It's the Leaf and a transit node replicating to R3 and R5 at the same time 💅 Replication to R3 steers a packet directly to the node on L23. Replication to R5 steers a packet directly to the node on L25.

Replication segment at R3:

Replication segment <R1,T-ID,I-ID1,R3>:
 Replication-SID: T-SID1
 Replication State:
   R6: <T-SID1->L36>

Replication to R6 steers a packet directly to the node on L36.

Replication segment at R5:

Replication segment <R1,T-ID,I-ID1,R5>:
 Replication-SID: T-SID1
 Replication State:
   R7: <T-SID1->L57>

Replication to R7 steers a packet directly to the node on L57.

Replication segment at R6:

Replication segment <R1,T-ID,I-ID1,R6>:
 Replication-SID: T-SID1
 Replication State:
   R6: <Leaf>

Replication segment at R7:

Replication segment <R1,T-ID,I-ID1,R7>:
 Replication-SID: T-SID1
 Replication State:
   R7: <Leaf>

When a packet is steered into the SR P2MP Policy at R1:

  • Since R1 is directly connected to R2, R1 performs the PUSH operation with just the <T-SID1> label for the replicated copy and sends it to R2 on interface L12.
  • R2, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload. It also performs the PUSH operation on T-SID1 for replication to R3 and R5. For replication to R6, R2 sends the <T-SID1> label stack to R3 on interface L23. For replication to R5, R2 sends the <T-SID1> label stack to R5 on interface L25.
  • R3 performs the NEXT operation on T-SID1, performs a PUSH operation for replication to R6, and sends the <T-SID1> label stack to R6 on interface L36.
  • R5 performs the NEXT operation on T-SID1, performs a PUSH operation for replication to R7, and sends the <T-SID1> label stack to R7 on interface L57.
  • R6, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload.
  • R7, as a Leaf, performs the NEXT operation, pops the T-SID1 label, and delivers the payload.

A.2.2. SRv6 ✨

The Replication segment state at nodes R1, R2, R3, R5, R6, and R7 is shown below, and yes it's a whole vibe 🎀

Replication segment at R1:

Replication segment <R1,T-ID,I-ID1,R1>:
 Replication-SID: 2001:db8:cccc:1:fa::
 Replication State:
   R2: <2001:db8:cccc:2:fa::->L12>

Replication to R2 steers a packet directly to the node on interface L12.

Replication segment at R2:

Replication segment <R1,T-ID,I-ID1,R2>:
 Replication-SID: 2001:db8:cccc:2:fa::
 Replication State:
   R2: <Leaf>
   R3: <2001:db8:cccc:3:fa::->L23>
   R5: <2001:db8:cccc:5:fa::->L25>

R2 is a Bud node. It performs the role of a Leaf as well as a transit node replicating to R3 and R5. Replication to R3 steers a packet directly to the node on L23. Replication to R5 steers a packet directly to the node on L25.

Replication segment at R3:

Replication segment <R1,T-ID,I-ID1,R3>:
 Replication-SID: 2001:db8:cccc:3:fa::
 Replication State:
   R6: <2001:db8:cccc:6:fa::->L36>

Replication to R6 steers a packet directly to the node on L36.

Replication segment at R5:

Replication segment <R1,T-ID,I-ID1,R5>:
 Replication-SID: 2001:db8:cccc:5:fa::
 Replication State:
   R7: <2001:db8:cccc:7:fa::->L57>

Replication to R7 steers a packet directly to the node on L57.

Replication segment at R6:

Replication segment <R1,T-ID,I-ID1,R6>:
 Replication-SID: 2001:db8:cccc:6:fa::
 Replication State:
   R6: <Leaf>

Replication segment at R7:

Replication segment <R1,T-ID,I-ID1,R7>:
 Replication-SID: 2001:db8:cccc:7:fa::
 Replication State:
   R7: <Leaf>

When a packet (A,B2) is steered into the active instance of CP 1 of the SR P2MP Policy at R1 using the H.Encaps.Replicate behavior:

  • Since R1 is directly connected to R2, R1 sends the replicated copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on interface L12.
  • R2, as a Leaf, removes the outer IPv6 header and delivers the payload. R2, as a Bud node, also replicates the packet. For replication to R3, R2 sends (2001:db8::1, 2001:db8:cccc:3:fa::) (A,B2) to R3 on interface L23. For replication to R5, R2 sends (2001:db8::1, 2001:db8:cccc:5:fa::) (A,B2) to R5 on interface L25.
  • R3 replicates and sends (2001:db8::1, 2001:db8:cccc:6:fa::) (A,B2) to R6 on interface L36.
  • R5 replicates and sends (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R7 on interface L57.
  • R6, as a Leaf, removes the outer IPv6 header and delivers the payload.
  • R7, as a Leaf, removes the outer IPv6 header and delivers the payload.

Acknowledgements 💜

The authors would like to acknowledge Siva Sivabalan, Mike Koldychev, and Vishnu Pavan Beeram for their valuable input. Thank you, queens 🫶

Contributors 🌈

Clayton Hassen Bell Canada Vancouver Canada Email: clayton.hassen@bell.ca

Kurtis Gillis Bell Canada Halifax Canada Email: kurtis.gillis@bell.ca

Arvind Venkateswaran Cisco Systems, Inc. San Jose, United States of America Email: arvvenka@cisco.com

Zafar Ali Cisco Systems, Inc. United States of America Email: zali@cisco.com

Swadesh Agrawal Cisco Systems, Inc. San Jose, United States of America Email: swaagraw@cisco.com

Jayant Kotalwar Nokia Mountain View, United States of America Email: jayant.kotalwar@nokia.com

Tanmoy Kundu Nokia Mountain View, United States of America Email: tanmoy.kundu@nokia.com

Andrew Stone Nokia Ottawa Canada Email: andrew.stone@nokia.com

Tarek Saad Juniper Networks Canada Email: tsaad@juniper.net

Kamran Raza Cisco Systems, Inc. Canada Email: skraza@cisco.com

Anuj Budhiraja Cisco Systems, Inc. United States of America Email: abudhira@cisco.com

Mankamana Mishra Cisco Systems, Inc. United States of America Email: mankamis@cisco.com

Authors' Addresses 🦋

Rishabh Parekh (editor) Arrcus San Jose, United States of America Email: rishabh@arrcus.com

Daniel Voyer (editor) Cisco Systems, Inc. Montreal Canada Email: davoyer@cisco.com

Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com

Hooman Bidgoli Nokia Ottawa Canada Email: hooman.bidgoli@nokia.com

Zhaohui Zhang Juniper Networks Email: zzhang@juniper.net

📦 where this page comes from