Nokia

Ottawa Canada hooman.bidgoli@nokia.com

Cisco Systems

Montreal Canada davoyer@cisco.com

Cisco Systems

San Jose USA abudhira@cisco.com

Arrcus

San Jose USA rishabh@arrcus.com

Ciena

Ottawa Canada ssivabal@ciena.com

Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable an architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths for SR-MPLS from a Root to a set of Leaf nodes.

The document defines a variant of the SR Policy called SR Point-to-Multipoint (P2MP) Policy for creation of P2MP trees. An SR P2MP Policy is constructed using one or more Replication segments () from a Root node to a set of Leaf nodes, optionally through a set of intermediate transit nodes that perform replication. An SR P2MP Policy is installed only on the Root node of a P2MP tree and consists of one or more Candidate Paths (CP). Each CP is made up of P2MP Tree Instances (PTI), and each PTI is constructed in the network via Replication segments. A Replication segment corresponds to the forwarding state of a P2MP segment on a particular node and provides forwarding instructions for the segment. As per , a P2MP service can be realized by two types of deployment, Ingress Replication spanning from the ingress node to the egress nodes of the service or a P2MP tree which spans from a Root node to a set of Leaf nodes via transit Replication nodes. For Ingress Replication , dataplane packet replication only occurs on the Root, which forwards individual copies of traffic to each Leaf directly over a Segment Routing path. The corresponding SR P2MP Policy consists of Replication segments only for the Root node and the Leaf nodes. A P2MP service delivery can be more efficient using a P2MP Tree. In this case, the corresponding SR P2MP Policy consists of Replication segments on the Root, Leaf, and Transit nodes which exist in the topology between the Root and Leaf nodes. The Root and Transit nodes perform dataplane packet replication along the tree as a packet traverses from the root towards each leaf. The PCE discovers the root and the leaves via different methods. As an example, the leaves and the root can be explicitly configured on the PCE or PCC can update the PCE with the identity of the root and the leaves when it discovers them via multicast protocols like MP-BGP and MVPN procedures or PIM. Once the controller is informed of the Root node and Leaf nodes, it can calculate the SR P2MP Policy and any of the required Replication segments from the Root node to the Leaf nodes. The computation may include traffic engineering criteria and any additional Service Level Agreements (SLAs) that are used to construct the tree. This document defines PCEP objects for MPLS SR P2MP Policy, TLVs, and the procedures to instantiate a P2MP Policy and Replication Segments. Only Stateful PCE is within the scope of this document, and the Stateless PCE is out of scope. Support for SRv6 P2MP Policy is also out of scope.

The readers of this document should familiarize themselves with the following documents and sections for terminology and details implementation of the SR P2MP Policy. Section 1.1 defines terms specific to SR Replication Segment and also explains the Node terminology in a multicast domain, including the Root Node, Leaf Node and a Bud Node. Section 2 defines terms and concepts specific to SR P2MP Policy including the CP and the PTI. In addition, the following section defines terms used frequently in this document. Refer to Terminology sections of , and for other terms used in Segment Routing. Unicast Segment Routing (SR): Standard Segment Routing constructs, capabilities and behavior which are not multicast or replication aware. Replication segment: A segment in SR domain that replicates packets. See , for details. Replication node: A node in SR domain which replicates packets based on Replication segment. Downstream nodes: A Replication segment replicates packets to a set of nodes. These nodes are Downstream nodes. Replication state: State held for a Replication segment at a Replication node. It is conceptually a list of replication branches to Downstream nodes. The list can be empty. Replication SID: Data plane identifier of a Replication segment. This is an SR-MPLS label or SRv6 Segment Identifier (SID). Point-to-Multipoint Service: A service that has one ingress node and one or more egress nodes. A packet is delivered to all the egress nodes. Transit node: alternative name for Replication node. Root node: An ingress node of a P2MP service. Leaf node: An egress node of a P2MP service. Bud node: A node that is both a Replication node and a Leaf node.

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 when, and only when, they appear in all capitals, as shown here.

After discovering the Root node and Leaf nodes, the PCE programs the PCCs with relevant information needed to create a P2MP Tree. An SR P2MP Policy is a variant of SR Policy; as such it inherits similar concepts as . An SR P2MP Policy is composed of a collection of CPs. CPs are computed by the PCE and can be used for P2MP Tree redundancy. Only a single CP may be active at each time. Each CP can be globally optimized, therefore it consists of multiple PTIs. A PTI can be considered as a P2MP LSP. If a CP needs to be globally optimized two or more PTIs can be programmed from the root to a set of leaves and via make-before-break procedures the CP can switch from the original PTI to the new optimized PTI. The forwarding states of these PTIs are built via Replication segments. Each PTI initiated on the root has its own set of replication segments on the Root, Transit and Leaf nodes. A Replication segment is a set of forwarding instructions on a specific node. Each instruction may be a PUSH or SWAP operation before forwarding out of an interface, or a POP action on bud and leaf nodes. PCE MAY also calculate and download additional information for the replication segments, such as protection next-hops for link protection.

The basis for a stateful PCE, and reuses the following objects or a new format of the objects <SRP Object> <LSP Object> A variation of the LSP identifier TLV is defined in this document, to support P2MP LSP Identifier P2MP capabilities advertisement. Candidate Paths for SR P2MP Policy are used for Tree Redundancy. As an example, an SR P2MP Policy can have multiple Candidate Paths. Each protecting the primary Candidate Path. The active CP is chosen via the preference of the Candidate Path. defines the instance-ID and P2MP tree instance (PTI). For SR P2MP Policy a CP can have one or more PTIs identified via instance-ID. If the CP has two or more PTIs, then these PTIs can be used for global optimization. Global optimization is defined in an upcoming section. Segment-list, used for connecting two non-adjacent Replication segments via a unicast binding SID or Segment-list. P2MP-END-POINT objects, used for the PCC to update the PCE with discovered Leaves. defines CCI object-type for SR-MPLS. This document specifies a new CCI object-type for SR P2MP Policy. Forwarding instruction for a P2MP LSP is defined by a set of SR-ERO sub-objects in the ERO object and ERO-ATTRIBUTES as defined in this document. SR-ERO Sub Object used in the multipath.

