Segment Routing Point-to-Multipoint Policy

A Multi-point service delivery can be realized with P2MP trees in a Segment Routing domain . A P2MP tree spans from a Root node to a set of Leaf nodes via intermediate Replication nodes. It consists of a Replication segment at the root node, stitched to one or more Replication segments at Leaf nodes and intermediate Replication nodes. A Bud node is a node that is both a Replication node and a Leaf node. Any mention of "Leaf node(s)" in this document should be considered as referring to "Leaf or Bud node(s)". A Segment Routing P2MP Policy defines the Root and Leaf nodes of a P2MP tree. It has one or more Candidate Paths (CP) with optional constraints and/or optimization objectives. A controller computes P2MP tree instances of a SR P2MP Policy, from the Root to Leaf nodes, of a Candidate Path using the constraints and objectives specified in the Candidate Path. Once computed, the controller instantiates a P2MP tree instance in the SR domain by signaling Replication segments to the Root, Replication and Leaf nodes. A Path Computation Element (PCE) is one example of such a controller. The Replication segments of a P2MP tree can be instantiated for both SR-MPLS and SRv6 data planes, enabling efficient packet replication within an SR domain.

This section defines terms used frequently in this document. Refer to Terminology section of for definition of Replication segment and other terms associated with it. SR P2MP Policy: A SR P2MP Policy is a mechanism to construct a P2MP tree in a SR domain by specifying a Root and Leaf nodes. Candidate Path: A Candidate Path of SR P2MP Policy defines topological or resource constraints and optimization objectives that are used to construct a P2MP Tree instances. P2MP Tree Instance: A P2MP tree instance in a SR domain is constructed by stitching Replication segments between Root and Leaf nodes of a SR P2MP Policy. A P2MP tree belongs to a Candidate Path and its topology is determined by constraints and optimization objective of the Candidate Path. This document uses terms P2MP tree instance and P2MP tree interchangeably.

An SR P2MP Policy is used to instantiate P2MP trees between a Root and Leaf nodes in an SR domain. It is similar to SR Policy . Like SR Policy, SR P2MP Policy has one or more Candidate Paths and uses same criteria to select the Active Candidate Path. However, SR P2MP Policies and SR Policies are independent and distinct entities in a SR domain.

A 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. This is equivalent to the Headend of SR Policy identifier tuple. Tree-ID: A 32-bit unsigned integer that uniquely identifies the P2MP Policy in the context of the Root node. This is equivalent to the Color of SR Policy identifier tuple. Note, SR P2MP Policy identification tuple does not have a member equivalent to Endpoint of SR Policy identifier tuple since SR P2MP Policies result in P2MP trees to a varying set of endpoints (Leaf nodes).

An SR P2MP Policy consists of the following elements: Leaf nodes: A set of nodes that terminate the P2MP trees of the P2MP Policy. Candidate Paths: A set of possible paths that define constraints and optimization objectives of P2MP trees of P2MP Policy. An SR P2MP Policy is provisioned on a controller (see Section ). The controller computes the P2MP tree instances of Candidate Paths of the policy and instantiates the necessary Replication segments at the Root, Replication and Leaf nodes of the trees. The Root and Tree-ID of the SR P2MP Policy are mapped to Replication-ID element of the Replication segment identifier .

An SR P2MP Policy has one or more CPs. Identification of a CP in context of the P2MP Policy is as specified in Section 2.9 of . A CP may include topological and/or resource constraints and optimization objectives which influence the computation of P2MP tree. The Root node selects the active Candidate Path based on the tie breaking rules defined in. A Candidate Path has zero or more P2MP tree instances. A P2MP tree instance is identified by an Instance-ID. This is an unsigned 16-bit number which is unique in context of the SR P2MP Policy of the Candidate Path. The Replication segments used to instantiate a P2MP tree instance are identified by the tuple: <Root, Tree-ID, Instance-ID, Node-ID>, where Root, Tree-ID of SR P2MP Policy and Instance-ID of the instance map to Replication-ID of Replication segment and Node-ID is as defined in . A controller designates an active instance of a CP at the Root node of SR P2MP Policy by signalling this state through the protocol used to instantiate the Replication segment of the instance.

