PCEP extensions for P2MP SR Policy

4.2.1. SR P2MP Policy and Candidate Path Identification

A SR 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. Each additional Candidate path is assigned a new PLSP-ID by PCC. Multiple Candidate paths can co-exist but only one is active.¶

• Root-ID: is equivalent to the first node on the SR P2MP path.¶

• Tree-ID: an identifier that is unique in context of the Root node. This value may be assigned manually on the Root node or advertised via the Provider Tunnel Association(PTA) in a multicast BGP Auto-Discovery(AD) route.¶

• Instance-ID: serves as the path-instance identifier and is assigned by the PCE. A candidate path can have up to two path instances for global optimization. Instance-IDs are unique within the SR P2MP policy and are assigned by the PCE per path instance. While different P2MP policies may use the same Instance-ID for their path instances, each path instance within a candidate path of an SR P2MP policy should use the same Instance-ID across the Root, Transit, and Leaf nodes when programming its replication segments on the PCC.¶

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

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

4.3.1. PCE-Init Procedure

• PCE is informed through its API or configuration mechanism to instantiate a SR P2MP Policy. PCE is configured with the Root and a set of Leaf nodes.¶

• PCE computes a P2MP tree from the Root node to all Leaf nodes which satisfy the configured constraints.¶

• PCE sends a PcInitiate message to the Root. The PcInitiate message is configured with a unique Instance-ID for the path-instance within the SR P2MP Policy. The PcInitiate message sent to the root MUST set the Tree-ID to 0. The endpoint-object MAY optionally be included in the PcInitiate message for providing list of Leaf nodes to the PCC for informational purposes.¶

• In response to the PcInitiate message, the PCC will assign the PLSP-ID and Tree-ID for the Candidate path. The PCC uses the Instance-ID defined in the PcInitiate message for the Path Instance contained within the Candidate Path. The PCC sends a PcRpt back to PCE containing the PLSP-ID, Tree-ID and Instance-ID. PCC MAY optionally include additional Leaf nodes that were also discovered by multicast procedures¶

• PCE will send a PCInitiate message to the Root, Transit and the Leaf nodes to download the Replication Segment information. These messages will utilize the CCI object to identify the p2mp cross connect and encode the forwarding instruction information.¶

• PCE then sends a PCUpdate to the Root node indicating the association information (Candidate path) and implicitly binds the Candidate path to the installed CCI information.¶

4.3.2. PCC-Init Procedure

• Root node PCC discovers the leaf nodes via MVPN procedures or other mechanism¶

• Root sends a PCRpt message for SR P2MP policy to PCE including the Root-ID, Tree-ID, PLSP-ID, symbolic-path-name, association object and any leaf nodes discovered. In addition:¶

• • Since the instance-id is set by the PCE, the root will set the instance-id to 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 document. The association ID SHOULD be set to value 1 similar to [draft-ietf-pce-segment-routing-policy-cp]. The association source is set to the Root PCC Address.¶

• PCE receives the PcRpt and generates a unique 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.¶

4.3.3. Common Procedures

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

4.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 MAY contain two Path-Instances. The current unoptimized Path-Instance is the active instance and its replication segments are forwarding the multicast packets 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 leaf nodes. These two Path-Instances MAY 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 Path-Instance 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 transit and leaf nodes SHOULD be able to accept traffic from both Path-Instances to minimize the traffic outage by the Make Before Break process.¶

It is recommended for the optimized Path-Instance to be setup up by PCE from the leaf nodes to transit nodes and finally the root nodes to ensure the entire Path-Instance is programmed before the MBB procedure is initiated.¶

4.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 make before break (MBB) is not feasible. However, with knowledge of the PCCs' advertised capabilities, the PCE can detect this limitation and instead opt for local re-optimization of the Candidate path. In such cases, the PCE can compute the optimized LSP by 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.¶

4.3.6. Fast Reroute

This document identifies Facility Fast Reroute (FRR) procedures. Only Link Protection procedures are defined. How the Facility Path is computed and instantiated is outside of scope of this document.¶

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

Figure 1: Redundant directly connected interfaces

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

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

Figure 2: Protection through alternative network path

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, including using SR LFA or R-LFA or TI-LFA to protect the direct link between R-T via F1. If no unicast SR is available within the network, the PCE optionally can establish a shared replication point on F1 and F2 and protect all path-instances that are traversing R-T via this shared Replication segment.¶

In addition, Penultimate Hop Popping (PHP) and implicit null label on the bypass path can be implemented to reduce the PCE programming on the merge point (MP) PCC.¶

4.3.7. Connecting Replication Segment via Segment List

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

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

4.3.9. Fragmentation

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

4.4.1. SR P2MP Policy

The format of the PCRpt message is updated as follows:¶

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

Where:

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

 <state-report> ::= [<SRP>]
                     <LSP>
                    [<association-list>]
                    [<end-point-list>]

where:

 <SRP> is defined in RFC8231

 <LSP> is defined in [RFC8231] section 5.5.1

 <association-list> ::=
      <ASSOCIATION> [<association-list>]

 <end-point-list> ::= [<P2MP-END-POINTS>]

Where:

 <ASSOCIATION>
        is described in this doc

 <P2MP-END-POINTS>
        is described in this doc