SR P2MP Policy Is only relevant on the Root of the P2MP tree and is a policy on PCE. It is downloaded only on the root node and is identified via <Root, Tree-ID>. It contains the following information: Root node of the P2MP Segment Set of Leaf nodes of the P2MP Segment Tree-ID, which is a unique identifier of the P2MP tree on the Root A set of CPs belonging to the policy Optional Constraints used to build these CPs Candidate Path (CP): Is used for P2MP Tree redundancy where the Candidate Path with the highest preference is the active path. Each CP can contain one or more P2MP Tree Instance (PTI). If the CP has more than one PTI then the CP can perform global optimization procedures (i.e., make-before-break) Contains information regarding originator, discriminator, preference, P2MP Tree Instances Tree Instance: Is used for global optimization of the CP. Two or more PTIs can be present under a Candidate Path but only a single PTI is active at a time. A Tree Instance is identified via <Root, Tree-ID, Instance-ID> Replication Segment: Is the forwarding information needed on each replication node for building the forwarding path for each PTI of the CP. Explained further in upcoming sections, there are 2 ways to identify the replication segment, depending on the type of replication segment (shared replication segment or non-shared replication segment) It is identified via Tree-ID and Root and PTI for non-shared replication segment. It is identified via Node-ID, Replication-ID, for shared replication segment. As per a shared replication segment is not associated to a single tree and can be used for constructing bypass tunnels for local protection on a Replication node. Contains forwarding instructions, in the form of a list of outgoing segments each of which may be a segment list or a single replication segment with next-hop information. On the forwarding plane the Replication Segment is identified via the incoming Replication SID. Is established on every node that may replicate (e.g., Root, Transit, Bud) or receive (e.g., Leaf) the packet in an SR P2MP tree.

An SR P2MP Policy and its CP can be identified on the root via the P2MP LSP Object. This Object is a new object based on the LSP ID Object defined in and is as follows: PLSP-ID: , is assigned by PCC and is unique per Candidate Path. It is constant for the lifetime of a PCEP session. Each additional Candidate Path is assigned a new PLSP-ID by PCC. Multiple Candidate Paths can co-exist but only one is active. Root: is equivalent to the first node on the SR P2MP Policy path. Tree-ID: an identifier that is unique in context of the Root node. This value may be assigned manually on the Root node or advertised via the Provider Tunnel Association (PTA) in a multicast BGP Auto-Discovery (AD) route. Instance-ID: serves as the PTI identifier and is assigned by the PCE. A CP can have two or more PTIs for global optimization. Instance-IDs are unique within the SR P2MP Policy and are assigned by the PCE per PTI within that Policy. While different P2MP policies may use the same Instance-ID for their PTI, each PTI within a CP of an SR P2MP Policy SHOULD use the same Instance-ID across the tree on its Root, Transit, and Leaf nodes when programming its replication segments on the PCC. Having the same Instance-ID throughout the tree's path will simplify correlation, troubleshooting and ID space management.

The key to identify a replication segment is also a P2MP LSP Object. With varying encoding rules for the SR-P2MP-INSTANCE-ID-TLV which will be explained in later sections.

PCECC and a new format of the CCI object is used in Replication Segment to identify a cross connect. A cross connect is an incoming SID and set of outgoing interfaces and their corresponding SID or SID List. The CCI objects contain the incoming SID and the outgoing interfaces which are presented via the ERO objects, each of which may contain a segment list.

An SR P2MP Policy on the Root can be either PCE-initiated or PCC-initiated, depending on how the Root and Leaf nodes are discovered. A PCE-initiated SR P2MP policy is configured directly on the PCE, while a PCC-initiated SR P2MP policy may be triggered by the PCC, sourced from local configuration or discovered with multicast protocols such as MVPN (see ), PIM, IGMP etc. In both cases, PCE-initiated mechanisms are used to install Replication segments on Transit, Bud and Leaf nodes. Note: Algorithms and techniques to compute the P2MP tree replicating nodes are out of scope of this document.

PCE is informed through its API or configuration mechanism to instantiate an SR P2MP Policy. PCE is configured with the Root and a set of Leaf nodes. PCE computes a P2MP tree from the Root node to all Leaf nodes which satisfy the configured constraints. PCE sends a PCInitiate message to the Root. The PCInitiate message is configured with a unique Instance-ID for the PTI within the CP of the SR P2MP Policy. The PCInitiate message sent to the Root MUST set the Tree-ID to 0. If not, the PCC MUST send a PCEP Error message (PCErr) with Error-Type = X2 (SR P2MP Policy General Error) and Error value = 1 (PCInit Invalid Tree-ID). The END-POINTS object MAY optionally be included in the PCInitiate message for providing list of Leaf nodes to the PCC for informational purposes. In response to the PCInitiate message, the PCC will assign the PLSP-ID and Tree-ID for the CP. The PCC uses the Instance-ID defined in the PCInitiate message for the PTI contained within the CP. The PCC sends a PCRpt back to PCE containing the PLSP-ID, Tree-ID and Instance-ID. PCC MAY optionally include additional Leaf nodes that were also discovered by multicast procedures. PCE will send a PCInitiate message to the Root, Transit and the Leaf nodes to download the Replication Segment information. These messages will utilize the CCI object to identify the P2MP cross-connect and encode the forwarding instruction information. PCE then sends a PCUpd to the Root node indicating the association information (CP) and implicitly binds the CP to the installed CCI information.

Root node PCC discovers the Leaf nodes via MVPN procedures or other mechanisms. Root sends a PCRpt message for SR P2MP policy to PCE including the Root, Tree-ID, PLSP-ID, symbolic-path-name, association object and any leaf nodes discovered. In addition: Since the Instance-ID is set by the PCE, the root will set the Instance-ID to the value 0 in the PCRpt message. For the association object, root will fill the association type according to the association type defined in this document. The association ID SHOULD be set to value 1 similar to . The association source is set to the Root PCC Address. PCE receives the PCRpt and generates a unique Instance-ID for this PTI of the CP and computes the P2MP Policy and its replication segments. PCE will send a PCInitiate message to the Root, Transit and the Leaf nodes to download the Replication Segment information. These messages will utilize the CCI object to encode the forwarding instruction information. PCE then sends a PCUpd to the Root node indicating the association information (CP) and implicitly binds the CP to the installed CCI information.

The following procedures are the same for PCE-init or PCC-init SR P2MP Policy.

PCE distributes the Replication segments for each CP's PTI to all Transit, Bud and Leaf nodes in the SR P2MP Tree using a PCInitiate message. PLSP-ID: value MUST be set to zero and will be assigned by PCC. If not, the PCC MUST send a PCEP Error message (PCErr) with Error-Type = 19 (Invalid Operation) and Error value = 8 (Non-zero PLSP-ID in LSP Initiate Request). Symbolic path name: generated by PCE, MUST be unique for each Candidate Path on PCC. If not, the PCC MUST send a PCEP Error message (PCErr) with Error-Type = X2 (SR P2MP Policy General Error) and Error value = 2 (Symbolic Path Name not unique). Root: the same value of the SR P2MP Policy. Tree-ID: it is RECOMMENDED the Tree-ID be set to the same Tree-ID defined on the Root node (which was assigned by the Root node PCC). Instance-ID: set to the same value of path-instance on the Root. The PCInitiate message includes the EROs and utilizes the CCI object to encode the Replication segment forwarding instruction information. In response to the PCInitiate message, each Transit, Bud and Leaf node PCC generates a local PLSP-ID and sends a PCRpt to PCE informing PCE of the Replication segment state.

Any new CP for the SR P2MP Policy is downloaded by PCE to the Root by sending a PCInitiate message. PLSP-ID: value MUST be set to zero and will be assigned by PCC. Symbolic path name: generated by PCE, MUST be unique for each CP on PCC. Root: the same value of the SR P2MP Policy. Tree-ID: the same value of the SR P2MP Policy. Instance-ID: The PCE generates the PTI's Instance-ID of the CP. If the PTI's Instance-ID is zero then the PCC MUST send a PCEP Error message (PCErr) with Error-Type = X2 (SR P2MP Policy General Error) and Error value = 3 (Invalid Instance-ID). The PCE distributes the necessary Replication segment for the CP and its PTIs to the Root, Leaf nodes and the Transit nodes as described in section "Replication Segment Instantiation". Any update to the CP or Replication segments is performed via the PCUpd message. Association object MUST be present for CP PCUpd and PCRpt message. If Association object is not present in the PCUpd message, the PCC MUST send a PCEP Error message (PCErr) with Error-Type = X2 (SR P2MP Policy General Error) and Error value = 5 (Missing Association). CCI object MUST be present in the Replication segment updates. If not, the PCC MUST send a PCEP Error message (PCErr) with Error-Type = X2 (SR P2MP Policy General Error) and Error value = 4 (CCI Object missing).

New Leaf nodes may be locally configured or discovered via multicast protocol procedures. New Replication segments may be instantiated or existing ones updated to reach new Leaf nodes. If the new Leaf nodes reside on routers that are part of the existing SR P2MP Tree, then PCUpd is sent from PCE to necessary PCCs (Leaf, Bud or Root nodes) with the existing PLSP-ID, Instance-ID, Tree-ID and CC-ID. If the new Leaf nodes are residing on routers that are not part of the existing SR P2MP Tree, then a PCInitiate message is sent from PCE to each new Leaf and any necessary Transit nodes following section "Replication Segment Instantiation".

The active CP is indicated by the PCC through the operational bits(Up/Active) of the LSP object in the PCRpt message. A CP is made active based on the preference of the path. If the Root is programmed with multiple CPs from different sources, as an example PCE and CLI, based on its tie-breaking rules, if it selects the CLI path, it will send a report to PCE for the PCE path indicating the status of label-download and sets operational bit of the LSP object to UP and Not Active. At any instance, only one PTI is permitted to be active.

When a P2MP LSP needs to be optimized for any reason (i.e. it is taking a FRR tunnel or new routers are added to the network) a global optimization of the CP is possible. When a PCC Open Message indicates support for only one instance of PTI, then the PCE MUST NOT include the PCC as part of global optimization procedures. Each CP MAY contain two or more PTIs. The current unoptimized PTI is the active instance and its replication segments are forwarding the multicast packets from the root to the leaves. However, the second optimized PTI will be setup with its own unique Replication Segments throughout the network, from the Root to the leaf nodes. These two PTIs MAY co-exist. The two PTIs are uniquely identified by their Instance-ID in the SR-P2MP-INSTANCE-ID-TLV (defined in this document). After the optimized PTI has been downloaded successfully, PCC MUST send two reports, reporting UP of the new PTI with the new LSP-ID, and a second reporting the tear down of the old PTI with the R bit of the LSP Object SET with the old Instance-ID in the SR-P2MP-INSTANCE-ID-TLV. This MBB procedure will move the multicast PDUs to the optimized Path-Instance. The transit and leaf nodes SHOULD be able to accept traffic from both PTIs to minimize the traffic outage by the Make Before Break process. It is RECOMMENDED for the optimized PTI to be set up by the PCE from the leaf nodes to transit nodes and finally the root nodes to ensure the entire PTI's path is programmed before the MBB procedure is initiated.

When one of the PCCs involved in the LSP lacks the capability to support more than one PTI, the possibility of achieving global make before break (MBB) is not feasible. However, with knowledge of the PCCs' advertised capabilities, the PCE can detect this limitation and instead opt for local re-optimization of the CP. In such cases, the PCE can compute the optimized LSP by sending the PCUpd message using the existing PTI and its Instance-ID for CP, specifically targeting the PCCs where the optimized LSP triggers a change in forwarding state.

This document identifies Facility Fast Reroute (FRR) procedures. Only Link Protection procedures are defined.

As an example, in figure 1 both R and T are configured with replication segments. There are two interfaces between R and T. One can be used as primary and second as a bypass in case the primary interface is down. There can be two methods to protect the primary interface: The two replication segments on R and T can take advantage of unicast SR to connect to each other. In this case the LFA of unicast SR can be utilized to protect the primary interface between R and T. The Replication segment provides a protection next-hop; the protection next-hop can be programmed to take the alternate interface between R and T to protect the primary interface. If the network already has implemented unicast SR then it might be advantageous to use LFA for SR to protect the link between R and T but if the network has not enabled unicast SR then the second option of Replication segment protection next-hop is the preferred method. For the second option the PATH-ATTRIB object can be used to describe a set of backup paths protecting a primary path within a PCEP LSP using the MULTIPATH_BACKUP TLV defined in this document. This capability is currently defined only for P2MP paths. Support for P2P paths with the MULTIPATH-BACKUP TLV is out of scope for this document. In this case, the PATH-ATTRIB is populated for each ERO as follows: The PCE assigns a unique Path ID to each ERO path and populates it inside the PATH-ATTRIB object. The Path ID is unique within the context of a PLSP (PCE Label Switched Path). The PCE MAY include the MULTIPATH-BACKUP TLV inside the PATH- ATTRIB object for each ERO that is protected, specifying the backup path IDs to reflect the set of backup paths protecting the primary path. The PCE updates the Length field and Backup Path Count in the MULTIPATH-BACKUP according to the number of backup path IDs included. The PCE MAY include the MULTIPATH-BACKUP TLV inside the PATH- ATTRIB object for each ERO that is unprotected. In this case, MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. If the path acts as a pure backup (i.e., the path only carries rerouted traffic after the protected paths fail), then the B flag MUST be set. Primary paths which do not include the MULTIPATH-BACKUP TLV are assumed to be protected by all the backup paths (i.e., omitting the TLV is equivalent to including the TLV with all the backup path IDs filled in). Note that a given PCC may not support certain backup combinations, such as a backup path that is itself protected by another backup path, etc. If a PCC does not support a requested backup scenario, the PCC MUST send a PCErr message with Error-Type = 19 (Invalid Operation) and Error-Value = 20 (Not supported path backup).

As a second example, in Figure 2, R and T are connected directly and via network F1..F2. In this example as per example 1, unicast SR can be used to connect the two Replication segments, including using SR LFA or R-LFA or TI-LFA to protect the direct link between R-T via F1. If unicast SR is not available within the network, the PCE optionally can establish a shared replication point on F1 and F2 and protect all path-instances that are traversing R-T via this shared Replication segment. In addition, Penultimate Hop Popping (PHP) and implicit null label on the bypass path can be implemented to reduce the PCE programming on the merge point (MP) PCC.

There could be many nodes between two Replication Segments that do not support SR P2MP Policy or Replication Segment. It is possible to connect two non-adjacent Replication segments via an SR Policy or similar technology using a SID list and rely on IGP forwarding. The SID list can be comprised of any IGP supported segment types (ex: Binding, Adjacency, Node). This information is encoded via the SR-ERO sub-objects and ERO-attributes objects. The last segment in an encoded SID list MUST be a Replication segment.

The SR P2MP Policy and its Replication segment can be deleted by the PCC or by the PCE. To delete the SR P2MP Policy, all the CPs associated with that P2MP Policy need to be deleted. The last CP that is being deleted, will delete the SR P2MP Policy Instance as well on the PCE or PCC. To delete the CPs there are two methods: The CPs can be deleted by deleting all the PTIs associated with them and the last PTI that is deleted will trigger the CP to be deleted. The CP can be deleted entirely and this will delete all the associated PTIs as well.

For PCC to delete a CP, Root sends a PCRpt message with the R bit of the LSP object set and all the fields of the SR-P2MP-INSTANCE-ID-TLV set to 0 (indicating to remove all state and PTIs associated with this SR P2MP Policy). The R bit in the LSP Object as defined in , refers to the removal of the LSP as identified by the SR-P2MP-INSTANCE-ID-TLV (defined in this document). An all-zero SR-P2MP-INSTANCE-ID-TLV indicates removal of all the state of the corresponding PLSP-ID. The PCE in response sends a PCInitiate message with R bit in the SRP object set to all nodes along the path to indicate deletion of the entries. In this case the Instance-ID can be set to 0 with the R bit set to indicate removing the entire CP and all its PTIs. For PCC to delete a PTI, Root sends a PCRpt message with the R bit of the LSP object set and all the fields of the SR-P2MP-INSTANCE-ID-TLV set to 0 but the Instance-ID value (indicating to remove the specific PTI associated with this P2MP tunnel). The PCE in response sends a PCInitiate message with R bit in the SRP object SET to all nodes along the path to indicate deletion of the entries. Note in this case the Instance-ID has to be set accordingly with the R bit set to indicate removing the specific PTI. This is useful for the global optimization case where after downloading the optimized PTI and ensuring the PTI is operational the PCC removes the old PTI.

When PCE is deleting a CP or a PTI it should delete all the replication segments of that CP or PTI as well before it moves to the next CP or PTI.

The objects and TLVs defined in this document can be included in PCRpt, PCInitiate and PCUpd messages. The inclusion of the Objects and TLVs differ between SR P2MP Policy and Replication segment.

An SR P2MP Policy supports actions to add, remove, and fully replace Leaf nodes in a message, described further in Section 5.5.2 and with an example in Appendix A. However, a CP and Replication Segment MUST NOT carry delta information. Every PCRpt, PCInitiate and PCUpd message MUST contain the full list of the Leaf nodes, and Segment forwarding information that is needed to build the CP and its Replication segments. This is necessary to ensure that PCE or any new PCE is in sync with the PCC.

This document uses to identify each outgoing interface in the Replication Segment. In addition, each outgoing interface can be protected by a backup path using the MULTIPATH-BACKUP TLV defined in this document. The Path Attributes Object is used to provide the relation between the primary path and its backup path as defined in later sections of this document. Note: Multipath weight TLV MUST NOT be used and SHOULD be ignored when received. Composite Candidate Path TLV SHOULD NOT be present and SHOULD be ignored if present. When a Replication segment is being updated or new outgoing interfaces are added to a specific replication segment, the PCRpt, PCInitiate and PCUpd messages sent via PCEP maintain the previous ERO Path IDs and generates new Path IDs for new instructions. The PATH IDs are maintained for each specific forwarding instructions until the instructions are deleted. For example: When the first leaf is added, the PCE will update with Path ID 1 to the PCC. When the second leaf is added, according to the path calculated, PCE might just append the existing instruction Path ID 1 with a new Path ID 2 to construct the new PCUpd message.

The Central Control Instruction (CCI) Object is used to identify the entire cross connect of Explicit Route Object (ERO) which consists of incoming Replication SID and the set of outgoing Interfaces and their corresponding SIDs and/or SID lists. Any modification to this instruction should use this CCI ID to identify the cross connect uniquely. Leaf nodes and their corresponding Path IDs can be removed from the cross connect identified via the CCI. The CC-ID is assigned by the PCE. The CCI Object used by the PCE to specify the controller instructions is defined in . specifies the CCI object in the PCInitiate and PCRpt messages only and does not define the CCI object for use in the PCUpd message. The Replication Segments defined in this document however require the need to modify the outgoing SID list(s) after initial instantiation on the root, transit and leaf routers, thus require the use of PCUpd messages. For example, when downstream leaf nodes are added or removed. For this reason, this document extends the use of the CCI object to the PCUpd message so that a PCE can update the forwarding instructions of an already-instantiated Replication Segment without re-initiating it, including the role of the node. This extension is scoped exclusively to Replication Segment. defines CCI object-type for SR-MPLS. This document defines a CCI object-type for SR-MPLS for SR P2MP Policy in upcoming sections.

The format of the PCRpt message as specified in and extended by is now further extended as follows:

::= Where: ::= [] ::= [] [] (|) Where: ::= is as per RFC8231 and extended by other PCEP extensions. is as per RFC8697 ]]>

The format of the PCUpd message as specified in and extended by is now further extended as follows:

::= Where: ::= [] ::= (|) Where: ::= is as per RFC8231 and extended by other PCEP extensions. ]]>

The format of the PCInitiate message as specified in and extended by is now further extended as follows:

::= Where: ::= [] ::= | ) ::= ([] |) [] [] Where: ::= ]]>

The Replication Segment can be constructed via the following PCRpt, PCUpd and PCInitiate messages NOTE: Replication segment does not use an association object The format of the PCRpt message is updated as follows:

::= Where: ::= [] ::= (| ) ::= [] ::= [] (| ( )| ( )) Where: is defined in [I-D.ietf-pce-multipath] ]]>

The format of the PCUpd message is updated as follows:

::= Where: ::= [] ::= (| ) ::= ::= ( ) Where: carries the SR-P2MP-LSP-IDENTIFIER object-type defined in this document and a applies only to a Replication Segment. is the SR P2MP Policy CCI object-type (Object-Class = 44 (CCI), Object-Type = TBD) defined in Section 5.7.2 of this document. is defined in [I-D.ietf-pce-multipath]. ]]>

The format of the PCInitiate message is updated as follows:

::= Where: ::= [] ::= (| | ) ::= (| ( )| ( )) Where: is defined in [I-D.ietf-pce-multipath] ]]>

A PCEP speaker indicates its ability to support SR P2MP Policy and Replication Segment during the PCEP initialization phase. Speakers which support SR P2MP Policy and Replication segment object MUST include SR-P2MP-POLICY-CAPABILITY TLV in the OPEN Object. This document defines a new SR-P2MP capability TLV with type TBD.

Type: 73 as per IANA Length: 8 octets Number of Instances 16 bits - Number of instances the advertising PCEP speaker supports. This is meaningful for PCEs. PCEs can determine the least number of instances that could be created for an SR P2MP Policy. Number of replication 16 bits - number of outgoing interfaces that the system is capable of having per multicast state. Flags 16 bits - No Flags currently defined Reserved 16 bits, MUST be set to 0 on transmission and ignored on receipt

If a PCEP speaker advertises SR P2MP Policy Capability then it MUST include the PST = 1 in the PATH-SETUP-TYPE-CAPABILITY TLV as per

An Assoc-Type-List TLV as per Section 3.4 SHOULD be sent via the PCEP OPEN object with the following association type.

OP-CONF-Assoc-RANGE (Operator-configured Association Range) SHOULD not be set for this association type and MUST be ignored.

This document reuses symbolic path name from Section 7.3.2. For SR P2MP Policy a symbolic path is unique on the PCC. To help the name be unique on PCC, it is RECOMMENDED the name contain the Root, Tree-ID and CP Discriminator values.

Two ASSOCIATION object types for IPv4 and IPv6 are defined in . The ASSOCIATION object includes "Association type" indicating the type of the association group. This document adds a new Association type. Association type = TBD1 "SR P2MP Policy Association Type" for SR Policy Association Group (P2MP SRPAG). For PCC-initiated SR P2MP Policy, the ASSOCIATION object is present in the first PCRpt message that is sent by the PCC to PCE to indicate the existence of the SR P2MP Policy and its CP. Note that, this first PCRpt message does not have an SRP object corresponding to a PCUpd message. The Association Source SHOULD be set to the root address of the P2MP tree. In line with Section 4.2, P2MP Policy reuses the four TLVs used in the SRPA object. P2MP policy also redefines the extended association ID TLV: SRPOLICY-POL-NAME TLV: (optional) encodes SR P2MP Policy Name SRPOLICY-CPATH-ID TLV: (mandatory) encodes SR P2MP Policy Candidate Path Identifier SRPOLICY-CPATH-NAME TLV: (optional) encodes SR P2MP Policy Candidate Path name. SRPOLICY-CPATH-PREFERENCE TLV: (optional) encodes SR P2MP Policy Candidate Path preference value. In addition to above the extended association ID TLV has been modified to address the SR P2MP Policy

In line with , the Extended Association ID TLV MUST be included and it MUST be in the following format for the SR P2MP Policy. If the Extended Association ID TLV is not present, the PCC MUST send a PCEP Error message (PCErr) with Error-Type = X2 (SR P2MP Policy General Error) and Error value = 6 (Missing Extended Association ID).

Length: 4 byte Tree-ID: identifies the P2MP Tree which the Replication segment is part of

In order for the Root node to indicate operations of its Leaf nodes (Add/Remove/Replace-all), the PCRpt and PCInitiate messages are extended to include P2MP-END-POINT Object which is defined in The absence of the P2MP-END-POINT Object means that there is no change in the leaf endpoint of the policy and the PCEP speaker MUST NOT consider the absence of the object as an indication of removal of the endpoints. Leaf Types (derived from section 3.3.2) : New leaves to add (leaf type = 1) Old leaves to remove (leaf type = 2) the entire PCE leaf list is overwritten and replaced with the new leaf list (leaf type = 5) Note a PCE speaking node MUST NOT combine leaf type 1 and 2 with leaf type 5. Note a PCE speaking node SHOULD NOT have the same node present in the leaf type 1 and 2 if both leaf types are present. A given P2MP END-POINTS object gathers the Leaf nodes of a given type. An SR P2MP PCRpt MAY mix different types of Leaf nodes by including several P2MP END-POINTS objects. The END-POINTS object body has a variable length. These are multiples of 4 bytes for IPv4, multiples of 16 bytes, plus 4 bytes, for IPv6.

Both SR P2MP Policy and Replication Segment are identified via the LSP object and more precisely via the SR-P2MP-INSTANCE-ID-TLV The SR P2MP Policy uses the PLSP-ID to identify the CP and the Instance-ID to identify a PTI within the CP. A Replication Segment uses the SR-P2MP-INSTANCE-ID-TLV to identify and correlate a Replication Segment to a P2MP Policy As it was noted previously, for the Root the SR P2MP Policy and the Replication Segment is downloaded via the same PCUpd message.

The LSP Object is defined in Section 7.3 of . It specifies the PLSP-ID to uniquely identify an LSP that is constant for the lifetime of a PCEP session. Similarly, for a P2MP Policy, the PLSP-ID identifies a Candidate Path uniquely within the SR P2MP policy. The LSP Object MUST include the new SR-P2MP-INSTANCE-ID-TLV (IPv4/IPv6) defined in this document below. This is a variation to the P2MP object defined in

The type (16-bit) of the TLV is TBD (need allocation by IANA). Root: Source Router IP Address Tree-ID: Unique Identifier of this P2MP LSP on the Root. Instance-ID : Identifier of PTI, Contains 16 Bit instance ID. Instance-id 0 is reserved. Reserved: 8 bits reserved for future use. Flags: 8 bits, A - Activate the Instance-ID, R - Remove the Instance-ID At any given time, only one PTI MUST be active. Activating one PTI entails deactivating the other PTI, with the condition that the active PTI Instance-ID MUST have a non-zero value. The (A) flag is meaningful for Root PCC and PCE. PCE MUST be setting (A) flag in the PCUpd containing SR-P2MP-INSTANCE-ID TLV for activating the PTI. The decision regarding when to set the (A) flag can be made locally on the PCE. E.g., this decision can be based on factors such as receiving PCRpt messages from all PCCs for the new PTI or utilizing a timer-based approach to ensure that the data plane is completely configured on all PCCs. It's important to note that determining the appropriate timing for activating the new PTI is not within the scope of this document. After the activation of the SR P2MP Policy any PCUpd MUST include the (A) flag in the P2MP-Instance TLV. Root PCC MUST set the (A) flag in the PCRpt as a response to receiving a PCUpd message with the (A) flag set. If a PCE receives a PCRpt with the (A) flag set in response to a PCUpd message that did not have the (A) flag set, then PCE MUST treat this as an error. In such a case, PCE MUST send a PCEP Error message (PCErr) with Error-Type=10 (Reception of an Invalid Object) and error-value=R1 (Invalid active instance). For Transit or Leaf PCCs, receipt of a PCUpd message with the (A) flag MUST be treated as an error. Transit or Leaf PCCs MUST send a PCEP Error message (PCErr) with Error-Type=19 (Invalid Operation) and error-value=I1 (Attempted activating instance on Transit or leaf PCC). Figure 3 presents an example exchange of SR-P2MP-INSTANCE-ID-TLV.

| With PLSP-ID and | (SRP, | Instance-ID | LSP(SR-P2MP-INST-ID),| | P2MP-END-POINT) | | | | <------- PCUpd ------- |2) PCUpd message sent | (SRP, | to the PCC with | LSP(SR-P2MP-INST-ID),| Path info and activating | Association, | instance. | P2MP SR Pol. ID TLV, | | CPATH_ID TLV, | | P2MP-END-POINT, | | CCI, PATH_ATTRIB, | | SR-ERO) | | | | | 3) LSP State Report |---- PCRpt message ---->| (echoing Instance | | Active) | | | | Note: SR-P2MP-INST-ID is SR-P2MP-INSTANCE-ID-TLV ]]>

As per , a replication segment has a next-hop-group which MAY contain a single outgoing replication SID or a list of SIDs (sr-policy-sid-list). In either case, there needs to be a replication SID identifying the replication state on a downstream replication node. Two replication segments can be directly connected or connected via a unicast SR domain.

The format of a Replication Segment message encoding is similar to SR P2MP Policy. However, the SR P2MP Policy contains the association object and the Replication Segment message does not contain the association object. In addition, the Replication Segment carries the CCI object to identify a P2MP cross-connect. The Replication Segment is distributed individually to the Root, Transit and Leaf nodes without the SR P2MP Policy. The Replication Segment uses SR-P2MP-INSTANCE-ID-TLV as its identifier. The TLV is coded differently for shared and non-shared cases.

The Central Control Instructions (CCI) Object used by PCE to specify the controller instructions is defined in . This document defines a new CCI object-type for SR P2MP Policy. The label in the CCI Object is the incoming SID. The outgoing SIDs are defined by the ERO Objects. The CCI Object can be included in PCRpt, PCInitiate and PCUpd messages for Replication Segments. CCI Object-Type is 3 for SR P2MP Policy.

Flags: The MT-ID, Algorithm, V and the L flags are defined as per The node action and role of ingress, transit, leaf or bud, is indicated via the 4-bit role field. Ingress, role type = 1 Transit, role type = 2 Leaf, role type = 3 Bud, role type = 4

Forwarding information of a Replication Segment can be configured and steered via many different mechanisms. RFC defines the NAI types. As an example a replication SID can be steered via: Replication SID steered with an IPv4/IPv6 directly connected nexthop (RFC 8664 NAI type 3, 4, 6 (adjacency)) In this case there will be two SR-EROs in the ERO Object, with the Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO on the top. Replication SID steered with an IPv4/IPv6 loopback address that resides on the directly connected router. (NAI type 1..2 (node)) In this case there will be two SR-EROs in the ERO Object, with the Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO on the top. Replication SID steered with unnumbered IPv4/IPv6 directly connected interface (NAI type 5 (adjacency unnumbered)) Replication SID steered via an SR adjacency or node SID In this case even a SID-list can be used to traffic engineer the path between two Replication Segment The Replication SID SR-ERO is at the bottom while the segments describing the path are on top in order.

This document defines a new MULTIPATH-BACKUP TLV which is optional in the PATH-ATTRIB object defined in . This TLV is used to describe a set of backup paths protecting a primary path within a PCEP LSP. This is similar to path protection, but works at the ECMP path level instead of at the PCEP LSP level. This functionality may be implemented for certain specialized use cases, as an example if the SR P2MP Policy is implemented in a network that does not support LFA this functionality can be used for link or node protection.

Type (16 bits): 62 for "MULTIPATH-BACKUP" TLV Length (16 bits): 4 + (N * 4) bytes (where N is the Backup Path Count) Backup Path Count (16 bits): Number of backup paths. Flags (16 bits): B (Pure Backup): If set, indicates the path is a backup path (e.g., for protection) and not used for load balancing under normal conditions. A pure backup path only carries rerouted traffic after the protected paths fail. If this flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the path is assumed to be a primary path that carries normal traffic. Unassigned bits MUST be set to 0 on transmission and MUST be ignored on receipt Backup Path IDs: A series of 4-octet identifiers that reference the Path ID field (see Section 4.2) of other PATH-ATTRIB objects within the same PCEP LSP. These referenced paths act as backup paths that protect this primary path. Each Backup Path ID value MUST match the Path ID of a PATH-ATTRIB object in the same LSP that has the B-flag set (indicating it is a pure backup path).

In addition this document defines a new flag "B-flag" in the MULTIPATH-CAP TLV which is defined in the B-flag: whether MULTIPATH-BACKUP TLV is supported.

This document defines a new Association type for SR P2MP Policy. IANA is requested to confirm the allocation in the IANA Registry "ASSOCIATION Type Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group.

specified the P2MP END-POINTS object but did not create a registry for the 32-bit Leaf type field. This document establishes the registry and populates it with values from and adds a new Leaf type. IANA is requested to create a new "Endpoint Leaf Types" registry with the allocation policy as IETF Review . This new registry contains the following values:

To keep it consistent with the Generalized Endpoint Types , this document defines a new Endpoint Type in the "Generalized Endpoint Types" registry. IANA is requested to confirm the allocation as follows:

This document extends the PCEP OPEN object by defining a new optional TLV to indicate the PCE's capability to perform SR-P2MP path computation. Further, this document defines two new TLVs for identifying the SR P2MP Policy and the Replication Segment with IPv4 or IPv6 root address.--> IANA is requested to confirm the following allocations in the IANA Registry "PCEP TLV Type Indicators"

Note: MULTIPATH-BACKUP TLV was originally defined in [I-D.ietf-pce-multipath], and marked as a reference. IANA is requested to update the reference to this document.

This document defines a new CCI Object type for SR P2MP Policy. IANA is requested to confirm the following allocation in the "PCEP Objects" sub-registry as follows:

IANA is requested to make the following allocations in the "PCEP-ERROR Object Error Types and Values" registry:

IANA is requested to confirm the following allocations in the "PCEP-ERROR Object Error Types and Values" registry:

Note: This was originally defined in [I-D.ietf-pce-multipath], and marked as a reference. IANA is requested to update the reference to this document.

IANA is requested to create a new sub-registry to manage the Flag field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP TLV" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. New values are to be assigned by "IETF review" [RFC8126].

IANA is requested to allocate bit 14 for "B-flag: MULTIPATH-BACKUP TLV support" which is currently Unassigned in the registry called "Flags in MULTIPATH-CAP TLV".

The security considerations described in , , , , , and are applicable to this specification. As per , it is RECOMMENDED that these PCEP extensions can only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) . No additional security measures are required for SR P2MP Policy.

Note to the RFC Editor: please remove this section before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC7942 . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Cisco has implemented this document on both IOS XR PCE and PCC. Both PCE-Initiated and PCC-Initiated SR P2MP Policy types have been implemented. Only one Candidate Path can be created with the SR P2MP Policy and only one PTI is supported within a CP.

All manageability requirements and considerations listed in , , , and apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.

With P2MP policy any router that is acting as a Root, Transit (replication point) and Leaf needs to have a PCEP connectivity to the controller. This might not be the case for unicast where only the node that is instantiating the SR Policy and the ordered list of the segments needs PCEP connectivity. An operator might need to enable PCEP on more nodes for enabling P2MP Policy on a network that is already supporting SR Policy, as such the operator needs to ensure that the controller can handle the extra PCEP connection scale. Otherwise, operational considerations of P2MP Policy are in line with , , , and .

Since P2MP Policy does not use any underlay signaling to detect failure it is recommended to use (Operations, Administration, and Maintenance) OAM features to detect failure on a tree. defines extensions to Ping and Traceroute mechanism for SR P2MP Policy with MPLS encapsulation to provide OAM capabilities. The extensions enable operators to verify connectivity, diagnose failures and troubleshoot forwarding issues within SR P2MP Policy multicast trees. The implementation can trigger P2MP Policy Ping or Traceroute periodically to test the end-to-end connectivity and trigger a global optimization of the tree from the Root to the Leaves. Any local failure can be detected via monitoring the state of the outgoing links and trigger a local optimization. In addition, as the controller gets updated with the network topology it also triggers a global optimization of the tree based on new discovered optimal paths from the Root to the Leaves.

Operation verification requirements already listed in , , , are applicable to mechanisms defined in this document. An implementation MUST allow the operator to view SR P2MP Policy Identifier and each SR Replication segment Candidate Path Identifier advertised in PCEP. An implementation SHOULD allow the operator to view the capabilities defined in this document. An implementation SHOULD allow the operator to view each Replication segment Candidate Path associated with specific SR P2MP Policy.

The PCEP extensions defined in this document do not imply any new requirements on other protocols.

The mechanisms defined in , , also apply to the PCEP extensions defined in this document.

The authors would like to thank Tanmoy Kundu and Andrew Stone at Nokia and Tarek Saad at Cisco for their feedback and major contribution to this document.

This is an example of PCC initiated P2MP Policy. The PCC will send a Report message to the PCE to initiate a P2MP Policy with a set of leaves that are discovered via Next Generation MVPN procedures as per . In addition, since the PCC is initiating the P2MP Policy, it does populate the PLSP-ID for the Candidate Path. PCC will leave the Instance-ID for the PTI to 0 and the Instance-ID is assigned by the PCE.

| PLSP-ID = 1 | A:1,D:1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=17 | Length= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | symbolic path name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root = A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree-ID = Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address = A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address = D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address = E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

The following packet is the PCE creating the CP for the SR P2MP Policy and downloading the Replication Segment with the same message on the root. It should be noted combining the SR P2MP Policy CP creation and Replication Segment only is possible on the root. As such this message contains both association object and the CCI object. The CCI Object contains the incoming Binding SID and wraps all the Path Attribute messages and their corresponding EROs. The PLSP-ID are populated with the same ID as the previous PCC report message and the Instance-ID is assigned by the PCE.

| PLSP-ID = 1 | A:1,D:1,C:0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=17 | Length= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | symbolic path name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root =A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree-ID = Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID = L1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association type= SR-P2MP-PAG | Association ID = z | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=P2MP SR Policy ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root = A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TREE-ID = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=P2MP SR Policy Name | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ P2MP SR Policy Name ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=P2MP SR Pol Cand-path ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ProtOrigin 10 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator ASN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Originator Address = | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discriminator = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=P2MP SR Pol Cand-path Name| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ P2MP SR Policy Candidate Path Name ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=P2MP SR Pol Cand-Path Pre | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference = 100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address = A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address = D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address = E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC-ID = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | Algorithm | role | flags |V|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Oper| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERO-path Id = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path Count = 1 | Flags |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT= 1| Flags |0|0|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipv4-address = NHD1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT= 0| Flags |0|1|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID = d1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Oper| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERO-path Id = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path Count = 0 | Flags |1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT= 1| Flags |0|0|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipv4-address = NHD2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT= 0| Flags |0|1|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID = d2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

The following packet examples show the Replication Segment initiation via a PCE on Transit nodes and/or Leaf nodes. Note: This packet is generated from PCE to instantiate the Replication segment, as such the PLSP-ID is set to zero. PCC will assign these values and report them back to PCE. The Instance-ID was assigned by the PCE for the entire PTI path on the root, transit and leaves (P2MP tree) This is a Replication Segment instantiation as such there is no association object. The LSP Object Root A and Tree-ID Y associates this Replication Segment to the corresponding CP and PTI on the root node. there is no association object present in the packet.

| PLSP-ID = 0 | A:1,D:1,C:0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=17 | Length= | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | symbolic path name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root =A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree-ID = Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID = L1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC-ID = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | Algorithm | role | flags |V|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label = d1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Oper| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERO-path Id = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path Count = 1 | Flags |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT= 1| Flags |0|0|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipv4-address = NHE1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT= 0| Flags |0|1|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID = e1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Oper| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERO-path Id = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Path Count = 0 | Flags |1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT= 1| Flags |0|0|1|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ipv4-address = NHE2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=36 | Length | NT= 0| Flags |0|1|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID = e2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