The Tree-SID, as described in , serves as the data plane identifier of a P2MP tree instance. It is instantiated in the data plane at the Root node, intermediate Replication nodes, and Leaf nodes of the P2MP tree instance. The Tree-SID of the active instance of the active Candidate Path SHOULD be used as the Binding SID of the SR P2MP Policy. The Root node can steer an incoming packet into a SR P2MP Policy in one of following methods: Local Policy-Based forwarding: The Root node selects the active P2MP tree instance of the active Candidate Path of the SR P2MP Policy based on local policy. The procedures to map an incoming packet to a SR P2MP Policy are out of scope of this document. Tree-SID Based forwarding: The Binding SID (Tree-SID) in the incoming packet is used to map the packet to the appropriate P2MP tree instance.

A P2MP tree 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.

The Replication SID associated with the Replication segment at the Root node is referred to as the Tree-SID. The Tree-SID SHOULD also serve as the Replication-SID for the Replication segments at intermediate Replication nodes and Leaf nodes. However, the Replication segments at intermediate Replication nodes and Leaf nodes MAY use Replication-SIDs that differ from the Tree-SID.

A Replication segment MAY be shared across different P2MP tree instances, for example, in scenarios involving protection mechanisms. A shared Replication segment MUST be identified using a Root set to zero (0.0.0.0 for IPv4 and :: for IPv6) along with a Replication-ID that is unique within the context of the node where the Replication segment is instantiated. However, a shared Replication segment MUST NOT be associated with an SR P2MP tree.

A specific service is identified by a service context in a packet. A P2MP tree is usually associated with one and only one multi-point service. On a Leaf node of such a multi-point service, the transport identifier which is the Tree-SID or Replication SID at a Leaf node is also associated with the service context because it is not always feasible to separate the transport and service context with efficient replication in core since a) multi-point services may have differing sets of end-points, and b) downstream allocation of service context cannot be encoded in packets replicated in the core. A P2MP tree can associated with one or more multi-point services on the Root and Leaf nodes. In SR-MPLS deployments, if it is known a priori that multi-point services mapped to a P2MP tree can be uniquely identified within the SR domain, a controller MAY opt not to instantiate Replication segments at Leaf nodes. In such cases, Replication Nodes upstream of the Leaf nodes effectively implement Penultimate-Hop Popping behavior by removing the Tree-SID from the packet before forwarding it. A multi-point service context allocated from the Domain-wide Common Block (DCB), as specified in , is an example of a globally unique context that facilitates this optimization.

When a packet is steered into a P2MP tree instance, the Replication segment at the Root node performs packet replication and forwards copies to downstream nodes. Each replicated packet carries the Replication-SID of the Replication segment at the downstream node. A downstream node can be either: A Leaf node, in which case the replication process terminates. An intermediate Replication node, which further replicates the packet through its associated Replication segments until it reaches all Leaf nodes.

A controller is provisioned with SR P2MP Policy and its Candidate Paths to compute and instantiate P2MP trees in an SR domain. Once computed, the controller instantiates the Replication segments that compose the P2MP tree in the SR domain nodes using signalling protocols such as PCEP, BGP, NetConf, etc. The procedures for provisioning a controller and the instantiation of Replication segments in an SR domain are outside the scope of this document.

An entity (an operator, a network node or a machine) provisions a SR P2MP Policy on a controller by specifying the addresses of the Root, set of Leaf nodes Candidate Paths. The procedures and mechanisms for provisioning a controller are outside the scope of this document. Candidate Path constraints MAY include link color affinity, bandwidth, disjointness (link, node, SRLG), delay bound, link loss, flexible algorithm etc., and optimization objectives based on IGP or TE metric or link latency. Other constraints and optimization objectives MAY be used for P2MP tree computation. The Tree SID of a P2MP Tree instance of a Candidate Path of a SR P2MP Policy can be either dynamically assigned by the controller or statically assigned by entity provisioning the SR P2MP Policy.

A controller performs the following functions 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 SR P2MP tree as well as advertise its capability to compute P2MP trees.

A controller computes one or more P2MP tree instances for CPs of a SR P2MP Policy. A CP may not have any P2MP tree instance if a controller cannot compute a P2MP tree instance for it. A controller MUST compute a P2MP tree such that there are no loops in the tree at steady state as required by . A controller SHOULD modify a P2MP tree instance of a Candidate Path on detecting 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. In this case, the controller MAY create a new instance of a P2MP tree and remove the old instance of the tree from the network in order to minimize traffic loss.

Once a controller computes a P2MP tree instance for a CP of a SR P2MP Policy, it needs to instantiate the tree on the relevant network nodes via Replication segments. The controller can use various mechanisms to program the Replication segments as described below. Some examples of these mechanisms are PCEP, BGP and NetConf. The mechanism and procedures to signal Replication segments are outside the scope of this document.

A network link, node or path on the instance of a P2MP tree can be protected using SR policies computed by a controller. The backup SR policies are programmed in data plane in order to minimize traffic loss when the protected link/node fails. It is also possible to use node local Loop-Free Alternate protection and Micro-Loop Prevention mechanisms to protect link/nodes of P2MP tree.

A controller can create a disjoint backup tree instance for providing end-to-end path protection if the topology permits.

This document makes no request of IANA.

This document describes how a P2MP tree can be created in an SR domain by stitching Replication segments together. Some security considerations for Replication segments outlined in are also applicable to this document. Following is a brief reminder of the same. An SR domain needs protection from outside attackers as described in . 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 Multi-point services that use the SR P2MP trees 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 BCP 38 or apply IACLs on nodes provisioning SIDs, permits attackers from outside the SR domain to send packets to the receivers of Multi-point services that use the SR P2MP trees provisioned within the domain. Incorrect provisioning of Replication segments by a controller that computes SR P2MP tree instance can result in a chain of Replication segments forming a loop. In this case, replicated packets can create a storm till MPLS TTL (for SR-MPLS) or IPv6 Hop Limit (for SRv6) decrements to zero. The control plane protocols (like PCEP, BGP, etc.) used to instantiate Replication segments of SR P2MP tree instance can leverage their own security mechanisms such as encryption, authentication filtering etc. For SRv6, describes an exception for Parameter Problem Message, code 2 ICMPv6 Error messages. If an attacker is able to inject a packet into Multi-point service with source address of a node and with an extension header using 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.

The authors would like to acknowledge Siva Sivabalan, Mike Koldychev and Vishnu Pavan Beeram for their valuable inputs.

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 US Email: arvvenka@cisco.com Zafar Ali Cisco Systems, Inc. US Email: zali@cisco.com Swadesh Agrawal Cisco Systems, Inc. San Jose US Email: swaagraw@cisco.com Jayant Kotalwar Nokia Mountain View US Email: jayant.kotalwar@nokia.com Tanmoy Kundu Nokia Mountain View US 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. US Email:abudhira@cisco.com Mankamana Mishra Cisco Systems, Inc. US Email:mankamis@cisco.com

Consider the following topology:

In these examples, the Node-SID of a node Rn is N-SIDn and Adjacency-SID from node Rm to node Rn is A-SIDmn. Interface between Rm and Rn is Lmn. For SRv6, the reader is expected to be familiar with SRv6 Network Programming to follow the examples. This document re-uses SID allocation scheme, reproduced below, from Illustrations in SRv6 Network Programming 2001:db8::/32 is an IPv6 block allocated by a 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 expressed in 64 bits and a function 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 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 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 Assume a controller is provisioned with following SR P2MP Policy at Root R1 with Tree-ID T-ID:

: Leaf nodes: {R2, R6, R7} Candidate-path 1: Optimize: IGP metric Tree-SID: T-SID1 ]]> The controller is responsible for computing a P2MP tree instance of the Candidate Path. In this example, we assume one active instance of P2MP tree with Instance-ID I-ID1. Assume the controller instantiates P2MP trees by signalling Replication segments i.e. Replication-ID of these Replication segments is <Root, Tree-ID, Instance-ID>. All Replication segments use the Tree-SID T-SID1 as Replication-SID. For SRv6, assume the Replication-SID at node k, bound to an End.Replicate function, is 2001:db8:cccc:k:fa::/128.

Assume the controller computes a P2MP tree instance 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. Replication segment at R1 replicates to R2. Replication segment at R2 replicates to R6 and R7. Note nodes R3, R4 and R5 do not have any Replication segment state for the tree.

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

: Replication-SID: T-SID1 Replication State: R2: L12> ]]> Replication to R2 steers packet directly to the node on interface L12. Replication segment at R2:

: Replication-SID: T-SID1 Replication State: R2: R6: R7: ]]> R2 is a Bud node. It performs role of Leaf as well as a transit node replicating to R6 and R7. Replication to R6, using N-SID6, steers packet via IGP shortest path to that node. Replication to R7, using N-SID7, steers packet via IGP shortest path to R7 via either R5 or R4 based on ECMP hashing. Replication segment at R6:

: Replication-SID: T-SID1 Replication State: R6: ]]> Replication segment at R7:

: Replication-SID: T-SID1 Replication State: R7: ]]> When a packet is steered into the active instance Candidate Path 1 of SR P2MP Policy at R1: Since R1 is directly connected to R2, R1 performs PUSH operation with just <T-SID1> label for the replicated copy and sends it to R2 on interface L12. R2, as Leaf, performs NEXT operation, pops T-SID1 label and delivers the payload. For replication to R6, R2 performs a PUSH operation of N-SID6, to send <N-SID6,T-SID1> label stack to R3. R3 is the penultimate hop for N-SID6; it performs penultimate hop popping, 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 <N-SID7,T-SID1> label stack to R4, one of IGP ECMP nexthops towards R7. R4 is the penultimate hop for N-SID7; it performs penultimate hop popping, which corresponds to the NEXT operation and the packet is then sent to R7 with <T-SID1> in the label stack. R6, as Leaf, performs NEXT operation, pops T-SID1 label and delivers the payload. R7, as Leaf, performs NEXT operation, pops T-SID1 label and delivers the payload.

For SRv6, the replicated packet from R2 to R7 has to traverse R4 using a SR-TE policy, Policy27. The policy has one SID in segment list: End.X function with USD of R4 to R7 . The Replication segment state at nodes R1, R2, R6 and R7 is shown below.

]]> Replication segment at R1:

: Replication-SID: 2001:db8:cccc:1:fa:: Replication State: R2: <2001:db8:cccc:2:fa::->L12> ]]> Replication to R2 steers packet directly to the node on interface L12. Replication segment at R2:

: Replication-SID: 2001:db8:cccc:2:fa:: Replication State: R2: R6: <2001:db8:cccc:6:fa::> R7: <2001:db8:cccc:7:fa:: -> Policy27>]]> R2 is a Bud node. It performs role of Leaf as well as a transit node replicating to R6 and R7. Replication to R6, steers packet via IGP shortest path to that node. Replication to R7, via SR-TE policy, first encapsulates the packet using H.Encaps and then steers the outer packet to R4. End.X USD on R4 decapsulates outer header and sends the original inner packet to R7. Replication segment at R6:

: Replication-SID: 2001:db8:cccc:6:fa:: Replication State: R6: ]]> Replication segment at R7:

: Replication-SID: 2001:db8:cccc:7:fa:: Replication State: R7: ]]> When a packet (A,B2) is steered into the active instance of Candidate Path 1 of SR P2MP Policy at R1 using H.Encaps.Replicate behavior: Since R1 is directly connected to R2, R1 sends replicated copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on interface L12. R2, as Leaf removes 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 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 End.X USD behavior, decapsulates outer IPv6 header and sends (2001:db8::1, 2001:db8:cccc:7:fa::) (A,B2) to R7. R6, as Leaf, removes outer IPv6 header and delivers the payload. R7, as Leaf, removes outer IPv6 header and delivers the payload.

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

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