The format of the PCUpd message is updated as follows:¶

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

Where:

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

 <update-request> ::= <SRP>
                      <LSP>
                     [<end-point-list>]

Where:

 <SRP> is defined in [RFC8231]

 <LSP> is defined in [RFC8231]section 5.5.1

 <end-point-list> ::= [<P2MP-END-POINTS>]

Where:

 <P2MP-END-POINTS> is described in this doc

The format of the PCInitiate message is updated as follows:¶

<PCInitiate Message> ::= <Common Header>
                         <PCE-initiated-lsp-list>

Where:

 <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-instantiation> ::= <SRP>
                                       <LSP>
                                       <association-list>
                                       <end-point-list>
Where:

 <SRP> is defined in RFC8231

 <LSP> is defined in [RFC8231] in section 5.5.1

 <association-list> ::=
             <ASSOCIATION> [<association-list>]

 <end-point-list> ::= [<P2MP-END-POINTS>]

Where:

 <ASSOCIATION> is described in this doc

 <P2MP-END-POINTS> is described in in this doc

4.4.2. Replication Segment

The Replication Segment can be constructed via the following PCRpt, PCUpd and PCInitiate messages¶

NOTE:¶

• Replication segment does not use a association object¶

The format of the PCRpt message is updated as follows:¶

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

Where:

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

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

Where:

 <SRP> is defined in [RFC8231]

 <LSP> is defined in [RFC8231] section 5.5.1

 <CCI> is defined in this doc

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

Where:

 <PATH-ATTRIB-ERO> is defined in [draft-ietf-pce-multipath]

 <ERO> is defined in [RFC8664]

The format of the PCUpd message is updated as follows:¶

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

Where:

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

 <update-request> ::= <SRP>
                      <LSP>
                      <CCI>
                      <intended-path>

Where:

 <SRP> is defined in [RFC8231]

 <LSP> is defined in [RFC8231] section 5.5.1

 <CCI> is defined in this doc

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

Where:

 <PATH-ATTRIB-ERO> is defined in [draft-ietf-pce-multipath]

 <ERO> is defined in [RFC8664]

The format of the PCInitiate message is updated as follows:¶

<PCInitiate Message> ::= <Common Header>
                         <PCE-initiated-lsp-list>

Where:

 <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-instantiation> ::= <SRP>
                                       <LSP>
                                       [<CCI>]
                                       [<intended-path>]
Where:

 <SRP> is defined in RFC8231

 <LSP> is defined in [RFC8231] section 5.5.1

 <CCI> is defined in section 4.4.3.3

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

Where:

 <PATH-ATTRIB-ERO> is defined in [draft-ietf-pce-multipath]

 <ERO> is defined in [RFC8664]

 <PCE-initiated-lsp-deletion> is as per [RFC8281].
 <attribute-list> is as per [RFC8281].

4.4.3. Considerations

A SR P2MP Policy supports add, remove, and full replace of Leaf nodes in a message, described further in section 5.5.2 and with an example in section 8.1. However, a Candidate Path and Replication Segment MUST NOT carry delta information. Every PcRpt, PcInitiate and PCUpd message MUST contain the full list of the Leaf nodes, and Segment forwarding information that is needed to build the Candidate path and its Replication segments. This is necessary to ensure that PCE or any new PCE is in sync with the PCC.¶

5.5.1. P2MP Policy Association Group

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

For PCC-initiated SR P2MP Policy, the ASSOCIATION object is present in the first PCRpt message that is sent by the PCC to PCE to indicate the existence of the SR P2MP Policy and its Candidate path. This first PCRpt message does not have a corresponding PCUpdate message but it does include the Association object accordingly.¶

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

5.5.2. P2MP-END-POINTS Object

In order for the Root node to indicate operations of its Leaf nodes (Add/Remove/Replace-all), the PcRpt and PcInit messages are extended to include P2MP End Point <P2MP End-points> Object which is defined in [RFC8306]¶

The absence of the P2MP-END-POINTS Object means that there is no change in the leaf endpoint of the policy and the PCEP speaker MUST NOT consider the absence of the object as an indication of removal of the endpoints.¶

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 Leaf nodes of a given type. A SR P2MP PcRpt MAY mix different types of Leaf nodes by including several P2MP END-POINTS objects. The END-POINTS object body has a variable length. These are multiples of 4 bytes for IPv4, multiples of 16 bytes, plus 4 bytes, for IPv6.¶

5.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 Policy, 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 MUST 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 PCE. 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).¶

Figure 3 presents an example exchange of SR-P2MP-LSPID-TLV.¶

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

5.7.1. Message format

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 carries the CCI object to identify a P2MP cross connect. The Replication segment is distributed individually to the Root, Transit and Leaf nodes without the P2MP Policy. The replication segment uses SR-P2MP-LSPID-TLV as its identifier. The TLV is coded differently for shared and non-shared case¶

5.7.2. CCI Object

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 can be include in Reports, initiate and Update messages for Replication Segments.¶

This document redefines a new version of the SR-MPLS CCI object-type [draft-ietf-pce-pcep-extension-pce-controller-sr] for P2MP Policy. The label in the CCI Object is the incoming SID. The outgoing SIDs are defined by the ERO Objects.¶

CCI Object-Type is TBD6 for SR 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            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¶

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