Skip to main content

PCEP extensions for p2mp sr policy
draft-ietf-pce-sr-p2mp-policy-09

Document Type Active Internet-Draft (pce WG)
Authors Hooman Bidgoli , Daniel Voyer , Saranya Rajarathinam , Anuj Budhiraja , Rishabh Parekh , Siva Sivabalan
Last updated 2024-08-02
Replaces draft-hsd-pce-sr-p2mp-policy
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Andrew Stone
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to andrew.stone@nokia.com
draft-ietf-pce-sr-p2mp-policy-09
Network Working Group                                    H. Bidgoli, Ed.
Internet-Draft                                                     Nokia
Intended status: Standards Track                                V. Voyer
Expires: 2 February 2025                                     Bell Canada
                                                         S. Rajarathinam
                                                                   Nokia
                                                            A. Budhiraja
                                                               R. Parekh
                                                            Cisco System
                                                            S. Sivabalan
                                                                   Ciena
                                                           1 August 2024

                   PCEP extensions for p2mp sr policy
                    draft-ietf-pce-sr-p2mp-policy-09

Abstract

   SR P2MP policies are set of policies that enable 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 from a Root to a set
   of Leaves.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 2 February 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Bidgoli, et al.          Expires 2 February 2025                [Page 1]
Internet-Draft             PCEP p2mp sr policy               August 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions used in this document . . . . . . . . . . . . . .   4
   3.  Overview of PCEP Operation in SR P2MP Network . . . . . . . .   4
     3.1.  High level view of P2MP Policy Objects  . . . . . . . . .   5
     3.2.  Existing drafts used for defining a P2MP Policy . . . . .   7
       3.2.1.  Existing Documents used by this draft . . . . . . . .   7
       3.2.2.  P2MP Policy Identification  . . . . . . . . . . . . .   8
       3.2.3.  Replication Segment Identification  . . . . . . . . .   8
       3.2.4.  PCECC Use in Replication Segment  . . . . . . . . . .   9
     3.3.  High Level Procedures for P2MP SR LSP Instantiation . . .   9
       3.3.1.  PCE-Init Procedure  . . . . . . . . . . . . . . . . .   9
       3.3.2.  PCC-Init Procedure  . . . . . . . . . . . . . . . . .  10
       3.3.3.  Common Procedure  . . . . . . . . . . . . . . . . . .  10
       3.3.4.  Global Optimization of the Candidate Path . . . . . .  12
       3.3.5.  local optimizatoin  . . . . . . . . . . . . . . . . .  12
       3.3.6.  Fast Reroute  . . . . . . . . . . . . . . . . . . . .  13
       3.3.7.  Connecting Replication Segment via Segment List . . .  14
     3.4.  SR P2MP Policy and Replication Segment TLVs and
           Objects . . . . . . . . . . . . . . . . . . . . . . . . .  14
       3.4.1.  SR P2MP Policy Objects  . . . . . . . . . . . . . . .  14
       3.4.2.  Replication Segment Objects . . . . . . . . . . . . .  14
       3.4.3.  P2MP Policy and Replication Segment general
               considerations  . . . . . . . . . . . . . . . . . . .  15
         3.4.3.1.  Path Attribute Object . . . . . . . . . . . . . .  15
         3.4.3.2.  CCI Object  . . . . . . . . . . . . . . . . . . .  16
   4.  Object Format . . . . . . . . . . . . . . . . . . . . . . . .  16
     4.1.  Open Message Extension  . . . . . . . . . . . . . . . . .  16
     4.2.  PCE Capabliity SubTLV . . . . . . . . . . . . . . . . . .  17
     4.3.  Association Type Capability . . . . . . . . . . . . . . .  17
     4.4.  Symbolic Name in PCInit Message from PCC  . . . . . . . .  17
     4.5.  P2MP Policy Specific Objects and TLVs . . . . . . . . . .  18
       4.5.1.  P2MP Policy Association Group for P2MP Policy . . . .  18
         4.5.1.1.  Extended Association ID TLV . . . . . . . . . . .  18
       4.5.2.  P2MP-END-POINTS Object  . . . . . . . . . . . . . . .  19
     4.6.  P2MP Policy and Replication Segment Identifier Object and
           TLV . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       4.6.1.  Extension of the LSP Object, SR-P2MP-LSPID-TLV  . . .  21

Bidgoli, et al.          Expires 2 February 2025                [Page 2]
Internet-Draft             PCEP p2mp sr policy               August 2024

     4.7.  Replication Segment . . . . . . . . . . . . . . . . . . .  24
       4.7.1.  The format of the replication segment message . . . .  24
       4.7.2.  PCECC . . . . . . . . . . . . . . . . . . . . . . . .  25
       4.7.3.  Label action rules in replicating segment . . . . . .  27
       4.7.4.  SR-ERO Rules  . . . . . . . . . . . . . . . . . . . .  28
   5.  Tree Deletion . . . . . . . . . . . . . . . . . . . . . . . .  29
     5.1.  PCC Initiated . . . . . . . . . . . . . . . . . . . . . .  29
     5.2.  PCE Initiated . . . . . . . . . . . . . . . . . . . . . .  30
   6.  Fragmentation . . . . . . . . . . . . . . . . . . . . . . . .  30
   7.  Some packet examples  . . . . . . . . . . . . . . . . . . . .  30
     7.1.  Report for Leaf Add . . . . . . . . . . . . . . . . . . .  30
     7.2.  P2MP Policy Candidate path Init . . . . . . . . . . . . .  31
     7.3.  Replication segment PCE Initiated on Transit and
           LEaves  . . . . . . . . . . . . . . . . . . . . . . . . .  35
   8.  Example Workflows . . . . . . . . . . . . . . . . . . . . . .  37
   9.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .  42
     9.1.  PCEP P2MP Association type  . . . . . . . . . . . . . . .  42
     9.2.  Endpoint Type . . . . . . . . . . . . . . . . . . . . . .  42
     9.3.  PCEP TLV Type Indicators  . . . . . . . . . . . . . . . .  43
     9.4.  New CCI Object Type . . . . . . . . . . . . . . . . . . .  44
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  44
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  44
   12. Informative References  . . . . . . . . . . . . . . . . . . .  44
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

1.  Introduction

   The draft [draft-ietf-pim-sr-p2mp-policy] defines a variant of the SR
   Policy that uses [RFC9256] for constructing a P2MP segment to support
   multicast service delivery.

   A Point-to-Multipoint (P2MP) Policy connects a Root node to a set of
   Leaf nodes, optionally through a set of intermediate replication
   nodes.  A Replication segment
   [draft-ietf-spring-sr-replication-segment], corresponds to the state
   of a P2MP segment on a particular node and provide forwarding
   instructions for the segment.

   A P2MP Policy is relevant on the root of the P2MP Tree and it
   contains candidate paths.  The candidate paths are made of path-
   instances and each path-instance is constructed via replication
   segments.  These replication segments are programmed on the root,
   leaves and optionally intermediate replication nodes.

   Replication segments MAY be connected to each other directly, or they
   MAY be connected or steered via unicast SR segments or a segment
   list.

Bidgoli, et al.          Expires 2 February 2025                [Page 3]
Internet-Draft             PCEP p2mp sr policy               August 2024

   For a P2MP Tree, a controller may be used to compute paths from a
   Root node to a set of Leaf nodes, optionally via a set of replication
   nodes.  A packet is replicated at the root node and optionally on
   Replication nodes towards each Leaf node.

   There are two types of a P2MP Tree: Spray and Replication.

   A Point-to-Multipoint service delivery could be via Ingress
   Replication, known as Spray.  The root unicasts individual copies of
   traffic to each leaf.  The corresponding P2MP Policy consists of
   replication segments only for the root and the leaves and they are
   connected via a unicast SR Segment.

   A Point-to-Multipoint service delivery could also be via Downstream
   Replication, known as Replication Tree.  The root and some downstream
   replication nodes replicate the traffic along the tree as it
   traverses closer to the leaves.

   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 [RFC6513] or PIM.  The controller can calculate
   the P2MP Policy and any of its associated replication segments from
   the root to the leaves with these info and any additional Service
   Leave Agreements (SLAs) that is used to construct the tree.

   This document defines PCEP objects, TLVs and the procedures to
   instantiate a P2MP Policy and Replication Segments.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Overview of PCEP Operation in SR P2MP Network

   After discovering the root and the leaves the PCE programs the PCCs
   with relevant information needed to create a P2MP Tree.

   As per draft [draft-ietf-pim-sr-p2mp-policy] a P2MP Policy is defined
   by Root-ID, Tree-ID and a set of leaves.  A P2MP policy is a variant
   of SR policy as such it uses the same concept as draft
   [draft-ietf-pce-segment-routing-policy-cp].  A P2MP policy is
   composed of a collection of SR P2mp Candidate Paths.  Candidate paths
   are computed by the PCE and can be used for P2MP Tree redundancy.
   Only a single candidate path may be active at each time.  Each

