Segment Routing Point-to-Multipoint Policy
updates
- rfc-9524 — Segment Routing Replication for Multipoint Service Delivery
Extracted elements (30)
A controller may instantiate Replication segments in a batch, first at Leaf and intermediate nodes, then at the Root node. If Root instantiation succeeds, the instance can immediately be activated to carry traffic, minimizing the window of potential traffic disruption.
A PTI is usually associated with one and only one multipoint service at Leaf nodes because it is not always feasible to separate transport and service context with efficient replication in the core: multipoint services may have differing endpoint sets and downstream allocation of service context cannot be encoded in replicated packets.
The Replication-ID of the Replication segment control plane identifier was updated from a variable-length field (RFC 9524) to the structured tuple <Root, Tree-ID, Instance-ID> because length alone is an imprecise indicator of the actual structure of the Replication-ID.
In SR-MPLS deployments, if 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, allowing upstream Replication nodes to remove the Tree-SID before forwarding.
This document updates the Replication-ID portion of the Replication segment identifier specified in Section 2 of RFC 9524. Implementations of RFC 9524 must be updated to use the new structured tuple <Root, Tree-ID, Instance-ID> for control plane identification.
A controller MUST compute a P2MP tree such that there are no loops in the tree at steady state, as required by RFC 9524.
A controller SHOULD modify a PTI of a CP on detecting a change in network topology if the change affects the tree instance or when a better path can be found. Alternatively, the controller MAY implement a Make-Before-Break approach to minimize traffic loss.
A node SHOULD report a successful instantiation of a Replication segment. If instantiation fails, the node SHOULD report this, preferably with a reason for the failure, using a signaling protocol.
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.
For simple use cases where the Replication-ID is a 32-bit number (per RFC 9524), the Root MUST be zero (0.0.0.0 for IPv4 and :: for IPv6) and the Instance-ID MUST be zero, effectively mapping to <[0.0.0.0 or ::], Tree-ID, 0, Node-ID>.
For SR-MPLS, it is RECOMMENDED to assign a Replication-SID from the SRLB since Replication segments are local to each node. It is NOT RECOMMENDED to allocate from the SRGB since this block is globally significant and may be depleted if many PTIs are instantiated.
If Replication segment instantiation 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.
If two or more multipoint services are mapped to one SRv6 PTI, the SRv6 SID representing the service context MUST be encoded as the last segment in the Segment List of the Segment Routing Header by the Root node to derive the packet processing context at a Leaf node.
In SRv6 deployments, Replication segments of a PTI MUST be instantiated on 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.
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 when the Root node is not the ingress node.
It is RECOMMENDED that the Tree-SID be used as the Replication-SID for Replication segments at intermediate Replication nodes and Leaf nodes of the PTI to simplify operations and troubleshooting. However, these Replication-SIDs MAY differ from the Tree-SID.
One and only one PTI MUST be the active instance of a 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.
The controller is RECOMMENDED to tear down the PTI if the instantiation of the Replication segment on the Root node fails.
A Candidate Path (CP) of an SR P2MP Policy is uniquely identified by the tuple <Protocol-Origin, Originator, Discriminator> as specified in RFC 9256. The active CP is selected by the Root node using tiebreaking rules from Section 2.9 of RFC 9256.
A P2MP Tree Instance (PTI) consists of a Replication segment at the Root node, zero or more Replication segments at intermediate Replication nodes, and Replication segments at the Leaf nodes. Packet forwarding replicates at each node, forwarding copies toward downstream nodes until all Leaf nodes are reached.
A PTI is identified by an Instance-ID, which is an unsigned 16-bit number unique in the context of the SR P2MP Policy of the CP.
An SR P2MP Policy is uniquely identified by the tuple <Root, Tree-ID>, where Root is the IP address of the Root node and Tree-ID is a 32-bit unsigned integer unique in the context of the Root node.
For SR-MPLS, non-adjacent replication is achieved by inserting one or more SIDs before the downstream Replication-SID. For SRv6, the LOC portion of the downstream Replication-SID guides the packet, or an optional segment list steers it on a specific path.
Local protection of network links, nodes, or replication branches in a PTI can be achieved using SR Policies (RFC 9256). The segment list of the backup SR Policy is imposed on the downstream Replication-SID of a replication branch to steer traffic on the backup path.
Path protection is achieved by creating a disjoint backup tree instance with a backup CP whose constraints and/or optimization objectives ensure its PTIs are disjoint from the PTIs of the primary/active CP.
This document updates the Replication-ID of the control plane identifier of a Replication segment (RFC 9524) to be the tuple <Root, Tree-ID, Instance-ID>. Replication segments used to instantiate a PTI are identified by <Root, Tree-ID, Instance-ID, Node-ID>.
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 SR P2MP Policies provisioned within the domain.
Failure to protect the SRv6 domain with inbound IACLs on external interfaces, combined with failure to implement BCP 38 or apply IACLs on nodes provisioning SIDs, permits attackers from outside the SR domain to send packets to receivers of multipoint services.
For SRv6, if an attacker injects 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, a large number of ICMPv6 Parameter Problem messages can cause a denial-of-service attack on the source node.
Incorrect provisioning of Replication segments by a controller can result in a chain of Replication segments forming a loop. Replicated packets can create a packet storm until MPLS TTL (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero.