PCEP extensions for p2mp sr policy

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

• [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.¶

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

• 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.¶

• 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 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 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.¶

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.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:¶

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

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¶

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

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

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

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.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]¶

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¶

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

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

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

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

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

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

   • 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.¶