Bidgoli, et al.          Expires 2 February 2025                [Page 4]
Internet-Draft             PCEP p2mp sr policy               August 2024

   candidate paths can be globally optimized, therefore it is consists
   of multiple path-instances.  A path-instance can be considered as a
   P2MP LSP.  If a candidate path needs to be globally optimized two
   path-instances can be programmed from the root the leaves and via
   make before break procedures the candidate path can be switched from
   path-instance 1 to the 2nd path-instance.  The forwarding states of
   these path-instances are build via replication segments, in short
   each path-instance initiated on the root has its own set of
   replication segments on the Root, Transit and Leaf nodes.

   A replication segment is 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 could also calculate and download additional information for the
   replication segments, such as protections next-hops for link
   protection (FRR).

3.1.  High level view of P2MP Policy Objects

   *  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-ID, Tree-ID> It contains the following
         information:

         o  Root node of the P2MP Segment

         o  Set of Leaf nodes of the P2MP Segment

         o  Tree-ID, which is a unique identifier of the P2MP tree on
            the Root

         o  A set of Candidate paths belonging to the policy

         o  Optional Constraints used to build these candidate paths

   *  Candidate Path:

      -  Is used for P2MP Tree redundancy where the candidate path with
         the highest preference is the active path.

      -  Each Candidate Path can contain two path-instance for global
         optimization procedures (i.e. make before break)

Bidgoli, et al.          Expires 2 February 2025                [Page 5]
Internet-Draft             PCEP p2mp sr policy               August 2024

      -  Contains information regarding originator, discriminator,
         preference, path-instances

   *  Path-instance:

      -  Is used for global optimization of the candidate path.
         Multiple path-instance can be present under a candidate path
         but only a single path instance is active at a time.

      -  A path instance is identified via <Root-ID, Tree-ID, Instance-
         ID>

   *  Replication Segment:

      -  Is the forwarding information needed on each replication node
         for building the forwarding path for each path-instance of the
         P2MP Candidate path.

      -  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)

         o  It is identified via Tree-ID and Root-ID and path-instance
            for non-shared replication segment.

         o  It is identified via Node-ID, Replication-ID, for shared
            replication segment.  As per [draft-ietf-pim-sr-p2mp-policy]
            a shared replication segment is not associated to a tree and
            is used for constructing by-pass tunnels.

         o  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.

         o  On the forwarding plane the Replication Segment is
            identified via the incoming Replication SID.

         o  Replication segment information is downloaded on any node
            that is replicating the packet on the path of the tree
            including the Root, Transit and Leaf nodes respectively.

Bidgoli, et al.          Expires 2 February 2025                [Page 6]
Internet-Draft             PCEP p2mp sr policy               August 2024

3.2.  Existing drafts used for defining a P2MP Policy

   This document attempts to leverage existing IETF draft and RFC
   documents which define PCEP objects, to update the PCE with Root and
   Leaves information when PCC Initiated method is used.  Similarly,
   existing documents are utilized where feasible to update the PCC with
   relevant information to build the P2MP Policy and its Replication
   Segments.  This document introduces new TLVs and Objects specific to
   a programing P2MP policy and its replication segment.

3.2.1.  Existing Documents used by this draft

   *  [RFC8231] The bases for a stateful PCE, and reuses the following
      objects or a variant of them

      -  <SRP Object>

      -  <LSP Object>

      -  A variation of the LSP identifier TLV is defined in this draft,
         to support P2MP LSP Identifier

   *  [RFC8306] P2MP capabilities advertisement

   *  [draft-ietf-pce-segment-routing-policy-cp] Candidate paths for
      P2MP Policy is used for Tree Redundancy.  As an example, a P2MP
      Policy can have multiple candidate paths.  Each protecting the
      primary candidate path.  The active path is chosen via the
      preference of the candidate path.

   *  [RFC3209] Defines the instance-ID, instance-ID is used for global
      optimization of a candidate path with in a P2MP policy.  Each
      Candidate path can have 2 path-instances.  These path-instances
      are equivalent to sub-lsps (instance-IDs).  There are used for MBB
      and global optimization procedures.  instance-ID is equivalent to
      LSP ID

   *  [RFC9256] Segment-list, used for connecting two non-adjacent
      replication policy via a unicast binding SID or Segment-list.

   *  [RFC8306] P2MP End Point objects, used for the PCC to update the
      PCE with discovered Leaves.

   *  [RFC9050] for programming and identifying the Replication Segment.
      A new PCE CC Capability sub Tlv is introduced to indicated the
      support to handle PCE CC based label download for SR P2MP.

Bidgoli, et al.          Expires 2 February 2025                [Page 7]
Internet-Draft             PCEP p2mp sr policy               August 2024

   *  [draft-ietf-pce-multipath] Forwarding instruction for a P2MP LSP
      is defined by a set of SR-ERO sub-objects in the ERO object, ERO-
      ATTRIBUTES object and MULTIPATH-BACKUP TLV as defined in this
      draft.

   *  [RFC8664] SR-ERO Sub Object used in the multipath.

   It should be noted that the [draft-hb-spring-sr-p2mp-policy-yang] can
   provide further details of the high level P2MP Policy Model.

3.2.2.  P2MP Policy Identification

   A P2MP Policy and its candidate path can be identified on the root
   via the P2MP LSP Object.  This Object is a variation of the LSP ID
   Object defined in [RFC8231] and is as follow:

   *  PLSP-ID: [RFC8231], is assigned by PCC and is unique per candidate
      path.  It is constant for the lifetime of a PCEP session.  Stand-
      by candidate paths will be assigned a new PLSP-ID by PCC.  Stand-
      by candidate paths can co-exist with the active candidate path.

   *  Root-ID: is equivalent to the first node on the P2MP path, as per
      [RFC3209], Section 4.6.2.1

   *  Tree-ID: is equivalent to Tunnel Identifier color which identifies
      a unique P2MP Policy at a ROOT and is advertised via the PTA in
      the BGP AD route or can be assigned manually on the root.  Tree-ID
      needs to be unique on the root.

   *  Instance-ID: LSP ID Identifier as defined in RFC 3209, is the
      path-instance identifier and is assigned by the PCE.  The
      candidate path can have up to two path-instance for global
      optimization.  Instance-IDs are assigned by PCE per path-instance,
      they are unique within the P2MP Policy.  Two or more P2MP policy
      can reuse the same Instance-ID assigned to their corresponding
      path-instances.  A path-instance for a candidate path of a P2MP
      policy should program same Instance-ID on the root, transit and
      leaf nodes when it is programing its replication segments on the
      PCC.

3.2.3.  Replication Segment Identification

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

Bidgoli, et al.          Expires 2 February 2025                [Page 8]
Internet-Draft             PCEP p2mp sr policy               August 2024

3.2.4.  PCECC Use in Replication Segment

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

3.3.  High Level Procedures for P2MP SR LSP Instantiation

   A P2MP policy can be instantiated via the PCC or the PCE depending on
   how the root and the leaves are discovered.  This document describes
   two way to discover the root and the leaves:

   *  They can be configured and identified on the controller and are
      considered PCE initiated.

   *  They can be discovered on the PCC via MVPN procedures [RFC6513] or
      legacy multicast protocols like PIM or IGMP etc... and are
      considered PCC initiated.

3.3.1.  PCE-Init Procedure

   *  PCE is informed of the P2MP request through its API or
      configuration mechanism to instantiate a P2MP tunnel.  PCE will be
      programmed with the Root and a set of leaf nodes.

   *  PCE will initiate the P2MP Policy for the request, by sending a
      PCInitiate message to the Root.  The PCInitiate message will be
      programmed with a unique Instance-ID for the path-instance (P2MP
      tunnel) within the P2MP Policy.  For the root PCInitiate message
      ONLY the tree-id should be set to 0 by the PCE, for transit and
      leaf nodes the PCE can set the tree-id same as the tree-id
      assigned by the PCC root.  Note in PCE initiate the endpoint-
      object can be added optionally to the PCInitiate message for
      providing the leaf list to the PCC.

   *  Root in response to the PCInitiate message, will generate PLSP-ID
      for the candidate paths and will use the instantiated Instance-ID
      from the PCE for the Path-Instance (LSP-ID) contained with in the
      candidate path.  The tree-id for the P2MP Policy are filled by the
      PCC root node as well.  PCC will reports back the PLSP-ID and
      tree-id with PCE assigned Instance-ID via PCRpt message

   *  -  Optionally, the Root can add any additional leaves that were
         discovered by multicast procedures in this PCRpt message.

Bidgoli, et al.          Expires 2 February 2025                [Page 9]
Internet-Draft             PCEP p2mp sr policy               August 2024

   *  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 will then send a PCUpdate to the root indicating the
      association information (Candidate path) , and implicitly indicate
      it to bind to the latest CCI information downloaded.

3.3.2.  PCC-Init Procedure

   Root node (PCC) discovers the leaves (as an example via MVPN
   Procedures or other mechanism), the following communication happens
   between the PCE and PCCs

   *  Root sends a PCRpt message for P2MP policy to PCE including the
      Root-ID, Tree-ID, PLSP-ID, symbolic-path-name, and any leaves
      discovered until then.  This PCRpt message also includes a
      association object.  In addition:

   *  -  Since the instance-id is set by the PCE, the root will set the
         instance-id to value to 0 in the RCRpt message

      -  For the association object, root will fill the association type
         according to the association type defined in this draft.  The
         association ID SHOULD be set to value 1 as done in
         [draft-ietf-pce-segment-routing-policy-cp].  The association
         source is set to the Root PCC Address.

   *  PCE on receiving of this report, will generate a Instance-ID for
      this path-instance of the candidate path and compute 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 will then send a PCUpdate to the root indicating the
         association information (Candidate path) , and implicitly
         indicate it to bind to the latest CCI information downloaded.

3.3.3.  Common Procedure

   The following procedures are the same for PCE or PCC Init.

Bidgoli, et al.          Expires 2 February 2025               [Page 10]
Internet-Draft             PCEP p2mp sr policy               August 2024

   *  PCE will download the replication segments for the Candidate-
      path's path-instances to all the leaves and transit nodes using
      PCInitiate message with the same Instance-ID that was assigned for
      the path-instance on the root, PLSP-ID = 0, symbolic path name,
      Root-address, Tree-id(assigned by the root an obtained via P2MP
      Policy creation).  This PCInitiate message includes the EROs
      needed for the replication segments.  These messages will utilize
      the CCI object to encode the forwarding instruction information.

   *  Any new candidate path for the P2MP Policy is downloaded by PCE to
      the Root by sending a PCInitiate message

      -  it should be noted, PLSP-ID, Path-Instance ID are generated by
         the PCC for these new candidate paths and their Path-instances

      -  Any update to the Candidate Paths or Replication Segments is
         done via the PCUpd message.  Association object need to be
         present for Candidate Path PCUpdate and PCRpt message.  CCI
         object needs to be present the replication segment updates.

   *  The PCE will also download the necessary replication segment for
      the candidate path and its path-instances to the root, leaves and
      the transit nodes via a PCInit message

   *  New leaves can be discovered via Multicast procedures, and new
      replication segments can be instantiated or existing one updated
      to reach these leaves

      -  If these leaves reside on routers that are part of the P2MP LSP
         path, then PCUpd is sent from PCE to necessary PCCs (LEAVES,
         TRANSIT or ROOT) with the correct PLSP-ID, Instance-ID, Tree-ID
         and CC-ID.

      -  If the new leaves are residing on routers that are not part of
         the P2MP Tree yet, then a PCInitiate message is sent from PCE
         to these new leaves with PLSP- ID=0 and Instance-ID that the
         PCE has reserved for that path-instance and end to end P2MP
         tree.

   *  The active candidate-path is indicated by the PCC through the
      operational bits(Up/Active) of the LSP object in the PCRpt
      message.  If a candidate path needs to be removed, PCE sends PC
      Initiate message, setting the R-flag in the LSP object and R bit
      in the SRP-object.

   *  To remove the entire P2MP-LSP, PCE needs to send PCInitiate remove
      messages for every candidate path of the P2MP POLICY to the root
      and send PCInitiate remove messages for every Replication Segment

Bidgoli, et al.          Expires 2 February 2025               [Page 11]
Internet-Draft             PCEP p2mp sr policy               August 2024

      on all the PCCs on the P2MP Tree.  The R bit in the LSP Object as
      defined in [RFC8231], 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-LSP-ID-TLV defines to remove all
      the state of the corresponding PLSP-ID.

   *  A candidate path is made active based on the preference of the
      path.  If the Root is programed with multiple candidate paths 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 path will be active

3.3.4.  Global Optimization of the Candidate Path

   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 candidate path is possible.

   Each Candidate Path can contain two Path-Instances.  The current
   unoptimized Path-Instance is the active instance and its replication
   segments are forwarding the multicast PDUs from the root to the
   leaves.  However the second optimized Path-Instance will be setup
   with its own unique replication segments throughout the network, from
   the Root to the leaves.  These two Path-Instances can co-exist.  The
   two Path-Instances are uniquely identified by their Instance-ID in
   the SR-P2MP-INSTANCE-ID-TLV (defined in this document).  After the
   optimized LSP has been downloaded successfully PCC MUST send two
   reports, reporting UP of the new path indicating the new LSP-ID, and
   a second reporting the tear down of the old path 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 leaf should be able to accept traffic from both Path-Instances to
   minimize the traffic outage by the Make Before Break process.

3.3.5.  local optimizatoin

   When one of the PCCs involved in the LSP lacks the capability to
   support more than one instance, the possibility of achieving global
   MBB (make before break) is compromised.  However, with knowledge of
   the PCCs' advertised capabilities, the PCE can detect this limitation
   and instead opt for local re-optimization of the candidate path.  In
   such cases, the PCE can compute the optimized LSP but send the PCUpd
   message using the existing Instance for candidate path, specifically
   targeting the PCCs where the optimized LSP triggers a change in

Bidgoli, et al.          Expires 2 February 2025               [Page 12]
Internet-Draft             PCEP p2mp sr policy               August 2024

   forwarding state.

3.3.6.  Fast Reroute

   Currently this draft identifies the Facility FRR procedures.  In
   addition, only LINK Protection procedures are defined.  How the
   Facility Path is built and instantiated is beyond the scope of this
   document.

             R
            | |
             T
             |
            ---
           |   |
           L1 L2

           Figure 1

             R---F1
             |    |
             T---F2
             |
            ---
           |   |
           L1 L2

           Figure 2

   As an example, in figure 1 both R and T are configured with
   replication segments.  There are two interface 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 2 method 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 utilize to protect the primary interface between
      R and T.

   *  The replication segment provides protection nexthop, the
      protection nexthop can be programmed to take the alternate
      interface between R and T to protect the primary interface.

Bidgoli, et al.          Expires 2 February 2025               [Page 13]
Internet-Draft             PCEP p2mp sr policy               August 2024

   As a second example, in figure 2, R and T 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 and in this case the
   unicast SR LFA or R-LFA or TI-LFA can be used to protect the direct
   link between R-T via F1.  That said if there is no unicast SR
   available with in the network, the PCE optionally can setup 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, PHP procedure and implicit null label on the bypass path
   can be implemented to reduce the PCE programming on the MP PCC.

3.3.7.  Connecting Replication Segment via Segment List

   There could be nodes between two replication segment that do not
   support P2MP Policy or Replication segment.  It is possible to
   connect two non-adjacent Replication segments via a unicast segment
   routing path and SID list.  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 encoding SID list MUST be a
   replication segment

3.4.  SR P2MP Policy and Replication Segment TLVs and Objects

3.4.1.  SR P2MP Policy Objects

   SR P2MP Policy can be constructed via the following objects

     <P2mp Policy> ::= <Common Header>
                       <SRP>
                       <P2MP LSP>
                       <association-list>

   optionally a list of end-point can be added.
   This is true weather it is PCC initiated or PCE initiated

                       [<end-point-list>}

3.4.2.  Replication Segment Objects

   Replication segment can be constructed via the following objects:

Bidgoli, et al.          Expires 2 February 2025               [Page 14]
Internet-Draft             PCEP p2mp sr policy               August 2024

    <Replication Segment> ::= <Common Header>
                              <SRP>
                              <P2MP LSP>
                              (<cci-list>|
                               (<CCI><intended-path>))
                              <cci-list> ::=  <CCI>
                                              [<cci-list>]
                              <intended-path> ::=
                                     ((<PATH-ATTRIB><ERO>)
                                      [<intended-path>])

   Path-attribute as per [draft-ietf-pce-multipath]

3.4.3.  P2MP Policy and Replication Segment general considerations

   The new objects and TLV's defined in this document can be included in
   PCRpt, PcInitiate and PcUpd messages.

   It should be noted that every PcRpt, PcInitiate and PCUpd messages
   will contain full list of the Leaves and segment and forwarding
   information that is needed to build the Candidate path and its
   Replication segments.  They will never send the delta information
   related to the new leaves or forwarding information that need to be
   added or updated.  This is necessary to ensure that PCE or any new
   PCE is in sync with the PCC.

3.4.3.1.  Path Attribute Object

   This draft uses [draft-ietf-pce-multipath] to identify each out-going
   interface in the replication segment.  In addition each out-going
   interface can be protected by a backup path.  The Path Attributes
   Object is used to provide the relation between the primary path and
   its backup path as per draft [draft-ietf-pce-multipath].

   Note: Multipath weight TLV MUST not be used and should be ignored
   when revived.  Composite Candidate Path TLV SHOULD NOt be present and
   ignored if present.

   When a replication segment is being updated or new out-going
   interfaces are added to a specific replication segment, the PCRpt,
   PCInitiate and PCUpd messages sent via PCEP maintains 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.

Bidgoli, et al.          Expires 2 February 2025               [Page 15]
Internet-Draft             PCEP p2mp sr policy               August 2024

3.4.3.2.  CCI Object

   The CCI Object is used to identify the entire cross connect of
   incoming segment and the set of outgoing Interfaces and their
   corresponding SIDs/SIDList.  Any modification to the cross connect
   should use this CCI ID to identify the cross connect uniquely.
   Leaves 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 Central Control Instructions (CCI) Object used by the PCE to
   specify the controller instructions is defined in [RFC9050].
   [draft-ietf-pce-pcep-extension-pce-controller-sr] defines CCI object-
   type for SR-MPLS.  This document redefines a new version of the SR-
   MPLS CCI object-type for SR P2MP Policy in upcoming sections.

4.  Object Format

4.1.  Open Message Extension

   A PCE does not advertise its P2MP capability during discovery, PCEP
   should be used to allow a PCC to discover, during the Open Message
   Exchange, which PCEs are capable of supporting SR P2MP path
   computation.  To satisfy this requirement, we extend the PCEP OPEN
   object by defining an optional TLV to indicate the PCE's capability
   to perform SR P2MP path computations.  This new TLV is called SR-
   P2MP-POLICY-CAPABILITY.  The inclusion of this TLV in an OPEN object
   indicates that the sender can perform SR P2MP path computations.  The
   capability TLV is meaningful only for a PCE, so it will typically
   appear only in one of the two Open messages during PCE session
   establishment.  However, in the case of PCE cooperation (e.g., inter-
   domain), when a PCE behaving as a PCC initiates a PCE session.  it
   SHOULD also indicate its path computation capabilities.

   This draft defines a new SR-P2MP capability TLV with type TBD

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type=TBD       |           Length=4              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Number of Instances    |       number of replication     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Flags          |           reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bidgoli, et al.          Expires 2 February 2025               [Page 16]
Internet-Draft             PCEP p2mp sr policy               August 2024

   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 a
   SR P2MP policy.

   Number of replication 16 bits - number of out going interfaces that
   the system is capable of having per multicast state.

   Flags 16 bits - Not used currently

   Upon the receipt of an Open message, the receiving PCEP peer MUST
   determine whether the suggested PCEP session characteristics (leaf-
   types) are acceptable.  If the suggested leaf-types are not
   acceptable to the receiving peer, it MUST send an PCEP Error message
   (PCErr) with Error-Type=2 (Capability not supported) and error-value
   X (new error type assigned by IANA incompatible SR P2MP leaf types)
   (See Section 4.5.2 for leaf-types)

4.2.  PCE Capabliity SubTLV

   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
   [RFC8664]

4.3.  Association Type Capability

   A Assoc-Type-List TLV as per [RFC8697] section 3.4 should be send via
   PCEP open object with following association type

   +-------------------+----------------------------+------------------+
   | Association Type  | Association Name           | Reference        |
   | Value             |                            |                  |
   +-------------------+----------------------------+------------------+
   | TBD1              | P2MP SR Policy Association | This document    |
   +-------------------+----------------------------+------------------+

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

4.4.  Symbolic Name in PCInit Message from PCC

   This document reuses symbolic path name from [RFC8231] section 7.3.2.
   For P2MP Policy a symbolic path is unique for a Candidate Path of the
   P2MP Policy on the PCC.  It is recommended for the symbolic path name
   to be root-id+tree-id+cp discriminator.

Bidgoli, et al.          Expires 2 February 2025               [Page 17]
Internet-Draft             PCEP p2mp sr policy               August 2024

4.5.  P2MP Policy Specific Objects and TLVs

4.5.1.  P2MP Policy Association Group for P2MP Policy

   Two ASSOCIATION object types for IPv4 and IPv6 are defined in
   [RFC8697].  The ASSOCIATION object includes "Association type"
   indicating the type of the association group.  This document adds a
   new Association type.  Association type = TBD1 "P2MP SR Policy
   Association Type" for SR Policy Association Group (P2MP SRPAG).

   NOTE: for PCC initiate the Association object is present in the first
   PCRpt message that is send by the PCC to PCE to indicate the
   initiation of the P2MP policy and its candidate path, this first
   PCRpt message does not have a corresponding PCUpdate message but it
   does include the Association object accordingly.

   NOTE: The Association Source should be set to the root address of the
   P2MP tree.

   In par with [draft-ietf-pce-segment-routing-policy-cp] section 4.2,
   P2MP policy reuses the four TLVs used in the SRPA object.  P2MP
   policy also redefines the extended association ID TLV:

   1.  SRPOLICY-POL-NAME TLV: (optional) encodes P2MP SR Policy Name

   2.  SRPOLICY-CPATH-ID TLV: (mandatory) encodes P2MP SR Policy
       Candidate path Identifier

   3.  SRPOLICY-CPATH-NAME TLV: (optional) encodes P2MP SR Policy
       Candidate path name.

   4.  SRPOLICY-CPATH-PREFRENCE TLV: (optional) encodes P2MP SR Policy
       Candidate path preference value.

   5.  In addition to above the extended association ID TLV has been
       modified to address the P2MP Policy

4.5.1.1.  Extended Association ID TLV

   In par with [draft-ietf-pce-segment-routing-policy-cp] the Extended
   Association ID TLV MUST be included and it MUST be in the following
   format for the P2MP Policy

Bidgoli, et al.          Expires 2 February 2025               [Page 18]
Internet-Draft             PCEP p2mp sr policy               August 2024

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Type = 31            |             Length = 4        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          TREE-ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length: 4 byte

   Tree-ID: Tree ID that the replication segment is part of as per
   draft-ietf-spring-sr-p2mp-policy

