1. Introduction
[RFC 9524] defines a Replication segment that lets an SR node replicate traffic to multiple downstream nodes in an SR domain. A P2MP service can be realized with ingress replication, but that is inefficient when the same traffic crosses the same nodes and links on the way to multiple egress nodes.
RFC 9960 uses an SR P2MP Policy to define the Root and Leaf nodes of a P2MP tree. The tree spans from a Root node to Leaf nodes through intermediate Replication nodes. A Bud node is both a Replication node and a Leaf node; in this document, "Leaf node(s)" includes Leaf or Bud nodes.
A controller computes P2MP tree instances (PTIs) for the candidate paths (CPs) of an SR P2MP Policy, then instantiates the PTI by signaling Replication segments to Root, Replication, and Leaf nodes. A PCE is one possible controller; NETCONF/YANG or CLI provisioning can also be used in some deployments.
Replication segments of a PTI can be instantiated for SR-MPLS and SRv6 data planes. This document updates the Replication-ID portion of the Replication-SID specified in Section 2 of RFC 9524.
1.1. Terminology
- SR P2MP Policy: a framework for constructing 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): defines topological or resource constraints and optimization objectives used to compute and construct PTIs.
- P2MP tree instance (PTI): a tree built by stitching Replication segments between Root and Leaf nodes.
- 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
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when they appear in all capitals.