idnits 2.17.1 draft-hsd-pce-sr-p2mp-policy-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2020) is 1274 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-spring-segment-routing-policy' is mentioned on line 826, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Bidgoli, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track V. Voyer 5 Expires: May 3, 2021 Bell Canada 6 S. Rajarathinam 7 Nokia 8 E. Hemmati 9 Cisco System 10 T. Saad 11 Juniper Networks 12 S. Sivabalan 13 Ciena 14 October 30, 2020 16 PCEP extensions for p2mp sr policy 17 draft-hsd-pce-sr-p2mp-policy-02 19 Abstract 21 SR P2MP policies are set of policies that enable architecture for 22 P2MP service delivery. This document specifies extensions to the 23 Path Computation Element Communication Protocol (PCEP) that allow a 24 stateful PCE to compute and initiate P2MP paths from a Root to a set 25 of Leaves. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 4 63 3. Overview of PCEP Opration in SR P2MP Network . . . . . . . . 4 64 3.1. High level view of P2MP Policy Objects . . . . . . . . . 5 65 3.1.1. Shared Tree vs Non-Shared Replication Segment . . . . 6 66 3.2. existing drafts used for defining a P2MP Policy . . . . . 7 67 3.2.1. Existing drafts/rfcs used by this draft . . . . . . . 7 68 3.2.2. P2MP Policy Identification . . . . . . . . . . . . . 8 69 3.2.3. Replication Segment Identificaton . . . . . . . . . . 9 70 3.3. High Level Procedures for P2MP SR LSP Instantiation . . . 9 71 3.3.1. PCE-Init Procedure . . . . . . . . . . . . . . . . . 9 72 3.3.2. PCC-Init Procedure . . . . . . . . . . . . . . . . . 10 73 3.3.3. Comon Procedure . . . . . . . . . . . . . . . . . . . 10 74 3.3.4. Global Optimiation of the Candidate Path . . . . . . 12 75 3.3.5. Fast Reroute . . . . . . . . . . . . . . . . . . . . 12 76 3.3.6. Connecting Replication Segment via Segment List . . . 13 77 3.4. SR P2MP Policy and Replication Segment TLVs and Objects . 14 78 3.4.1. SR P2MP Policy Objects . . . . . . . . . . . . . . . 14 79 3.4.2. Replication Segment Objects . . . . . . . . . . . . . 14 80 3.4.3. P2MP Policy vs Replication Segment . . . . . . . . . 15 81 3.4.4. P2MP Policy and Replication Segment general 82 considerations . . . . . . . . . . . . . . . . . . . 15 83 4. Object Format . . . . . . . . . . . . . . . . . . . . . . . . 15 84 4.1. Open Message and Capablity Exchange . . . . . . . . . . . 16 85 4.2. Symbolic Name in PCInit Message from PCC . . . . . . . . 17 86 4.3. P2MP Policy Specific Objects and TLVs . . . . . . . . . . 17 87 4.3.1. P2MP Policy Association Group for P2MP Policy . . . . 17 88 4.3.1.1. P2MP SR Policy Association Group Policy 89 Identifiers TLV . . . . . . . . . . . . . . . . . 17 90 4.3.1.2. P2MP SR Policy Association Group Candidate Path 91 Identifiers TLV . . . . . . . . . . . . . . . . . 18 92 4.3.1.3. P2MP SR Policy Association Group Candidate Path 93 Attributes TLV . . . . . . . . . . . . . . . . . 19 94 4.3.2. P2MP-END-POINTS Object . . . . . . . . . . . . . . . 19 95 4.4. P2MP Policy and Replication Segment Identifier Object and 96 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 4.4.1. Extension of the LSP Object, SR-P2MP-LSPID-TLV . . . 21 99 4.5. Replication Segment . . . . . . . . . . . . . . . . . . . 22 100 4.5.1. The format of the replication segment message . . . . 23 101 4.5.2. Label action rules in replicating segment . . . . . . 23 102 4.5.3. SR-ERO Rules . . . . . . . . . . . . . . . . . . . . 24 103 4.5.3.1. SR-ERO subobject changes . . . . . . . . . . . . 24 104 5. Examples of PCEP messages between PCE and PCEP . . . . . . . 25 105 5.1. PCE Initiate . . . . . . . . . . . . . . . . . . . . . . 25 106 5.2. PCC Initiate or PCE Initiate Respond . . . . . . . . . . 27 107 5.3. PCE P2MP Path-Instance Calculation and Replication 108 Segment download . . . . . . . . . . . . . . . . . . . . 28 109 5.4. PCC Rpt for PCE Update and Init Messages . . . . . . . . 36 110 6. Tree Deletion . . . . . . . . . . . . . . . . . . . . . . . . 37 111 7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 38 112 8. Example Workflows . . . . . . . . . . . . . . . . . . . . . . 38 113 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 38 114 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 115 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 117 12.1. Normative References . . . . . . . . . . . . . . . . . . 38 118 12.2. Informative References . . . . . . . . . . . . . . . . . 39 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 121 1. Introduction 123 The draft [draft-ietf-pim-sr-p2mp-policy] defines a variant of the SR 124 Policy [draft-ietf-spring-segment-routing-policy] for constructing a 125 P2MP segment to support multicast service delivery. 127 A Point-to-Multipoint (P2MP) Policy connects a Root node to a set of 128 Leaf nodes, optionally through a set of intermediate replication 129 nodes. We also define a Replication segment 130 [draft-ietf-spring-sr-replication-segment], which corresponds to the 131 state of a P2MP segment on a particular node, as an example the 132 forwarding instructions for the replication SID. 134 A P2MP Policy is relevant on the root of the P2MP Tree and it 135 contains candidate paths. The candidate paths are made of path- 136 instances and each path-instance is constructed via replication 137 segments. These replication segments are programmed on the root, 138 leaves and optionally intermediate replication nodes. 140 It should be noted that two replication segments can be connected 141 directly, or they can be connected or steered via unicast SR segment 142 or a segment list. 144 For a P2MP Tree, a controller may be used to compute paths from a 145 Root node to a set of Leaf nodes, optionally via a set of replication 146 nodes. A packet is replicated at the root node and optionally on 147 Replication nodes towards each Leaf node. 149 We define two types of a P2MP Tree: Spray and Replication. 151 A Point-to-Multipoint service delivery could be via Ingress 152 Replication (aka Spray in some SR context), i.e., the root unicast 153 individual copies of traffic to each leaf. The corresponding P2MP 154 Policy consists of replication segments only for the root and the 155 leaves and they are connected via a unicast SR Segment. 157 A Point-to-Multipoint service delivery could also be via Downstream 158 Replication (aka TreeSID in some SR context), i.e., the root and some 159 downstream replication nodes replicate the traffic along the way as 160 it traverses closer to the leaves. 162 The leaves and the root can be explicitly configured on the PCE or 163 PCC can update the PCE with the information of the discovered root 164 and leaves. As an example Multicast protocols like mvpn procedures 165 [RFC6513] or pim can be used to discovery the leaves and roots on the 166 PCC and update the PCE with these relevant information. The 167 controller can calculate the P2MP Policy based on these info. 169 In all of above cases a set of new PCEP object and TLVs are needed to 170 update and instantiate the P2MP tree. This draft explains the 171 procedure needed to instantiate a P2MP TreeSID. 173 2. Conventions used in this document 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 3. Overview of PCEP Opration in SR P2MP Network 181 After discovering the root and the leaves on the PCE (via different 182 mechanism mentioned in previous sections) computes the P2MP Tree and 183 identifying the relevant Replication routers, the PCE programs the 184 PCCs with relevant information needed to create a P2MP Tree. 186 As per draft [draft-ietf-pim-sr-p2mp-policy] a P2MP Policy is defined 187 by Root-ID, Tree-ID and a set of leaves. A P2MP policy is a variant 188 of SR policy as such it uses the same concept as draft 189 [draft-ietf-pce-segment-routing-policy-cp]. In short a P2MP policy 190 uses a collection of SR P2MP Candidate paths. Candidate paths are 191 computed by the PCE and can be used for P2MP Tree redundancy, only a 192 single candidate path is active at each time. Each candidate paths 193 can be globally optimized and is consists of multiple path-instances. 195 A path-instance can be thought of as a P2MP LSP. If a candidate path 196 needs to be globally optimized two path-instances can be programmed 197 on the root node and via make before procedures the candidate path 198 can be switched from path-instance 1 to the 2nd path-instance. The 199 forwarding states of these path-instances are build via replication 200 segments, in short each path-instance initiated on the root has its 201 own set of replication segments on the Root, Transit and Leaf nodes. 203 A replication segment is set of forwarding instructions on a specific 204 node. As an example the push information on the Root node or swap 205 and outgoing interface information on the transit nodes or pop 206 information on the bud and leaves nodes. 208 PCE could also calculate and download additional information for the 209 replication segments, such as protections next-hops for link 210 protection (FRR). 212 3.1. High level view of P2MP Policy Objects 214 o SR P2MP Policy 216 * Is only relevant on the Root of the P2MP path and is a policy 217 on PCE which contains information about: 219 + Root node of the P2MP Segment 221 + Leaf nodes of the P2MP Segment 223 + Tree-ID, which is a unique identifier of the P2MP tree on 224 the Root 226 + It also contains a set of Candidate paths and their path- 227 instances for P2MP tree redundancy and global optimization 229 + Optional Constrains used to build these candidate paths 231 + P2MP policy information is downloaded only on the Root node 232 and is identified via 234 o Candidate Path: 236 * Is used for P2MP Tree redundancy where the candidate path with 237 the highest preference is the active path. 239 * It can contain up to two path-instance for global optimization 240 procedures (i.e. make before break), each identified with their 241 own path-instance ID 243 * Contains information about protocol-id, originator, 244 discriminator, preference, path-instances 246 o Replication Segment: 248 * Is the forwarding information needed on each node for building 249 the forwarding path for each path-instance of the P2MP 250 Candidate path. 252 * As it will be explained in upcoming sections there are 2 ways 253 to identify the replication segment, shared and non-shared 255 + It is identified via Tree-ID and Root-ID and path-instance 256 for non-shared replication segment. 258 + It is identified via Node-ID, Replication-ID, for shared 259 replication segment 261 + Contains forwarding instructions for the path-instances 263 + On the forwarding plane the Replication Segment is 264 identified via the incoming Replication SID. 266 + Replication segment information is downloaded on Root, 267 Transit and Leaf nodes respectively. 269 3.1.1. Shared Tree vs Non-Shared Replication Segment 271 A non-shared Replication Segment is used when the label field of the 272 PMSI Tunnel Attribute (PTA) is set to zero as per 273 [draft-parekh-bess-mvpn-sr-p2mp]. In short this is used when there 274 is no upstream assigned label in the PTA (provider tunnel attribute) 275 and aggregate of MVPNs into a single P-Tunnel is not desired. 277 On other hand shared Replication Segment is used when the label field 278 of the PTA is not set to Zero and there is an upstream assigned label 279 in the PTA. In this case multiple MVPNs (VRFs) can be aggregate into 280 a single Provider Tunnel and the upstream assigned label 281 distinguishes the MVPNs context. 283 It should be noted that the shared Replication Segment can also be 284 used to build a bypass tunnel for the purpose of FRR. This might be 285 desirable if the bypass tunnel is build via the PCE and downloaded to 286 the PCC for link protection. In this case multiple non-shared 287 Replication Segments can use the shared replication segment as their 288 bypass tunnel for link protection. This replication segments used in 289 this bypass tunnel should only create a unicast bypass tunnel to 290 protect the link between two replication segments on the primary 291 path. 293 3.2. existing drafts used for defining a P2MP Policy 295 P2MP Policy reuses current drafts and PCEP objects to update the PCE 296 with Root and Leaves information when PCC Initiated method is used. 297 Also current drafts are used as much as possible to update the PCC 298 with relevant information to build the P2MP Policy and its 299 Replication Segments. 301 In addition this draft will introduced new TLVs and Objects specific 302 to a programing P2MP policy and its replication segment. 304 3.2.1. Existing drafts/rfcs used by this draft 306 o [RFC8231] The bases for a stateful PCE, and reuses the following 307 objects or a variant of them 309 * 311 * 313 * A variation of the LSP identifier TLV is defined in this draft, 314 to support P2MP LSP Identifier 316 o [RFC8236] P2MP capabilities advertisement 318 o [draft-ietf-pce-segment-routing-policy-cp] Candidate paths for 319 P2MP Policy is used for Tree Redundancy. As an example a P2MP 320 Policy can have multiple candidate paths. Each protecting the 321 primary candidate path. The active path is chosen via the 322 preference of the candidate path. 324 o [RFC3209] Defines the instance-ID, instance-ID is used for global 325 optimization of a candidate path with in a P2MP policy. Each 326 Candidate path can have 2 path-instances. These path-instances 327 are equivalent to sub-lsps (instance-IDs). There are used for MBB 328 and global optimization procedures. instance-ID is equivalent to 329 LSP ID 331 o [draft-ietf-spring-segment-routing-policy] Segment-list, used for 332 connecting two non-adjacent replication policy via a unicast 333 binding SID or Segment-list. 335 o [RFC8306] P2MP End Point objects, used for the PCC to update the 336 PCE with discovered Leaves. 338 o [draft-sivabalan-pce-binding-label-sid] Section 3; Path binding 339 TLV is used to indicate the incoming replication SID 341 o [draft-koldychev-pce-multipath] Forwarding instruction for a P2MP 342 LSP is defined by a set of SR-ERO sub-objects in the ERO object, 343 ERO-ATTRIBUTES object and MULTIPATH-BACKUP TLV as defined in this 344 draft. 346 o [RFC8664] SR-ERO Sub Object used in the multipath. 348 It should be noted that the [draft-dhs-spring-sr-p2mp-policy-yang] 349 can provide further details of the high level P2MP Policy Model. 351 3.2.2. P2MP Policy Identification 353 A P2MP Policy and its candidate path can be identified on the root 354 via the P2MP LSP Object. This Object is a variation of the LSP ID 355 Object defined in [RFC8231] and is as follow: 357 o PLSP-ID: [RFC8231], is assigned by PCC and is unique per candidate 358 path. It is constant for the lifetime of a PCEP session. Stand- 359 by candidate paths will be assigned a new PLSP-ID by PCC. Stand- 360 by candidate paths can co-exist with the active candidate path. 362 * Note: Every candidate path in the SR-P2MP Policy is unique with 363 its own unique PLSP-ID and Instance-ID. But the same Tree-ID 364 is used for all candidate paths as they are part of the same 365 P2MP Tree. 367 o Root-ID: is equivalent to the first node on the P2MP path, as per 368 [RFC3209], Section 4.6.2.1 370 o Tree-ID: is equivalent to Tunnel Identifier color which identifies 371 a unique P2MP Policy at a ROOT and is advertised via the PTA in 372 the BGP AD route or can be assigned manually on the root. Tree-ID 373 needs to be unique on the root. 375 o Instance-ID: LSP ID Identifier as defined in RFC 3209, is the 376 path-instance identifier and is assigned by the PCC. As it was 377 mentioned the candidate path can have up to two path-instance for 378 global optimization. Note that the Root-ID, Tree-ID and Instance- 379 ID are part of a new SR- P2MP-LSP-IDENTIFIER TLV which will be 380 identified in this draft. 382 * Note: each Path-instance on the Root node is assigned a unique 383 Instance-ID 385 3.2.3. Replication Segment Identificaton 387 The key to identify a replication segment is also a P2MP LSP Object. 388 That said there are different rules for coding the SR-P2MP-LSP- 389 IDENTIFIER TLV which will be explained in later sections. In short 390 for replication segment the P2MP LSP Object does not have the 391 association object. 393 3.3. High Level Procedures for P2MP SR LSP Instantiation 395 A P2MP policy can be instantiated via the PCC or the PCE depending on 396 how the root and the leaves are discovered. In theory there is two 397 way to discover the root and the leaves: 399 o They can be configured and identified on the controller, PCE 400 initiated. 402 o They can be discovered on the PCC via MVPN procedures [RFC6513] or 403 legacy multicast protocols like PIM or IGMP etc... PCC initiated. 405 3.3.1. PCE-Init Procedure 407 o PCE is informed of the P2MP request through it's API or 408 configuration mechanism to instantiate a P2MP tunnel. 410 o PCE will initiate the P2MP Policy for the request, by sending a 411 PCInitiate message to the Root. This PCInitiation message will 412 have the association object to identify the Candidate Path 414 * Optionally the EROs can be added to the PCInitiate message to 415 construct the replication segment on the root. 417 o Root in response to the PCInitiate message. It will generate 418 PLSP-ID for the candidate paths and an Instance-ID for the Path- 419 Instance (LSP-ID) contained with in a candidate path. The tree-id 420 for the P2MP Policy is also filled. PCC will reports back the 421 PLSP-ID, Instance-ID and tree-id via PCRpt message 423 * Optionally, the Root can add any additional leaves that were 424 discovered by multicast procedures in this PCRpt message. 426 o PCE based on any update to the configured leaves or if any new 427 discovered leaves, can re-compute the P2MP Policy and its 428 replication segments from the Root to the leaves. 430 * Any new EROs are send via PCInitiate message, without the 431 association object 433 * Any update to the existing EROs are send via PCUpd message, 434 without the association object 436 o PCE will also sends a PCInitiate message to the Transit and the 437 leaves for the Replication Segment. 439 3.3.2. PCC-Init Procedure 441 After Root (PCC) discovers the leaves (as an example via MVPN 442 Procedures or other mechanism), the following communication happens 443 between the PCE and PCCs 445 o Root sends a PCRpt message for P2MP policy to PCE including the 446 Root-ID, Tree-ID, PLSP-ID, Instance-ID, symbolic-path-name, and 447 any leaves discovered until then. 449 o PCE on receiving of this report, will compute the P2MP Policy and 450 its replication segments. 452 * The PCE will send a PCUpd message to Root for P2MP policy with 453 the Tree-ID, PLSP-ID and the Instance-ID assigned by the PCC. 454 It should be noted the replication segment for root is also 455 downloaded via this update message. In short a single update 456 message that includes the association object will create the 457 P2MP Policy and its replication segment on the Root 459 + Note: in this scenario no PCInitiate message was send from 460 the PCE to the PCC to instantiate the P2MP Policy and its 461 Replication segment. This is because for an PCInitiate 462 message a brand new PLSP-ID and Instance-ID is assigned by 463 PCC which is undesirable, since they are already assigned on 464 the first step of this procedure. 466 * PCE will also sends a PCInitiate message to the Transit and the 467 leaves for the Replication Segment. 469 3.3.3. Comon Procedure 471 Beyond this, the following procedures are the same for PCE or PCC 472 Init. 474 o PCE will download the replication segments for the Candidate- 475 path's path-instances to all the leaves and transit nodes using 476 PCInitiate message with PLSP-ID = 0, Instance-ID =0, symbolic path 477 name, Root-address, Tree-id(assigned by the root). This 478 PCInitiate message includes the EROs needed for the replication 479 segments. 481 o Any new candidate path for the P2MP Policy is downloaded by PCE to 482 its connected Root by sending a PCInitiate message 484 * it should be noted, PLSP-ID, Path-Instance ID and the Tree-ID 485 are generated by the PCC for these new candidate paths and 486 their Path-instances 488 * The ERO objects can be included in this Initiate message 490 * The PCC will reply with a PCRpt message 492 * Any update to the Candidate Paths or Replication Segments is 493 done via the PCUpd message. Association object need to be 494 present for Candidate Path updates. 496 o The PCE will also download the necessary replication segment for 497 the candidate path and its path-instances to the leaves and the 498 transit nodes via a PCInit message 500 o New leaves can be discovered via Multicast procedures, and new 501 replication segments can be instantiated or existing one updated 502 to reach these leaves 504 * If these leaves reside on routers that are part of the P2MP LSP 505 path, then PCUpd is sent from PCE to necessary PCCs (LEAVES, 506 TRANSIT or ROOT) with the correct PLSP-ID, Instance-ID and 507 Tree-ID 509 * If the new leaves are residing on routers that are not part of 510 the P2MP Tree yet, then a PCInitiate message is sent down with 511 PLSP- ID=0 and Instance-ID=0 on the corresponding routers. 513 o The active candidate-path is indicated by the PCC through the 514 operational bits(Up/Active) of the LSP object in the PCRpt 515 message. If a candidate path needs to be removed, PCE sends PC 516 Initiate message, setting the R-flag in the LSP object and R bit 517 in the SRP-object. 519 o To remove the entire P2MP-LSP, PCE needs to send PC Initiate 520 remove messages for every candidate path of the P2MP POLICY to all 521 the PCCs on the P2MP Tree. The R bit in the LSP Object as defined 522 in [RFC8231], refers to the removal of the LSP as identified by 523 the SR-P2MP-POLICY-ID-TLV (defined in this document). An all zero 524 (SR-P2MP-LSP-ID-TLV defines to remove all the state of the 525 corresponding PLSP-ID. 527 o A candidate path is made active based on the preference of the 528 path. If the Root is programed with multiple candidate paths from 529 different sources, as an example PCE and CLI, based on its tie- 530 breaking rules, if it selects the CLI path, it will send a report 531 to PCE for the PCE path indicating the status of label-download 532 and sets operational bit of the LSP object to UP and Not Active . 533 At any instance, only one path will be active 535 3.3.4. Global Optimiation of the Candidate Path 537 When a P2MP LSP needs to be optimized for any reason (i.e. it is 538 taking a FRR tunnel or new routers are added to the network) a global 539 optimization of the candidate path is possible. 541 Each Candidate Path can contain two Path-Instances. The current 542 unoptimized Path-Instance is the active instance and its replication 543 segments are forwarding the multicast PDUs from the root to the 544 leaves. How ever the second optimized Path-Instance will be setup 545 with its own unique replication segments throughout the network, from 546 the Root to the leaves. These two Path-Instances can co-exist. The 547 two Path-Instances are uniquely identified by their Instance-ID in 548 the SR-P2MP-POLICY-ID-TLV (defined in this document). After the 549 optimized LSP has been downloaded successfully PCC MUST send two 550 reports, reporting UP of the new path indicating the new LSP-ID, and 551 a second reporting the tear down of the old path with the R bit of 552 the LSP Object SET with the old Instance-ID in the SR-P2MP-POLICY-ID- 553 TLV. This MBB procedure will move the multicast PDUs to the 554 optimized Path-Instance. 556 The leaf should be able to accept traffic from both Path-Instances to 557 minimize the traffic outage by the Make Before Break process. 559 3.3.5. Fast Reroute 561 Currently this draft identifies the Facility FRR procedures. In 562 addition, only LINK Protection procedures are defined. How the 563 Facility Path is built and instantiated is beyond the scope of this 564 document. 566 R 567 | | 568 T 569 | 570 --- 571 | | 572 L1 L2 574 Figure 1 576 R---F1 577 | | 578 T---F2 579 | 580 --- 581 | | 582 L1 L2 584 Figure 2 586 As an example, the bypass path (unicast bypass) between the PLR and 587 MP can be constructed via SR or even via a shared tree (replication 588 segment). 590 As an example, in figure 1 the detour path between R and T is the 2nd 591 fiber between these nodes. As such the bypass path could be setup on 592 the 2nd fiber. That said in figure 2 the bypass path is traversing 593 multiple nodes and this example a unicast SR path might be ideal for 594 setting up the detour path. 596 In addition, PHP procedure and implicit null label on the bypass path 597 can be implemented to reduce the PCE programming on the MP PCC. 599 Optional shared replication segments can be used in networks that do 600 not have unicast SR turned on. These shared replication segments can 601 be programmed on the bypass nodes without a P2MP Policy. The 602 replication segments on primary path can use these shared replication 603 segments as a protection tunnel to protect links. 605 3.3.6. Connecting Replication Segment via Segment List 607 There could be nodes between two replication segment that do not 608 understand P2MP Policy or Replication segment. It is possible to 609 connect two non-adjacent Replication segment via a unicast binding 610 SID or segment-list. 612 Replication segment does support the concept of a segment-list. A 613 list of unicast SIDs (Binding SID, Adjacency SIDs or Node SIDs) can 614 be programmed on a Replication segment via the SR-ERO sub-objects and 615 ERO-attributes object. 617 How ever it should be noted that there needs to be a Replication SID 618 as the bottom of the stack in all cases. 620 3.4. SR P2MP Policy and Replication Segment TLVs and Objects 622 3.4.1. SR P2MP Policy Objects 624 SR P2MP Policy can be constructed via the following objects 626 628 [] 630 632 [] 634 optionally if the root is updating the PCE with end point list the 635 end-point-list object can be added. 637 [] 639 3.4.2. Replication Segment Objects 641 Replication segment can be constructed via the following objects 643 645 [] 647 649 [] 651 as described in [draft-sivabalan-pce-binding-label-sid] 653 [] 655 as per [draft-koldychev-pce-multipath] 657 3.4.3. P2MP Policy vs Replication Segment 659 Note on the root the P2MP Policy and Replication Segment can be 660 downloaded via the same message that includes the association object. 661 That said on the transit or leaf nodes the replication segment needs 662 to be downloaded individually as P2MP Policy is only relevant to the 663 Root node. P2MP Policy and Replication segments objects have a very 664 close definition, they can be told apart via the following abstracts: 666 o The P2MP Policy will always have an association list object for 667 the Candidate Paths in its PCInitiate message. While the 668 replication segment does not have the association list object. 669 That said they can be downloaded simultaneously by inserting the 670 association list object and the ERO object in the same PCInitiate 671 or PCUdp message. 673 o Both P2MP Policy and Replication segment have the PLSP-ID and it 674 is set to 0 in the PCInitiate message. For both Objects the PLSP- 675 ID is set via the PCC. 677 3.4.4. P2MP Policy and Replication Segment general considerations 679 The above new objects and TLV's defined in this document can be 680 included in PCRpt, PcInitiate and PcUpd messages. 682 It should be noted that every PcRpt, PcInitiate and PCUpd messages 683 will contain full list of the Leaves and labels and forwarding 684 information that is needed to build the Candidate path and its 685 Replication segments. They will never send the delta information 686 related to the new leaves or forwarding information that need to be 687 added or updated. This is necessary to ensure that PCE or any new 688 PCE is in sync with the PCC. 690 As such when a PcRpt, PcInitiate and PCUpd messages is send via PCEP 691 it maintains the previous ERO Path IDs and generates new Path IDs for 692 new instructions, as per [draft-koldychev-pce-multipath]. This means 693 the PATH IDs are maintained for each specific forwarding instructions 694 until these instructions are deleted. For example: When the first 695 leaf is added the PCE will be update with PathI ID 1 to the PCC. 696 When the second leaf is add, according to the path calculated, PCE 697 might just append the existing instruction Path ID 1 with a new Path 698 ID 2 to construct the new PCUpd message. 700 4. Object Format 701 4.1. Open Message and Capablity Exchange 703 Format of the open Object: 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Ver | Flags | Keepalive | DeadTimer | SID | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | | 710 // Optional TLVs // 711 | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 All the nodes need to establish a PCEP connection with the PCE. 716 During PCEP Initialization Phase, PCEP Speakers need to set flags N, 717 M, P in the STATEFUL-PCE-CAPABILITY TLV as defined in 718 [draft-ietf-pce-stateful-pce-p2mp] section-5.2 720 This draft extends the PCEP OPEN object by defining an optional TLV 721 to indicate the PCE's capability to perform SR-P2MP path computations 722 with a new IANA capability type. 724 The inclusion of this TLV in an OPEN object indicates that the sender 725 can perform SR-P2MP path computations. This will be similar to the 726 P2MP-CAPABILITY defined in [RFC8306] section-3.1.2 and a new value 727 needs to be defined for SR-P2MP. 729 In addition a Assoc-Type-List TlV as per [RFC8697] section 3.4 should 730 be send via PCEP open object with following association type 732 +-------------------+----------------------------+------------------+ 733 | Association Type | Association Name | Reference | 734 | Value | | | 735 +-------------------+----------------------------+------------------+ 736 | TBD1 | P2MP SR Policy Association | This document | 737 +-------------------+----------------------------+------------------+ 739 OP-CONF-Assoc-RANGE (Operator-configured Association Range)should not 740 be set for this association type and must be ignored. 742 Finally the open message needs to include the MULTIPATH CAPABILITY 743 TLV as defined in [draft-koldychev-pce-multipath] 745 4.2. Symbolic Name in PCInit Message from PCC 747 As per [RFC8231] section 7.3.2. a Symbolic Path Name TLV should 748 uniquely identify the P2MP path on the PCC. This symbolic path name 749 is a human-readable string that identifies an P2MP LSP in the 750 network. It needs to be constant through the life time of the P2MP 751 path. 753 As an example in the case of P2MP LSP the symbolic name can be p2mp 754 policy name + candidate path name of the LSP. 756 4.3. P2MP Policy Specific Objects and TLVs 758 4.3.1. P2MP Policy Association Group for P2MP Policy 760 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 761 [RFC8697]. The ASSOCIATION object includes "Association type" 762 indicating the type of the association group. This document adds a 763 new Association type. Association type = TBD1 "P2MP SR Policy 764 Association Type" for SR Policy Association Group (P2MP SRPAG). As 765 per [draft-barth-pce-segment-routing-policy-cp] section 5, three new 766 TLVs are identified to carry association information: P2MP-SRPAG- 767 POL-ID-TLV, P2MP-SRPAG-CPATH-ID-TLV, P2MP-SRPAG-CPATH-ATTR-TLV 769 4.3.1.1. P2MP SR Policy Association Group Policy Identifiers TLV 771 The P2MP-SRPOLICY-POL-ID TLV is a mandatory TLV for the P2MP-SRPAG 772 Association. Only one P2MP-SRPOLICY-POL-ID TLV can be carried and 773 only the first occurrence is processed and any others MUST be 774 ignored. 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Type | Length | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Root | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | TREE-ID | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Type: TBD2 for "P2MP-SRPOLICY-POL-ID" TLV. 788 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 790 Tunnel Sender Address : Can be either IPv4 or IPv6, this value is the 791 value of the root loopback IP. 793 Tree-ID: Tree ID that the replication segment is part of as per 794 draft-ietf-spring-sr-p2mp-policy 796 4.3.1.2. P2MP SR Policy Association Group Candidate Path Identifiers 797 TLV 799 The P2MP-SRPOLICY-CPATH-ID TLV is a mandatory TLV for the P2MPSRPAG 800 Association. Only one P2MP-SRPOLICY-CPATH-ID TLV can be carried and 801 only the first occurrence is processed and any others MUST be 802 ignored. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Length | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Proto. Origin |Flags |A| Reserved | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Originator ASN | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | | 814 | Originator Address | 815 | | 816 | | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Discriminator | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Type: TBD3 for "P2MP-SRPOLICY-CPATH-ID" TLV. 823 Length: 28. 825 Protocol Origin: 8-bit value that encodes the protocol origin, as 826 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 828 Flags : A: This candidate path is active. At any instance only one 829 candidate path can be active. PCC indicates the active candidate 830 path to PCE through this bit. Reserved: MUST be set to zero on 831 transmission and ignored on receipt. 833 Originator ASN: Represented as 4 byte number, part of the originator 834 identifier, as specified in 835 [draft-ietf-spring-segment-routing-policy] Section 2.4. 837 Originator Address: Represented as 128 bit value where IPv4 address 838 are encoded in lowest 32 bits, part of the originator identifier, as 839 specified in [draft-ietf-spring-segment-routing-policy] Section 2.4. 841 Discriminator: 32-bit value that encodes the Discriminator of the 842 candidate path. 844 4.3.1.3. P2MP SR Policy Association Group Candidate Path Attributes TLV 846 The P2MP-SRPOLICY-CPATH-ATTR TLV is an optional TLV for the SRPAG 847 Association. Only one P2MP-SRPOLICY-CPATH-ATTR TLV can be carried 848 and only the first occurrence is processed and any others MUST be 849 ignored. 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Type | Length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Preference | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 Type: TBD4 for "P2MP-SRPOLICY-CPATH-ATTR" TLV. 861 Length: 4. Preference: Numerical preference of the candidate path, 862 as specified in [draft-ietf-spring-segment-routing-policy] 863 Section 2.7. 865 If the TLV is missing, a default preference of 100 as specified in 866 [draft-ietf-spring-segment-routing-policy] is used. 868 4.3.2. P2MP-END-POINTS Object 870 In order for the Root to indicate operations of its 871 leaves(Add/Remove/Modify/DoNotModify), the PC Report message is 872 extended to include P2MP End Point Object which is 873 defined in [RFC8306] 875 The format of the PC Report message is as follow: 877 879 [] 881 883 [] 885 [] 886 IPV4-P2MP END-POINTS: 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Leaf type | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Source IPv4 address | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Destination IPv4 address | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 ~ ... ~ 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Destination IPv4 address | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 IPV6-P2MP END-POINTS: 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Leaf type | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | | 908 | Source IPv6 address (16 bytes) | 909 | | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | | 912 | Destination IPv6 address (16 bytes) | 913 | | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 ~ ... ~ 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | | 918 | Destination IPv6 address (16 bytes) | 919 | | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Leaf Types (derived from [RFC8306] section 3.3.2) : 924 1. New leaves to add (leaf type = 1) 926 2. Old leaves to remove (leaf type = 2) 928 3. Old leaves whose path can be modified/reoptimized (leaf type = 929 3), Future reserved not used for tree SID as of now. 931 4. Old leaves whose path must be left unchanged (leaf type = 4) 932 A given P2MP END-POINTS object gathers the leaves of a given type. 933 Note that a P2MP report can mix the different types of leaves by 934 including several P2MP END-POINTS objects. The END-POINTS object 935 body has a variable length. These are multiples of 4 bytes for IPv4, 936 multiples of 16 bytes, plus 4 bytes, for IPv6. 938 4.4. P2MP Policy and Replication Segment Identifier Object and TLV 940 As it was mentioned previously both P2MP Policy and Replication 941 Segment are identified via the LSP object and more precisely via the 942 SR-P2MP-LSPID-TLV 944 The P2MP Policy uses the PLSP-ID to identify the Candidate Paths and 945 the Instance-ID to identify a Path-Instance with in the Candidate 946 path. 948 On other hand the Replication Segment uses the SR-P2MP-LSPID-TLV to 949 identify and correlate a Replication Segment to a P2MP Policy 951 As it was noted previously on the Root, the P2MP Policy and the 952 Replication Segment is downloaded via the same PCUpd message. 954 4.4.1. Extension of the LSP Object, SR-P2MP-LSPID-TLV 956 The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 957 the PLSP-ID to uniquely identify an LSP that is constant for the life 958 time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID 959 identify a Candidate Path uniquely with in the P2MP policy. 961 The LSP Object MUST include the new SR-P2MP-POLICY-ID-TLV (IPV4/IpV6) 962 defined in this document below. This is a variation to the P2MP 963 object defined in [draft-ietf-pce-stateful-pce-p2mp] 965 SR-IPV4-P2MP-POLICY-ID TLV: 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Type=TBD | Length=10 | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Root | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Tree-ID | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Path-Instance-ID | Reserved | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 SR-IPV6-P2MP-POLICY-ID TLV : 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Type=TBD | Length=22 | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 + + 986 | Root | 987 + (16 octets) + 988 | | 989 + + 990 | | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Tree-ID | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Path-Instance-ID | Reserved | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 The type (16-bit) of the TLV is TBD (need allocation by IANA). 999 Root: Source Router IP Address 1001 Tree-ID: Unique Identifier of this P2MP LSP on the Root. 1003 Instance-ID : Contains 16 Bit instance ID. 1005 4.5. Replication Segment 1007 As per [draft-ietf-spring-sr-replication-segment] a replication 1008 segment has a next-hop-group which MAY contain a single outgoing 1009 replication sid OR a list of SIDs (sr-policy-sid-list) In either case 1010 there needs to be a replication SID at the bottom of the stack. This 1011 means two replication segments can be directly connected or connected 1012 via a SR domain. 1014 4.5.1. The format of the replication segment message 1016 As it was mentioned in previous chapters the format of the 1017 replication segment message is close to P2MP Policy. That said the 1018 P2MP Policy contains the association object and the replication 1019 segment message does not contain the association object. The 1020 replication segment may be downloaded individually on transit and 1021 leaf nodes without the P2MP Policy. The P2MP Policy is a Root 1022 Concept. The replication segment uses SR-P2MP-LSPID-TLV as its 1023 identifier. That said this TLV is coded differently for shared and 1024 on shared case. 1026 o In the case of a replication segment being shared, the Tree-ID in 1027 the SR-P2MP-POLICY Identifier TLV is the replication-id of the 1028 replication segment and Root = 0, Instance-Id = 0. When 1029 downloading a shared replication segment from PCE through a 1030 PcInitiate message, the SR-P2MP-POLICY Identifier TLV is all 0, 1031 and on the report back from PCC, PCC generates PLSP-ID, 1032 Replication-id (Tree-id field will be populated with replication- 1033 id). Instance-id will be 0. 1035 4.5.2. Label action rules in replicating segment 1037 The node action, ingress, transit, leaf or Bud, is indicated via a 1038 new Node Role TLV. This document introduces a new SR-P2MP-NODE-ROLE 1039 TLV (Type To be assigned by IANA) that will be present in the PATH- 1040 ATTRIB object. 1042 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 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Type=TBD | Length=4 | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Role Type | Reserved | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 o ingress, role type = 1 1051 o transit, role type = 2 1053 o leaf, role type = 3 1055 o bud, role type = 4 1057 4.5.3. SR-ERO Rules 1059 Forwarding information of a replication segment can be configured and 1060 steered via many different mechanisms. 1062 As an example a replication SID can be steered via: 1064 1. Replication SID steered with an IPv4/IPv6 directly connected 1065 nexthop 1067 * In this case there will two SR-ERO in the ERO Object, with the 1068 Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO 1069 on the top. 1071 2. Replication SID steered with an IPv4/IPv6 loopback address that 1072 reside on the directly connected router. 1074 * In this case there will two SR-ERO in the ERO Object, with the 1075 Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO 1076 on the top. 1078 * In addition a new flag D is added to the SR-ERO to signal that 1079 the Loopback nexthop is connected to the directly attached 1080 router. 1082 3. Replication SID steered with unnumbered IPv4/IPv6 directly 1083 connected Interface 1085 4. Replication SID steered via a SR adjacency or node SID 1087 * In this case even a sid-list can be used to traffic engineer 1088 the path between two Replication SID 1090 * The Replication SID SR-ERO is at the bottom while all other 1091 SR-EROs are on the top in order. 1093 4.5.3.1. SR-ERO subobject changes 1095 SR-ERO from RFC 8664 is used to construct the forwarding information 1096 needed for Replication Segment. 1098 A new D flag was added to indicate a loopback nexthop that is 1099 residing on the directly attached router. It should be noted that 1100 this flag should be set only for the loopback case and not for a 1101 local interface as a nexthop. 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 |L| Type=36 | Length | NT | Flags |D|F|S|C|M| 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | SID (optional) | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 // NAI (variable, optional) // 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Flags : F, S, C, M are already defined in rfc8664. 1115 This document defines a new flag D: If the next-hop in NAI field is 1116 system IP or loopback, this bit indicates whether the system IP / 1117 loopback is directly connected router or not. If set indicates 1118 directly connected address. When this bit is set, F bit should be 0 1119 (meaning NAI should be present) 1121 5. Examples of PCEP messages between PCE and PCEP 1123 +-------+ 1124 | | 1125 +-------+ |LEAF D | +-------+ 1126 |Rep | | | | PCE | 1127 |Transit| +-------+ +-------+ 1128 +------|C | 1129 | Non | | +-------+ 1130 | Rep +-------+ | | 1131 | Transit| |LEAF E | 1132 +------| B | | | 1133 |Rep +--------+ +-------+ 1134 |ROOT | 1135 |A | 1136 +--------+ 1138 5.1. PCE Initiate 1140 For a PCE Initiate P2MP Policy a sample PC Initiate message from the 1141 PCE to the root is provided below. This is on reception of a P2MP 1142 Policy creation on the PCE: 1144 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 1145 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Flags = 0 | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | SRP-ID-number = 1 | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | | PST = TBD | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Type=17 | Length= | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | symbolic path name | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Type=TBD | Length | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | Root = A | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Tree-ID = 0 | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Instance-id = 0 | Reserved | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Reserved | Flags |0| 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Association type= SR-P2MP-PAG | Association ID = z | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | IPv4 Association Source = | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Type | Length | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Root = A | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | TREE-ID = 0 | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Type | Length | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 |ProtOrigin 10 | Reserved | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Originator ASN | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | | 1194 | Originator Address = | 1195 | | 1196 | | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Discriminator = 1 | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Type | Length | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Preference = 100 | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 Presence of an association object with Tree-ID = 0 in the Initiate 1206 message, is an indication to the node to create a P2MP policy and 1207 associated candidate path. An initiate message without an 1208 association object, is an indication to PCC that a Replication 1209 Segment (forwarding instructions) is being instantiated. 1211 5.2. PCC Initiate or PCE Initiate Respond 1213 For PCC initiated P2MP Policy, the Root will send a P2MP request to 1214 the PCE, this is achieved through Root sending a PCRpt to PCE with 1215 the Tree-ID, PLSP-ID and Instance-ID Set. Below is a sample Report 1216 generated by the Root (PCC) to the PCE 1218 In addition for the PCE Initiated case the same PCRpt message can be 1219 send from Root (PCC) to the PCE. The Root will generate the Tree-ID, 1220 PLSP-ID, Instance-ID for the candidate path identified by the 1221 candidate path identifier TLV and sends a report back to PCE. Note, 1222 in this case the End point object is optional. The end point object 1223 (optionally) is added if the root has discovered any new leaves on 1224 the PCC. 1226 Sample Report generated by the Root to the PCE for Leaf Add 1228 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 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Flags = 0 | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | SRP-ID-number = 1 | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | | PST = TBD | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 1239 | PLSP-ID = 1 | A:1,D:1,N:1 | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | Type=17 | Length= | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | symbolic path name | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Type=TBD | Length | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | Root = A | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Tree-ID = Y | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Instance-ID =L1 | Reserved | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 1255 | Leaf type =1 | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Source IPv4 address = A | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Destination IPv4 address = D | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Destination IPv4 address = E | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 5.3. PCE P2MP Path-Instance Calculation and Replication Segment 1265 download 1267 Once the PCRpt message including the endpoints (optional in case of 1268 PCE Initiated) is sent to the PCE, PCE computes the path from root to 1269 the leaves and would send a PCInitiate to the transit and leaf nodes 1270 for instantiating the replication segment for the Path-Instance. 1272 In addition a PCUpd is send to the Root node to construct the 1273 replication segment. 1275 The forwarding information is downloaded via the ERO object, ERO- 1276 attribute object and SR-ERO sub-objects. For example, say PCE 1277 computed 2 candidate paths that needs to be downloaded 1278 on the root and their corresponding Replication Segment download to 1279 the root, transit and leaf nodes. The sample messages are explained 1280 below. 1282 For cp1: 1284 o For PCC initiate case, the PCE will send a PCUpd message to 1285 download the Candidate Paths and the replication segment. Note on 1286 the root a single message with association object will achieve 1287 this. 1289 o For PCE initiate case, the PCE optionally sends a PCUpd message to 1290 instantiate the replication segment that were newly discovered by 1291 the PCC and send to the PCE via the PCRpt message.. Note for this 1292 case the association object might not be needed is there is no 1293 update to the P2MP Policy. 1295 For cp2: 1297 o For both PCC/PCE initiate, a PCInitiate messages sent from PCE, 1298 initiating the new Candidate Path and its associated Replication 1299 Segments. 1301 For both CP1 and CP2 on the transit and leaves, since PCE is 1302 initiating newly Replication Segments, PCE will send one PCInitiate 1303 message with two LSP objects and no association object, defining the 1304 Replication Semgnets on each candidate path. On other hand, PCE can 1305 send separate PCInitiate message for every Replication Segment. As 1306 defined in [draft-barth-pce-segment-routing-policy-cp] 1308 A sample PCUpd message sent to the Root for cp1 is as follows, NOTE 1309 in the below example the Node B is not Replication Segment Capable as 1310 such there is a sid-list programmed on A with node SID B as steering 1311 followed by node SID of C and finally the Replication SID C at the 1312 bottom : 1314 Note: 1316 1. Root is connected to the next replication Segment C via non 1317 replication segment B. Hence a segment List is used. 1319 2. The following PCUpd message send to the root is for PCC Initiated 1320 case as such it has the association object to instantiate the 1321 Candidate Path and the Replication Segment via a single message 1322 on the root. 1324 3. For PCE Initiate message the association object can be omitted 1325 sense it is only used for instantiating or updating the 1326 Replication Segment only. 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Flags = 0 | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | SRP-ID-number = 2 | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | | PST = TBD | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 1339 | PLSP-ID = 1 | A:1,D:1,N:1,C:0 | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Type=17 | Length= | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | symbolic path name | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Type=TBD | Length | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Root =A | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Tree-ID = Y | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Instance-ID = L1 | Reserved | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Type | Length | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | BT= 0 | Reserved | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Binding value = incoming replication SID | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Reserved | Flags |0| 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Association type= SR-P2MP-PAG | Association ID = z | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | IPv4 Association Source = | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Type | Length | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Root = A | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | TREE-ID = 0 | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Type | Length | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 |ProtOrigin 10 | Reserved | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Originator ASN | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | | 1380 | Originator Address = | 1381 | | 1382 | | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Discriminator = 1 | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Type | Length | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Preference = 100 | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Flags | Oper| 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Type | Length | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 |1|0|0| Reserved | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | ERO-path Id = 1 | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Back-up ero path id = 0 | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | SID = node sid b | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | SID = node sid c | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | SID = RSID C | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 A sample PC Initiate message to the Root for cp2 is as follows: Note 1416 cp2 can be either on the same path as cp1 or on a separate path, 1417 assuming that there is a 2nd path connecting A to B to C. In this 1418 example a 2nd interface is used on A and B, hence the adjacency SIDs 1419 are programmed 1420 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 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Flags = 0 | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | SRP-ID-number = 3 | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | | PST = TBD | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 1431 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | Type=17 | Length= | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | symbolic path name | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | Type=TBD | Length | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Root = A | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | Tree-ID = Y | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | Instance-ID = 0 | reserved | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | Type | Length | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | BT | Reserved | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Binding Value= incoming replication sid | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Reserved | Flags |0| 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Association type= SR-P2MP-PAG | Association ID = z | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | IPv4 Association Source = | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | Type | Length | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Root = A | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | TREE-ID = Y | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Type | Length | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 |ProtOrigin 10 | Reserved | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Originator ASN | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | | 1472 | Originator Address = | 1473 | | 1474 | | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Discriminator = 2 | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Type | Length | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Preference = 50 | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1482 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | Flags | Oper| 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Type | Length | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 |1|0|0| Reserved | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | ERO-path Id = 2 | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Back-up ero path id = 0 | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | SID = adjacency sid a-b-int2 | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | SID = adjacency sid b-c-int2 | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | SID = RSID C | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 A sample PC Initiate message to the transit Replication Segment C for 1508 cp1 Lets assume C is connected to D and E via 2 fiber hence Fast 1509 Reroute is possible. Below example sets up the forwarding plane fro 1510 C to Leaves D and E 1512 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 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | Flags = 0 | 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | SRP-ID-number = 4 | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | | PST = TBD | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 1523 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Type=17 | Length= | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | symbolic path name | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Type=TBD | Length | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Root=A | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Tree-ID = Y | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Instance-ID =L1 | Reserved | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Type | Length | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | BT | Reserved | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Binding Value= incoming replication sid = c1 | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 1544 1545 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | Flags | Oper| 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | Type | Length | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 |1|0|1| Reserved | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | ERO-path Id = 3 | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Back-up ero path id = 4 | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | SID = d1 | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | ipv4-address = NHD1 | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | Flags | Oper| 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Type | Length | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 |0|1|0| Reserved | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | ERO-path Id = 4 | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Back-up ero path id = 0 | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | SID = d protect | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | ipv4-address = NHD2 | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 1583 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Flags | Oper| 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Type | Length | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 |1|0|1| Reserved | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | ERO-path Id = 5 | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | Back-up ero path id = 6 | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | SID = e1 | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | ipv4-address = NHE1 | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Flags | Oper| 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Type | Length | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 |0|1|0| Reserved | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | ERO-path Id = 6 | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Back-up ero path id = 0 | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | SID = e protect | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | ipv4-address = NHE2 | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 5.4. PCC Rpt for PCE Update and Init Messages 1622 In response to the PC Initiate message / PC Update message , PCC will 1623 send PC Reports to PCE indicating the state of the label download for 1624 that particular candidate path. PCC's will generate PLSP-ID for 1625 newly initiated candidate path. Here is an PC Report Message send 1626 for the root PCE Init message with cp2 on the root. 1628 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 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Flags = 0 | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | SRP-ID-number = 2 | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | | PST = TBD | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 1639 | PLSP-ID = 1 | O:1,A:1,D:1,N:1,C:1| 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Type=17 | Length= | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | symbolic path name | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Type=TBD | Length | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Root | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Tree-ID | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | Instance-ID = L1 | Reserved | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 1654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1655 | Flags |O =Up| 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Type | Length | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 |1|0|1| Reserved | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | ERO-path Id = 5 | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | Back-up ero path id = 6 | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 6. Tree Deletion 1668 To delete the entire tree (P2MP LSP) , Root send a PCRpt message with 1669 the R bit of the LSP object set and all the fields of the SR-P2MP- 1670 LSP-ID TLV set to 0(indicating to remove all state associated with 1671 this P2MP tunnel). The controller in response sends a PCInitiate 1672 message with R bit in the SRP object SET to all nodes along the path 1673 to indicate deletion of a label entry. 1675 7. Fragmentation 1677 The Fragmentation bit in the LSP object (F bit) can be used to 1678 indicate a fragmented PCEP message 1680 8. Example Workflows 1682 As per slides submitted in IETF 105. 1684 9. IANA Consideration 1686 1. This draft extends the PCEP OPEN object by defining an optional 1687 TLV to indicate the PCE's capability to perform SR-P2MP path 1688 computations with a new IANA capability type (TBD). 1690 2. PCEP open object with a new association type " P2MP SR Policy 1691 Association " value (TBD). 1693 3. A new Association type. Association type = TBD1 "P2MP SR Policy 1694 Association Type" for SR Policy Association Group (P2MP SRPAG) 1696 1. three new TLVs are identified to carry association 1697 information: P2MP-SRPAG- POL-ID-TLV, P2MP-SRPAG-CPATH-ID-TLV, 1698 P2MP-SRPAG-CPATH-ATTR-TLV 1700 4. Two new TLVs for Identifying the P2MP Policy and the Replication 1701 segment SR-IPV4-P2MP-POLICY-ID TLV and SR-IPV6-P2MP-POLICY-ID TLV 1703 5. A new SR-P2MP-NODE-ROLE TLV (Type To be assigned by IANA) that 1704 will be present in the PATH-ATTRIB object 1706 10. Security Considerations 1708 TBD 1710 11. Acknowledgments 1712 The authors would like to thank Tanmoy Kundu and Stone Andrew at 1713 Nokia for their feedback and major contribution to this draft. 1715 12. References 1717 12.1. Normative References 1719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1720 Requirement Levels", BCP 14, RFC 2119, 1721 DOI 10.17487/RFC2119, March 1997, 1722 . 1724 12.2. Informative References 1726 [draft-barth-pce-segment-routing-policy-cp] 1727 . 1729 [draft-dhs-spring-sr-p2mp-policy-yang] 1730 . 1732 [draft-ietf-pce-segment-routing-policy-cp] 1733 . 1735 [draft-ietf-pce-stateful-pce-p2mp] 1736 . 1738 [draft-ietf-pim-sr-p2mp-policy] 1739 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 1740 "draft-voyer-pim-sr-p2mp-policy"", October 2019. 1742 [draft-ietf-spring-segment-routing-policy] 1743 . 1745 [draft-ietf-spring-sr-replication-segment] 1746 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 1747 "draft-voyer-pim-sr-p2mp-policy "draft-voyer-spring-sr- 1748 replication-segment"", July 2020. 1750 [draft-koldychev-pce-multipath] 1751 . 1753 [draft-parekh-bess-mvpn-sr-p2mp] 1754 . 1756 [draft-sivabalan-pce-binding-label-sid] 1757 . 1759 [RFC3209] . 1761 [RFC6513] . 1763 [RFC8231] . 1765 [RFC8236] . 1767 [RFC8306] . 1769 [RFC8664] . 1771 [RFC8697] . 1773 Authors' Addresses 1775 Hooman Bidgoli (editor) 1776 Nokia 1777 Ottawa 1778 Canada 1780 Email: hooman.bidgoli@nokia.com 1782 Daniel Voyer 1783 Bell Canada 1784 Montreal 1785 Canada 1787 Email: daniel.yover@bell.ca 1789 Saranya Rajarathinam 1790 Nokia 1791 Mountain View 1792 US 1794 Email: saranya.Rajarathinam@nokia.com 1796 Ehsan Hemmati 1797 Cisco System 1798 San Jose 1799 USA 1801 Email: ehemmati@cisco.com 1803 Tarek Saad 1804 Juniper Networks 1805 Ottawa 1806 Canada 1808 Email: tsaad@juniper.com 1810 Siva Sivabalan 1811 Ciena 1812 Ottawa 1813 Canada 1815 Email: ssivabal@ciena.com