| PCECC LSP |PCC +--------+ | N=1,root-addr,Tree-ID=a, | SR-Policy | | | | Instance-ID =0, | Report to |Leaf | | | P2MP-END-POINT (LeafType=5)(optnl)| PCE +--------+ | | association-obj | | | | | |<---------------PCInitiate,PLSP-ID=0, -------------| Download | | | root-addr,Tree-ID=a,Instance-ID=b,| Leaf | | | CC-ID=Z,C=0, | Replication | | | O=0,L=z,path-attribute,ERO,SR-ERO | Segment(RS) | | | | |---------------------PCRpt,PLSP-ID=1-------------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Z,Label=z,O=0, | | | | path-attribute,ERO,SR-ERO | | | | | | |<-------PCInitiate,PLSP-ID=0, -------------| Download | | | root-addr,Tree-ID=a,Instance-ID=b,| Transit | | | CC-ID=Y,C=0, | RS | | | O=0,L=y,path-attribute,ERO,SR-ERO | | | | | | |-------------PCRpt,PLSP-ID=2-------------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Y,Label=y,O=0, | | | | path-attribute,ERO,SR-ERO | | | | | | | |<--PCInitiate,PLSP-ID=0, | Download | | | root-addr,Tree-ID=a,Instance-ID=b,| Root | | | CC-ID=X,C=0, | RS | | | O=0,L=x,P2MP-end- | | | | points(LeafType=5),path-attribute,| | | | ERO,SR-ERO | | | | | | | |-------PCRpt,PLSP-ID=1-------------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=X,Label=x,O=0, | | | | P2MP-END-POINT (LeafType=5) | | | | path-attribute,ERO,SR-ERO | | | | | | | |<--PCUpd,PLSP-ID=1, SRP-ID =2, | | | | root-addr,Tree-ID=a,Instance-ID=b,| Activate | | | P2MP-END-POINTs | CP to last | | | | RS | | |-------PCRpt,PLSP-ID=1, SRP-ID =2, ->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | P2MP-END-POINT (LeafType=5) | | | | | ]]>

Note that on transit / leaf Initiate is with PLSP-ID = 0. Therefore PLSP-ID is locally unique to a node. It should be noted that the CC-ID does not need to be constant across all nodes that make up the path. PCE-Initiated workflow

| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | P2MP-END-POINTs(LeafType=5) | | | | association-object, | | | | | | | |<--PCUpd,PLSP-ID=1, | Download | | | root-addr,Tree-ID=a,Instance-ID=b,| Root RS | | | CC-ID=X,C=0, | | | | O=0,L=x,P2MP-end- | | | | points(LeafType=5),path-attribute,| | | | ERO,SR-ERO | | | | | | | |-------PCRpt,PLSP-ID=1-------------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=X,Label=x,O=0, | | | | P2MP-END-POINTs(LeafType=5) | | | | path-attribute,ERO,SR-ERO | | | | | |<---------------PCInitiate,PLSP-ID=0, -------------| Download | | | root-addr,Tree-ID=a,Instance-ID=b,| Leaf RS | | | CC-ID=Z,C=0, | | | | O=0,L=z,path-attribute,ERO,SR-ERO | | | | | |---------------------PCRpt,PLSP-ID=1-------------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Z,Label=z,O=0, | | | | path-attribute,ERO,SR-ERO | | | | | | |<-------PCInitiate,PLSP-ID=0, -------------| Download | | | root-addr,Tree-ID=a,Instance-ID=b,| Transit RS | | | CC-ID=Y,C=0, | | | | O=0,L=y,path-attribute,ERO,SR-ERO | | | | | | |-------------PCRpt,PLSP-ID=2-------------->| | | | root-addr,Tree-ID=a,Instance-ID=c,| | | | CC-ID=Y,Label=y,O=0, | | | | path-attribute,ERO,SR-ERO | | | | | | |<-------PCInitiate,PLSP-ID=0, -------------| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Y,C=0, | | | | O=0,L=y,path-attribute,ERO,SR-ERO | | | | | | |-------------PCRpt,PLSP-ID=2-------------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Y,Label=y,O=0, | | | | path-attribute,ERO,SR-ERO | | | | | | | |<--PCUpd,PLSP-ID=1, SRP-ID =1, | Bind and | | | root-addr,Tree-ID=a,Instance-ID=b,| Activate | | | P2MP-END-POINTs, | CP to last | | | | RS | | |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | P2MP-END-POINTs(LeafType=5) | ]]>

MBB Workflow:

| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Z1,Label=z1,O=0, | | | | path-attribute,ERO,SR-ERO | | | | | | |<-------PCInitiate,PLSP-ID=2, -------------| Download | | | root-addr,Tree-ID=a,Instance-ID=b,| new RS on | | | CC-ID=Y1,C=0, | Transit | | | O=0,L=y1,path-attribute,ERO,SR-ERO | | | | | | |-------------PCRpt,PLSP-ID=2-------------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Y1,Label=y1,O=0, | | | | path-attribute,ERO,SR-ERO | | | | | | | |<--PCInitiate,PLSP-ID=1, | Download | | | root-addr,Tree-ID=a,Instance-ID=b,| new RS on | | | CC-ID=X1,C=0, | Root | | | O=0,L=x1,P2MP-end- | | | | points(LeafType=5),path-attribute,| | | | ERO,SR-ERO | | | | | | | |-------PCRpt,PLSP-ID=1-------------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=X1,Label=x1,O=0, | | | | P2MP-END-POINTs(LeafType=5) | | | | path-attribute,ERO,SR-ERO | | | | | | | |<--PCUpd,PLSP-ID=1, SRP-ID =1, | Bind and | | | root-addr,Tree-ID=a,Instance-ID=b,| Activate | | | P2MP-END-POINTs, | CP to last | | | | RS | | |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | P2MP-END-POINTs(LeafType=5) | | | | | | | |<--PCInitiate,PLSP-ID=1,R=1 | Remove | | | root-addr,Tree-ID=a,Instance-ID=b,| the old RS | | | CC-ID=X1,C=0 | from Leaf | | | O=0,L=x1,P2MP-end- | | | | points(LeafType=5),path-attribute,| | | | ERO,SR-ERO | | | | | | | |-------PCRpt,PLSP-ID=1, R=1--------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=X1,Label=x1,O=0, | | | | P2MP-END-POINTs(LeafType=5) | | | | path-attribute,ERO,SR-ERO | | | | | | |<-------PCInitiate,PLSP-ID=2, R=1----------| Remove the | | | root-addr,Tree-ID=a,Instance-ID=b,| old RS from | | | CC-ID=Y1,C=0, | Transit | | | O=0,L=y1,path-attribute,ERO,SR-ERO | | | | | | |-------------PCRpt,PLSP-ID=2, R=1--------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Y1,Label=y1,O=0, | | | | path-attribute,ERO,SR-ERO | | | | | |<---------------PCInitiate,PLSP-ID=1,R=1-----------| Remove the | | | root-addr,Tree-ID=a,Instance-ID=b,| old RS from | | | CC-ID=Z1,C=0, | Root | | | O=0,L=z1,path-attribute,ERO,SR-ERO | | | | | |---------------------PCRpt,PLSP-ID=1,R=1---------->| | | | root-addr,Tree-ID=a,Instance-ID=b,| | | | CC-ID=Z1,Label=z1,O=0, | | | | path-attribute,ERO,SR-ERO | ]]>