: Replication-SID: T-SID1 Replication State: R2: L12> ]]> Replication to R2 steers packet directly to the node on interface L12. Replication segment at R2:

: Replication-SID: T-SID1 Replication State: R2: R3: L23> R5: L25>]]> R2 is a Bud node. It performs role of Leaf as well as a transit node replicating to R3 and R5. Replication to R3, steers packet directly to the node on L23. Replication to R5, steers packet directly to the node on L25. Replication segment at R3:

: Replication-SID: T-SID1 Replication State: R6: L36> ]]> Replication to R6, steers packet directly to the node on L36. Replication segment at R5:

: Replication-SID: T-SID1 Replication State: R7: L57> ]]> Replication to R7, steers packet directly to the node on L57. Replication segment at R6:

: Replication-SID: T-SID1 Replication State: R6: ]]> Replication segment at R7:

: Replication-SID: T-SID1 Replication State: R7: ]]> When a packet is steered into the SR P2MP Policy at R1: Since R1 is directly connected to R2, R1 performs PUSH operation with just <T-SID1> label for the replicated copy and sends it to R2 on interface L12. R2, as Leaf, performs NEXT operation, pops T-SID1 label and delivers the payload. It also performs PUSH operation on T-SID1 for replication to R3 and R5. For replication to R6, R2 sends <T-SID1> label stack to R3 on interface L23. For replication to R5, R2 sends <T-SID1> label stack to R5 on interface L25. R3 performs NEXT operation on T-SID1 and performs a PUSH operation for replication to R6 and sends <T-SID1> label stack to R6 on interface L36. R5 performs NEXT operation on T-SID1 and performs a PUSH operation for replication to R7 and sends <T-SID1> label stack to R7 on interface L57. R6, as Leaf, performs NEXT operation, pops T-SID1 label and delivers the payload. R7, as Leaf, performs NEXT operation, pops T-SID1 label and delivers the payload.

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

: Replication-SID: 2001:db8:cccc:1:fa:: Replication State: R2: <2001:db8:cccc:2:fa::->L12> ]]> Replication to R2 steers packet directly to the node on interface L12. Replication segment at R2:

: Replication-SID: 2001:db8:cccc:2:fa:: Replication State: R2: R3: <2001:db8:cccc:3:fa::->L23> R5: <2001:db8:cccc:5:fa::->L25>]]> R2 is a Bud node. It performs role of Leaf as well as a transit node replicating to R3 and R5. Replication to R3, steers packet directly to the node on L23. Replication to R5, steers packet directly to the node on L25. Replication segment at R3:

: Replication-SID: 2001:db8:cccc:3:fa:: Replication State: R6: <2001:db8:cccc:6:fa::->L36> ]]> Replication to R6, steers packet directly to the node on L36. Replication segment at R5:

: Replication-SID: 2001:db8:cccc:5:fa:: Replication State: R7: <2001:db8:cccc:7:fa::->L57> ]]> Replication to R7, steers packet directly to the node on L57. Replication segment at R6:

: Replication-SID: 2001:db8:cccc:6:fa:: Replication State: R6: ]]> Replication segment at R7:

: Replication-SID: 2001:db8:cccc:7:fa:: Replication State: R7: ]]> When a packet (A,B2) is steered into the active instance of Candidate Path 1 of SR P2MP Policy at R1 using H.Encaps.Replicate behavior: Since R1 is directly connected to R2, R1 sends replicated copy (2001:db8::1, 2001:db8:cccc:2:fa::) (A,B2) to R2 on interface L12. R2, as Leaf, removes 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 Leaf, removes outer IPv6 header and delivers the payload. R7, as Leaf, removes outer IPv6 header and delivers the payload.