4.5.2.  P2MP-END-POINTS Object

   In order for the Root to indicate operations of its
   leaves(Add/Remove/Replace-all), the PC Report message is extended to
   include P2MP End Point <P2MP End-points> Object which is defined in
   [RFC8306]

   It SHOULD be noted, the absence of the P2MP-END-POINTS Object means
   that there is no change in the leaf endpoint of the policy.

   The format of the PC Report message is as follow:

   <Common Header>

   [<SRP>]

   <LSP>

   [<association-list>]

   [<end-points-list>]

Bidgoli, et al.          Expires 2 February 2025               [Page 19]
Internet-Draft             PCEP p2mp sr policy               August 2024

      IPV4-P2MP END-POINTS:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Leaf type                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Source IPv4 address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                           ...                                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Destination IPv4 address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IPV6-P2MP END-POINTS:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Leaf type                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                Source IPv6 address (16 bytes)                 |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |              Destination IPv6 address (16 bytes)              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                           ...                                 ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |              Destination IPv6 address (16 bytes)              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Leaf Types (derived from [RFC8306] section 3.3.2) :

   1.  New leaves to add (leaf type = 1)

   2.  Old leaves to remove (leaf type = 2)

   3.  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.

Bidgoli, et al.          Expires 2 February 2025               [Page 20]
Internet-Draft             PCEP p2mp sr policy               August 2024

   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 leaves of a given type.
   Note that a P2MP report can mix the different types of leaves 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.

4.6.  P2MP Policy and Replication Segment Identifier Object and TLV

   As it was mentioned previously both P2MP Policy and Replication
   Segment are identified via the LSP object and more precisely via the
   SR-P2MP-LSPID-TLV

   The P2MP Policy uses the PLSP-ID to identify the Candidate Paths and
   the Instance-ID to identify a Path-Instance with in the Candidate
   path.

   On other hand the Replication Segment uses the SR-P2MP-LSPID-TLV to
   identify and correlate a Replication Segment to a P2MP Policy

   As it was noted previously on the Root, the P2MP Policy and the
   Replication Segment is downloaded via the same PCUpd message.

4.6.1.  Extension of the LSP Object, SR-P2MP-LSPID-TLV

   The LSP Object is defined in Section 7.3 of [RFC8231].  It specifies
   the PLSP-ID to uniquely identify an LSP that is constant for the life
   time of a PCEP session.  Similarly, for a P2MP tunnel, the PLSP-ID
   identify a Candidate Path uniquely with in the 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 [draft-ietf-pce-stateful-pce-p2mp]

Bidgoli, et al.          Expires 2 February 2025               [Page 21]
Internet-Draft             PCEP p2mp sr policy               August 2024

 IPV4-SR-P2MP-INSTANCE-ID-TLV:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=TBD            |           Length=10           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Root                                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Tree-ID                                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Instance-ID           | Reserved      |  Flags    |R|A|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 IPv6-SR-P2MP-INSTANCE-ID-TLV :

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=TBD            |           Length=22           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                  Root                                         |
       +                          (16 octets)                          +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Tree-ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Instance-ID           | Reserved      |  Flags    |R|A|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 : Contains 32 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

Bidgoli, et al.          Expires 2 February 2025               [Page 22]
Internet-Draft             PCEP p2mp sr policy               August 2024

   At any given time, only one instance SHOULD be active.  Activating
   one instance entails deactivating all other instances, with the
   condition that the active instance MUST have a non-zero value.

   The (A) flag is meaningful for Root PCC and PCEs.  PCE MUST be
   setting (A) flag in the PCupd containing SR-P2MP-INSTANCE-ID TLV for
   activating the instance.  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 instance 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 instance is not within the scope of this document.  After the
   activation of the 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 an PCEP Error
   message (PCErr) with Error-Type=10 (Reception of an Invalid Object)
   and error-value (X) (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 an
   PCEP Error message (PCErr) with Error-Type=19 (Invalid Operation) and
   error-value (X) (Attempted activating instance on Transit or leaf
   PCC).

Bidgoli, et al.          Expires 2 February 2025               [Page 23]
Internet-Draft             PCEP p2mp sr policy               August 2024

                     +-+-+                    +-+-+
                     |PCC|                    |PCE|
                     +-+-+                    +-+-+
                       |                        |
   1) LSP state Report | -------- PCRpt ------> |
      With PLSP-ID and |  (SRP,                 |
      Instance ID      |   LSP (SR-P2MP-LSPID), |
                       |   P2MP-END-POINT)      |
                       |                        |
                       | <------- PCUpd ------- |2) PCUpd message sent
                       |  (SRP,                 |   to the PCC with
                       |   LSP (SR-P2MP-LSPID), |   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)         |                        |
                       |                        |

4.7.  Replication Segment

   As per [draft-ietf-spring-sr-replication-segment] 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.  This means two replication
   segments can be directly connected or connected via a unicast SR
   domain.

4.7.1.  The format of the replication segment message

   The format of a Replication Segment message encoding is similar to
   P2MP Policy.  However, the P2MP Policy contains the association
   object and the replication segment message does not contain the
   association object.  In addition the replication segment uses the CCI
   object to identify a P2MP cross connect.  The replication segment is
   downloaded individually to the root, transit and leaf nodes without
   the P2MP Policy.  The P2MP Policy is a Root Concept.  The replication
   segment uses SR-P2MP-LSPID-TLV as its identifier.  The TLV is coded
   differently for shared and non-shared case

Bidgoli, et al.          Expires 2 February 2025               [Page 24]
Internet-Draft             PCEP p2mp sr policy               August 2024

4.7.2.  PCECC

   The CCI Object as defined in [RFC9050] is used to identify a
   forwarding instruction in the Replication Segment.  A forwarding
   instruction is incoming SID and a set of outgoing branches.  The CCI
   Object-Type of 1 is used for the MPLS Label.  The label in the CCI
   Object is the incoming SID.  The outgoing SIDs are defined by the ERO
   Objects.

   The CCI Object can be include in Reports, initiate and Update
   messages for Replication Segments.

   The PCInitiate message defined in [RFC8281] and extended in [RFC9050]
   is further extended to support SR-P2MP replication segment based
   central control instructions.

    The format of the extended PCInitiate message is as follows:
         <PCInitiate Message> ::= <Common Header>
                                  <PCE-initiated-lsp-list>
      Where:
         <Common Header> is defined in "RFC5440"

         <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
                                      [<PCE-initiated-lsp-list>]

         <PCE-initiated-lsp-request> ::=
                              (<PCE-initiated-lsp-instantiation>|
                               <PCE-initiated-lsp-deletion>|
                               <PCE-initiated-lsp-central-control>)

         <PCE-initiated-lsp-central-control> ::= <SRP>
                                                 <LSP>
                                                 (<cci-list>|
                                                 (<CCI><intended-path>))

         <cci-list> ::=  <CCI>
                         [<cci-list>]

       <intended-path> ::= ((<PATH-ATTRIB><ERO>)
                           [<intended-path>])

      Where:
          <PCE-initiated-lsp-instantiation> and
          <PCE-initiated-lsp-deletion> are as per
          [RFC8281].

   The LSP and SRP object is defined in [RFC8231].  The <intended-path>
   is as per [RFC8281] [draft-ietf-pce-multipath] (PATH-ATTRIB and ERO).

Bidgoli, et al.          Expires 2 February 2025               [Page 25]
Internet-Draft             PCEP p2mp sr policy               August 2024

The format of the PCRpt message is as follows:

         <PCRpt Message> ::= <Common Header>
                             <state-report-list>
      Where:

         <state-report-list> ::= <state-report>[<state-report-list>]

         <state-report> ::= (<lsp-state-report>|
                             <central-control-report>)

         <lsp-state-report> ::= [<SRP>]
                                <LSP>
                                <path>

         <central-control-report> ::= [<SRP>]
                                      <LSP>
                                      (<cci-list>|
                                      (<CCI><intended-path>))

         <cci-list> ::=  <CCI>
                         [<cci-list>]

       Where:
         <path> is as per [RFC8231] and the LSP and SRP object are
         also defined in [RFC8231].
         The <intended-path> is as per [draft-ietf-pce-multipath] (PATH-ATTRIB
         and ERO).

   This document extends the use of PCUpd message with SR-P2MP CCI as
   follows:

Bidgoli, et al.          Expires 2 February 2025               [Page 26]
Internet-Draft             PCEP p2mp sr policy               August 2024

      <PCUpd Message> ::= <Common Header>
                          <update-request-list>
   Where:

      <update-request-list> ::= <update-request>[<update-request-list>]

      <update-request> ::= (<lsp-update-request>|
                             <central-control-update>)

      <lsp-update-request> ::= <SRP>
                               <LSP>
                               <path>

      <central-control-update> ::= <SRP>
                                   <LSP>
                                   (<CCI><intended-path>)

   Where:
      <path> is as per [RFC8231] and the LSP and SRP object are
      also defined in [RFC8231].
      The <intended-path> is as per [draft-ietf-pce-multipath] (PATH-ATTRIB
      and ERO).

4.7.3.  Label action rules in replicating segment

   Any modification to the cross connect should use this CCI ID to As
   per [draft-ietf-spring-sr-replication-segment] a replication identify
   the cross connect uniquely.  Leaves and their corresponding segment
   has a next-hop-group which MAY contain a single outgoing Path IDs can
   be removed from the cross connect identified via the replication SID
   or a list of SIDs (sr-policy-sid-list) In either case CCI.  The CC-ID
   is assigned by the PCE.

   [draft-ietf-pce-pcep-extension-pce-controller-sr] defines CCI object-
   type for SR-MPLS.  This document redefines a new version of the SR-
   MPLS CCI object-type for SR P2MP Policy in upcoming sections.

Bidgoli, et al.          Expires 2 February 2025               [Page 27]
Internet-Draft             PCEP p2mp sr policy               August 2024

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            CC-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MT-ID    |    Algorithm  | role  |     flags         |V|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SID/Label/Index                         |
   +---------------------------------------------------------------+
   |                                                               |
   //                        Optional TLV                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Flags:

   The V and the L flags are defined as per
   [draft-ietf-pce-pcep-extension-pce-controller-sr]

   The node action and role of ingress, transit, leaf or bud, is
   indicated via the 4 bit roles field

   *  Head, role type = 1

   *  Transit, role type = 2

   *  Leaf, role type = 3

   *  Bud, role type = 4

4.7.4.  SR-ERO Rules

   Forwarding information of a replication segment can be configured and
   steered via many different mechanisms.  RFC [RFC8664] defines the NAI
   types.

   As an example a replication SID can be steered via:

   1.  Replication SID steered with an IPv4/IPv6 directly connected
       nexthop (RFC 8664 NAI type 3, 4, 6 (adjacency))

       *  In this case there will two SR-ERO in the ERO Object, with the
          Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO
          on the top.

   2.  Replication SID steered with an IPv4/IPv6 loopback address that
       reside on the directly connected router.  (NAI type 1..2 (node))

Bidgoli, et al.          Expires 2 February 2025               [Page 28]
Internet-Draft             PCEP p2mp sr policy               August 2024

       *  In this case there will two SR-ERO in the ERO Object, with the
          Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO
          on the top.

   3.  Replication SID steered with unnumbered IPv4/IPv6 directly
       connected Interface (NAI type 5 (adjacency unnumbered)

   4.  Replication SID steered via a 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.

5.  Tree Deletion

   The P2MP policy and its replication segment can be delete by the PCC
   or by the PCE. to delete the P2MP policy all the Candidate paths
   associated to that P2MP policy need to be deleted.  The last
   Candidate path that is being deleted, will delete the P2MP Policy
   Instance as well on the PCE or PCC.

   To delete Candidate paths there are two methods:

   1.  The Candidate paths can be deleted by deleting all the path-
       instances associated with them and the last path-instance that is
       deleted will trigger the Candidate path to be deleted.

   2.  The Candidate path can be deleted entirely and this will delete
       all the associated path-instances for that candidate path as
       well.

   When PCE is deleting a Candidate path or a path instance it should
   delete all the replication segments of that Candidate path or path-
   instance as well before it moved to the next Candidate path or path
   instance.

5.1.  PCC Initiated

   For PCC to delete a Candidate path, Root send a PCRpt message with
   the R bit of the LSP object set and all the fields of the SR-P2MP-
   LSP-ID TLV set to 0(indicating to remove all state and path-instances
   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 can be set 0 with the R bit set to indicate
   removing the entire Candidate path and all its path-instances.

Bidgoli, et al.          Expires 2 February 2025               [Page 29]
Internet-Draft             PCEP p2mp sr policy               August 2024

   For PCC to delete a path-instance, Root send a PCRpt message with the
   R bit of the LSP object set and all the fields of the SR-P2MP- LSP-ID
   TLV set to 0 but the instance-id value (indicating to remove the
   specific path-instances 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 path-instances.  This is
   useful for the global optimization case where after downloading the
   optimize path-instance and ensuring the path-instance is operational
   the PCC removed that old path-instance.

5.2.  PCE Initiated

   For PCE to delete the Candidate path or path instance, the above can
   be implemented without the PCC PCRpt message.

6.  Fragmentation

   The Fragmentation bit in the LSP object (F bit) can be used to
   indicate a fragmented PCEP message

7.  Some packet examples

7.1.  Report for Leaf Add

   This is an example of PCC initiated P2MP Policy.  The PCC will send a
   Report message to the PCE to initiat a P2MP Policy with a set of
   leaves that are discovered via Next Generation MVPN procedures as per
   [RFC6513].

   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 Path-Instance to 0 and the instance-id is
   assigned by the PCE.

Bidgoli, et al.          Expires 2 February 2025               [Page 30]
Internet-Draft             PCEP p2mp sr policy               August 2024

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Flags = 0                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SRP-ID-number  = 0                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  TLV Type = 28 (PathSetupType)| TLV Len = 4                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                             | PST = TBD       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                <LSP OBJECT>
       |                PLSP-ID = 1            |     A:1,D:1,N:1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=17             |           Length=<var>        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            symbolic path name                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type=TBD          |  Length                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Root = A                                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Tree-ID = Y                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Instance-ID = 0                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               <P2MP END POINT OBJECT>
       |                          Leaf type = 5                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Source IPv4 address = A                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Destination IPv4 address = D                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Destination IPv4 address = E                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.2.  P2MP Policy Candidate path Init

   The following packet is the PCE creating the candidate path for the
   P2MP Policy and downloading the replication segment with the same
   message on the root.

   It should be noted combining the P2MP Policy candidate path 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.

Bidgoli, et al.          Expires 2 February 2025               [Page 31]
Internet-Draft             PCEP p2mp sr policy               August 2024

   The PLSP-ID are populated with the same ID as the previous PCC report
   message and the Instance-ID is assigned by the PCE.

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Flags = 0                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SRP-ID-number  = 1                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  TLV Type = 28 (PathSetupType)| TLV Len = 4                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                             | PST = TBD       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              <LSP OBJECT>
       |                PLSP-ID = 1            |     A:1,D:1,N:1,C:0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=17             |           Length=<var>        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            symbolic path name                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type=TBD          |  Length                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Root =A                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Tree-ID = Y                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Instance-ID = L1                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             <ASSOCIATION OBJECT>
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Reserved              |            Flags            |0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Association type= SR-P2MP-PAG |      Association ID = z       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              IPv4 Association Source = <pce-address>          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type=P2MP SR Policy ID    |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Root  = A                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           TREE-ID = 0                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type=P2MP SR Policy Name   |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                     P2MP SR Policy Name                       ~
       |                                                               |

Bidgoli, et al.          Expires 2 February 2025               [Page 32]
Internet-Draft             PCEP p2mp sr policy               August 2024

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=P2MP SR Pol Cand-path ID  |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |ProtOrigin 10  |    Reserved                                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Originator ASN                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       Originator Address = <pce-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 <default>          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               <P2MP END POINT OBJECT>
       |                          Leaf type = 5                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Source IPv4 address = A                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Destination IPv4 address = D                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Destination IPv4 address = E                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             <CCI OBJECT>
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            CC-ID = X                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Reserved1            |             Flags         |0|0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Label = 0             |     Reserved2         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        <PATH-ATTRIBUTES OBJECT>
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Flags                           | Oper|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bidgoli, et al.          Expires 2 February 2025               [Page 33]
Internet-Draft             PCEP p2mp sr policy               August 2024

       |                              ERO-path Id = 1                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Backup Path Count = 1   |             Flags           |0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Backup Path ID 2                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=Node Role      |           Length=4            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Role = ingress |                 Reserved                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            <ERO-OBJECT>
                          <SR-ERO-SUB OBJECT>

       |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                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        <PATH-ATTRIBUTES OBJECT>
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Flags                           | Oper|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ERO-path Id = 2                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Backup Path Count = 0   |             Flags           |1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=TBD            |           Length=4            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Role = ingress |                 Reserved                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            <ERO-OBJECT>
                          <SR-ERO-SUB OBJECT>

       |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                              |

Bidgoli, et al.          Expires 2 February 2025               [Page 34]
Internet-Draft             PCEP p2mp sr policy               August 2024

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7.3.  Replication segment PCE Initiated on Transit and LEaves

   The following packet examples shows the replication segment
   initiation via a PCE on transit nodes and/or leaves node.

   Note:

   1.  This packet is generated from PCE to instantiate the replication
       segment, as such the PLSP-ID is set to zero.  PCC will assign
       these value and report them back to PCE.

   2.  The instance-id was assigned by the PCE for the entire path-
       instance (P2MP tree)

   3.  This is a replication segment instantiation as such there is no
       association object.

   4.  The LSP Object Root A and Tree-ID Y associates this replication
       segment to the corresponding Candidate path and path instance on
       the root node.

   there is no association object present in the packet.

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Flags = 0                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        SRP-ID-number  = 1                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  TLV Type = 28 (PathSetupType)| TLV Len = 4                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                             | PST = TBD       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              <LSP OBJECT>
       |                PLSP-ID = 0            |     A:1,D:1,N:1,C:0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=17             |           Length=<var>        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            symbolic path name                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type=TBD          |  Length                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Root =A                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Tree-ID = Y                                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bidgoli, et al.          Expires 2 February 2025               [Page 35]
Internet-Draft             PCEP p2mp sr policy               August 2024

       |                        Instance-ID = L1                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             <CCI OBJECT>
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            CC-ID = X                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Reserved1            |             Flags         |0|0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Label = d1            |     Reserved2         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        <PATH-ATTRIBUTES OBJECT>
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Flags                           | Oper|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ERO-path Id = 1                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Backup Path Count = 1   |             Flags           |0|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Backup Path ID 2                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=TBD            |           Length=4            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Role           |                 Reserved                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            <ERO-OBJECT>
                          <SR-ERO-SUB OBJECT>

       |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                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        <PATH-ATTRIBUTES OBJECT>
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Flags                           | Oper|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ERO-path Id = 2                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Bidgoli, et al.          Expires 2 February 2025               [Page 36]
Internet-Draft             PCEP p2mp sr policy               August 2024

       |       Backup Path Count = 0   |             Flags           |1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Type=TBD            |           Length=4            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Role           |                 Reserved                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            <ERO-OBJECT>
                          <SR-ERO-SUB OBJECT>

       |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                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.  Example Workflows

                 +-------+                             +-------+
                  |PCC    |                             |  PCE  |
                  |Root   |                             +-------+
           +------|       |                                 |
           | PCC  +-------+                                 |
           | Transit| |                                     |
    +------|        | |---PCRpt,PLSP-ID=1,SRP-ID=1--------->| PCECC LSP
    |PCC   +--------+ |   N=1,root-addr,tree-id=a,          | SR-Policy
    |        |  |     |   instance-id =0,                   | Report to
    |Leaf    |  |     |   p2mp-end-points(LeafType=5)(optnl)| PCE
    +--------+  |     |   association-obj                   |
        |       |     |                                     |
        |       |     |<--PCUpdate,PLSP-ID=1, SRP-ID =1,    | Update
        |       |     |   root-addr,tree-id=a,instance-id=b,| CP
        |       |     |   p2mp-end-points, association-obj  |
        |       |     |                                     |
        |       |     |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->|
        |       |     |   root-addr,tree-id=a,instance-id=b,|
        |       |     |      p2mp-end-points(LeafType=5)    |
        |       |     |      association-object             |
        |       |     |                                     |
        |<---------------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,|

Bidgoli, et al.          Expires 2 February 2025               [Page 37]
Internet-Draft             PCEP p2mp sr policy               August 2024

        |       |     |       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=1,             | 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-points(LeafType=5)    |
        |       |     |      path-attriute,ERO,SR-ERO       |
        |       |     |                                     |
        |       |     |<--PCUpdate,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-points(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

                 +-------+                             +-------+
                  |PCC    |                             |  PCE  |
                  |Root   |                             +-------+
           +------|       |                                 |
           | PCC  +-------+                                 |
           | Transit| |                                     |

Bidgoli, et al.          Expires 2 February 2025               [Page 38]
Internet-Draft             PCEP p2mp sr policy               August 2024

    +------|        | |                                     | PCECC LSP
    |PCC   +--------+ |                                     |
    |        |  |     |                                     |
    |Leaf    |  |     |                                     |
    +--------+  |     |                                     |
        |       |     |<--PCInitiate,PLSP-ID=0,             | Initiate
        |       |     |   root-addr,tree-id=0,instance-id=b,| CP
        |       |     |   p2mp-end-points, association-obj  |
        |       |     |                                     |
        |       |     |-------PCRpt,PLSP-ID=1,------------->|
        |       |     |   root-addr,tree-id=a,instance-id=b,|
        |       |     |      p2mp-end-points(LeafType=5)    |
        |       |     |      association-object,            |
        |       |     |                                     |
        |       |     |<--PCUpdt,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-attriute,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, -------------|

Bidgoli, et al.          Expires 2 February 2025               [Page 39]
Internet-Draft             PCEP p2mp sr policy               August 2024

        |       |     |   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      |
        |       |     |                                     |
        |       |     |<--PCUpdate,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:

Common (PCE-INIT, PCC-INIT) MBB

                 +-------+                             +-------+
                  |PCC    |                             |  PCE  |
                  |Root   |                             +-------+
           +------|       |                                 |
           | PCC  +-------+                                 |
           | Transit| |                                     |
    +------|        | |                                     | PCECC LSP
    |PCC   +--------+ |                                     |
    |        |  |     |                                     |
    |Leaf    |  |     |                                     |
    +--------+  |     |                                     |
        |<---------------PCInitiate,PLSP-ID=1, -------------| Download
        |       |     |   root-addr,tree-id=a,instance-id=b,| new RS on
        |       |     |  CC-ID=Z1,C=0,                      | Leaf
        |       |     |  O=0,L=z1,path-attribute,ERO,SR-ERO |
        |       |     |                                     |
        |---------------------PCRpt,PLSP-ID=1-------------->|
        |       |     |   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-------------->|

Bidgoli, et al.          Expires 2 February 2025               [Page 40]
Internet-Draft             PCEP p2mp sr policy               August 2024

        |       |     |   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-attriute,ERO,SR-ERO       |
        |       |     |                                     |
        |       |     |<--PCUpdate,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-attriute,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      |
        |       |     |                                     |

Bidgoli, et al.          Expires 2 February 2025               [Page 41]
Internet-Draft             PCEP p2mp sr policy               August 2024

        |<---------------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      |

9.  IANA Consideration

9.1.  PCEP P2MP Association type

   This draft defines a new Association type for P2MP SR Policy.  IANA
   is requested to allocate a new value from the existing IANA Registry
   "ASSOCIATION TYPE Field" within the "Path Computation Element
   Protocol (PCEP) Numbers" registry group.

   +----------+----------------------------+-----------------+
   | Type     | Name                       | Reference       |
   +----------+----------------------------+-----------------+
   | TBD1     | P2MP SR Policy Association | This document   |
   +----------+----------------------------+-----------------+

9.2.  Endpoint Type

   [RFC8306] 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 [RFC8306] and adds a
   new Leaf type.  IANA is requested to create a new "Endpoint Leaf
   Types" registry with the allocation policy as IETF Review [RFC8126].
   This new registry contains the following values:

Bidgoli, et al.          Expires 2 February 2025               [Page 42]
Internet-Draft             PCEP p2mp sr policy               August 2024

   +----------+----------------------------+-----------------+
   | Value    | Description                | Reference       |
   +----------+----------------------------+-----------------+
   | 0        | Reserved                   | This document   |
   +----------+----------------------------+-----------------+
   | 1        | New leaves to add          | RFC 8306        |
   +----------+----------------------------+-----------------+
   | 2        | Old leaves to remove       | RFC 8306        |
   +----------+----------------------------+-----------------+
   | 3        | Old leaves whose path can  | RFC 8306        |
   |          | be modified/reoptimized    |                 |
   +----------+----------------------------+-----------------+
   | 4        | Old leaves whose path must | RFC 8306        |
   |          | be left unchanged          |                 |
   +----------+----------------------------+-----------------+
   | 5        | All old leaves overwritten | This document   |
   |          | and replaced with the new  |                 |
   +----------+----------------------------+-----------------+

   To keep it consistent with the Generalized Endpoint Types [RFC8779],
   this draft defines a new Endpoint Type in the "Generalized Endpoint
   Types" registry as follows:

       +-----------+---------------------+-----------------+
       | Value     | Type                | Reference       |
       +-----------+---------------------+-----------------+
       | TBD2      | Point-to-Multipoint | This document   |
       |           | with leaf type 5    |                 |
       +-----------+---------------------+-----------------+

   The Authors are requesting value 5 for this new endpoint type.

9.3.  PCEP TLV Type Indicators

   This draft 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 draft defines two new TLVs for Identifying the P2MP
   Policy and the Replication segment with IPv4 or IPv6 root address.

   IANA is requested to allocate a new value from the IANA Registry
   "PCEP TLV Type Indicators"

Bidgoli, et al.          Expires 2 February 2025               [Page 43]
Internet-Draft             PCEP p2mp sr policy               August 2024

       +------------+------------------------------+----------------+
       | TLV Type   | Description                  | Reference      |
       | Value      |                              |                |
       +------------+------------------------------+----------------+
       | TBD3       | SR-P2MP-POLICY-CAPABILITY    | This document  |
       +------------+------------------------------+----------------+
       | TBD4       | IPV4-SR-P2MP-INSTANCE-ID TLV | This document  |
       +------------+------------------------------+----------------+
       | TBD5       | IPV6-SR-P2MP-INSTANCE-ID TLV | This document  |
       +------------+------------------------------+----------------+

9.4.  New CCI Object Type

   This draft defines a new CCI Object type SR P2MP Policy.

   IANA is requested to allocate new codepoints in the "PCEP Objects"
   sub-registry as follows:

       +-------------+----------------------+----------------+
       | Object Class| Name                 | Reference      |
       | Value       |                      |                |
       +-------------+----------------------+----------------+
       | 44          | CCI Object           |                |
       |             | Object-Type          |                |
       |             | TBD6: SR P2MP Policy | This document  |
       +-------------+----------------------+----------------+

10.  Security Considerations

   TBD

11.  Acknowledgments

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

12.  Informative References

   [draft-hb-spring-sr-p2mp-policy-yang]
              "H.Bidgoli, D. Yoyer, R. Parekh, T.Saad, T.kundu "YANG
              Data Model for p2mp sr policy"", October 2020.

   [draft-ietf-pce-multipath]
              "M. Koldychev, S. Sivabalan, T. Saad, H. Bidgoli, B.
              Yadav, S.  Peng, G. Mishra "PCEP Extensions for Signaling
              Multipath Information"", November 2022.

Bidgoli, et al.          Expires 2 February 2025               [Page 44]
Internet-Draft             PCEP p2mp sr policy               August 2024

   [draft-ietf-pce-pcep-extension-pce-controller-sr]
              "Z. Li, S. Peng, M. negi, Q. Zhao, C. Zhau "PCEP
              Extensions for Using PCE as a PCECC for SR MPLS SID"".

   [draft-ietf-pce-segment-routing-policy-cp]
              "M. Koldychev, S. Sivabalan, C. Barth, S. Peng, H. Bidgoli
              "PCEP extension to support Segment Routing Policy
              Candidate Paths", October 2022.

   [draft-ietf-pce-stateful-pce-p2mp]
              "U. Palle, D. Dhody, Y.Tanaka, V. Beeram "Protocol
              Extensions for Stateful PCE usage for Point-to-Multipoint
              Traffic Engineering Label"", April 2019.

   [draft-ietf-pim-sr-p2mp-policy]
              "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
              "Segment Routing Point-to-Multipoint Policy"", October
              2019.

   [draft-ietf-spring-sr-replication-segment]
              "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, "SR
              Replication Segment for Multi-point Service Delivery"",
              July 2020.

   [RFC2119]  ""Key words for use in RFCs to Indicate Requirement
              Levels"", March 1997.

   [RFC3209]  "D. Awduche, L. Berger, T. Li, V. Srinivasan, G. Swallow
              "RSVP-TE: Extensions to RSVP for LSP Tunnels"", December
              2001.

   [RFC5440]  "JP. Vasseur,JL. Le Roux "Path Computation Element
              Communication Protocol"", March 2009.

   [RFC6513]  "E. Rosen, R. Aggerwal "Multicast in MPLS/BGP IP VPNs"",
              February 2012.

   [RFC8126]  "M. Cotton, B. Leiba, T. Narten "Guidelines for Writing an
              IANA Considerations Section in RFCs"", June 2017.

   [RFC8231]  "E. Crabbe, I. Minei, J. Medved, R. Varga "PCEP Extensions
              for Stateful PCE"", September 2017.

   [RFC8281]  "E. Crabbe, I. Minei, S. Sivabalan, R. Varga "PCEP
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model"", December 2017.

Bidgoli, et al.          Expires 2 February 2025               [Page 45]
Internet-Draft             PCEP p2mp sr policy               August 2024

   [RFC8306]  "Q. Zhao, D. Dhody, R. Palleti, D.King "PCEP for Point-to-
              Multipoint Traffic Engineering Label Switched Paths"",
              November 2017.

   [RFC8664]  "S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J.
              Hardwick "PCEP Extensions for Segment Routing"", December
              2019.

   [RFC8697]  "I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D.
              Dhody, Y. Tanaka "PCEP Extensions for Establishing
              Relationships between Sets of LSPs"", January 2020.

   [RFC8779]  "C. Margaria, O. Gonzalez, F. Zhang "PCEP extensions for
              GMPLS"", July 2020.

   [RFC9050]  "Z. Li, S. Peng, M. Negi, Q. Zhao, C. Zhou "PCEP
              Procedures and Extensions for Using the PCECC"", July
              2021.

   [RFC9256]  "C. Filsfils, K. Talaulikar, D. Voyer, A. Bogdanov, P.
              Mattes "Segment Routing Policy Architecture"", July 2022.

Authors' Addresses

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

   Daniel Voyer
   Bell Canada
   Montreal
   Canada
   Email: daniel.voyer@bell.ca

   Saranya Rajarathinam
   Nokia
   Mountain View,
   United States of America
   Email: saranya.Rajarathinam@nokia.com

Bidgoli, et al.          Expires 2 February 2025               [Page 46]
Internet-Draft             PCEP p2mp sr policy               August 2024

   Anuj Budhiraja
   Cisco System
   San Jose,
   United States of America
   Email: abudhira@cisco.com

   Rishabh
   Cisco System
   San Jose,
   United States of America
   Email: riparekh@cisco.com

   Siva Sivabalan
   Ciena
   Ottawa
   Canada
   Email: ssivabal@ciena.com

Bidgoli, et al.          Expires 2 February 2025               [Page 47]