idnits 2.17.1 draft-hsd-pce-sr-p2mp-policy-01.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 : ---------------------------------------------------------------------------- ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2019) is 1634 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 section? 'RFC 6514' on line 392 looks like a reference -- Missing reference section? 'RFC 6513' on line 392 looks like a reference -- Missing reference section? 'RFC2119' on line 175 looks like a reference -- Missing reference section? 'RFC8231' on line 892 looks like a reference -- Missing reference section? 'RFC8236' on line 302 looks like a reference -- Missing reference section? 'RFC 3209' on line 314 looks like a reference -- Missing reference section? 'RFC8306' on line 816 looks like a reference -- Missing reference section? 'RFC3209' on line 351 looks like a reference -- Missing reference section? 'RFC6513' on line 397 looks like a reference -- Missing reference section? 'RFC6514' on line 397 looks like a reference -- Missing reference section? 'I-D.ietf-spring-segment-routing-policy' on line 809 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 12 comments (--). 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: Standard Track D. Voyer, Ed. 5 Bell Canada 6 S. Rajarathinam 7 J. Kotalwar 8 Nokia 9 S. Sivabalan 10 Cisco System, Inc. 11 T. Saad 12 Juniper 14 Expires: May 5, 2020 November 2, 2019 16 PCEP extensions for p2mp sr policy 17 draft-hsd-pce-sr-p2mp-policy-01 19 Abstract 21 SR P2MP policies are set of policies that enable architecture for 22 P2MP service delivery. 24 This document specifies extensions to the Path Computation Element 25 Communication Protocol (PCEP) that allow a stateful PCE to compute 26 and initiate P2MP paths from a Root to a set of Leaves. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." The list 42 of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on October 8, 2017. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Conventions used in this document . . . . . . . . . . . . . . . 4 69 3. Overview of PCEP Operation in SR P2MP Network . . . . . . . . . 4 70 3.1. High level view of a P2MP Policy Objects . . . . . . . . . 5 71 3.1.1. shared tree vs non-shared tree . . . . . . . . . . . . 6 72 3.1.1. Existing drafts used in defining the P2MP Policy . . . 6 73 3.1.2. P2MP Policy Identification . . . . . . . . . . . . . . 8 74 3.1.3. Replication Segment Identification . . . . . . . . . . 8 75 3.2 High-Level Procedures for P2MP SR LSP Instantiation . . . . 8 76 3.2.1 MVPN procedures . . . . . . . . . . . . . . . . . . . . 9 77 3.2.2. Global Optimization for P2MP LSPs . . . . . . . . . . . 11 78 3.2.3. Fast Reroute . . . . . . . . . . . . . . . . . . . . . 11 79 3.2.3. Connecting Replication Segment via Segment List . . . . 12 80 3.3. SR P2MP Policy and Replication Segment TLVs and Objects . . 12 81 3.3.1. SR P2MP Policy Objects . . . . . . . . . . . . . . . . 13 82 3.3.2. Replication Segment Objects . . . . . . . . . . . . . . 13 83 3.3.3. P2MP Policy vs Replication Segment . . . . . . . . . . 13 84 3.3.4. P2MP Policy and Replication Segment general 85 considerations . . . . . . . . . . . . . . . . . . . . 13 86 4. Object Format . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.1. Open Message and Capability Exchange . . . . . . . . . . . 14 88 4.2. Symbolic Name in PCInitiate message from PCC . . . . . . . 15 89 4.3. P2MP Policy Specific Objects and TLVs . . . . . . . . . . . 15 90 4.3.1. P2MP Policy Association Group for P2MP Policy . . . . . 15 91 4.3.1.2. P2MP SR Policy Association Group Policy 92 Identifiers TLV . . . . . . . . . . . . . . . . . . 15 94 4.3.1.3. P2MP SR Policy Association Group Candidate Path 95 Identifiers TLV . . . . . . . . . . . . . . . . . . 16 96 4.3.1.4. P2MP SR Policy Association Group Candidate Path 97 Attributes TLV . . . . . . . . . . . . . . . . . . 17 98 4.3.2. P2MP-END-POINTS OBJECT . . . . . . . . . . . . . . . . 18 99 4.4. P2MP Policy and Replication Segment Identifier Object and 100 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 4.4.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV . . . . . 20 102 4.5. Replication Segment . . . . . . . . . . . . . . . . . . . . 21 103 4.5.1. shared vs non-shared replication segment . . . . . . . 21 104 4.5.2. The format of the replication segment message . . . . . 21 105 4.5.3. Label action rules in replicating segment . . . . . . . 21 106 5. Examples of PCEP messages between PCE and PCEP . . . . . . . . 22 107 5.1. PCE Initiate and PCC Leaves Update . . . . . . . . . . . . 22 108 5.2. PCE P2MP LSP Calculation and Replication Segment download . 25 109 5.3. PCC Rpt for PCE Update and Init Messages . . . . . . . . . 32 110 6. Tree Deletion . . . . . . . . . . . . . . . . . . . . . . . . . 33 111 7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 8. Example workflow . . . . . . . . . . . . . . . . . . . . . . . 34 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 114 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 34 115 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 116 8.1. Normative References . . . . . . . . . . . . . . . . . . . 34 117 8.2. Informative References . . . . . . . . . . . . . . . . . . 34 118 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 34 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 121 1. Introduction 123 The draft [draft-voyer-pim-sr-p2mp-policy] defines a variant of the 124 SR Policy [I-D. ietf-spring-segment-routing-policy] for constructing 125 a 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. We also define a Replication segment, which corresponds 129 to the state of a P2MP segment on a particular node, as an example 130 the forwarding instructions for the replication SID. 132 A P2MP Policy is relevant on the root of the P2MP Tree and it 133 contains candidate paths. The candidate paths are made of replication 134 segments that are programmed on the root, leaves and optionally 135 intermediate replication nodes. 137 It should be noted that two replication segments can be connected 138 directly, or they can be connected via unicast SR segment or a 139 segment list. 141 For a P2MP Tree, a controller may be used to compute paths from a 142 Root node to a set of Leaf nodes, optionally via a set of replication 143 nodes. A packet is replicated at the root node and optionally on 144 Replication nodes towards each Leaf node. 146 We define two types of a P2MP Tree: Spray and Replication. 148 A Point-to-Multipoint service delivery could be via Ingress 149 Replication (aka Spray in some SR context), i.e., the root unicasts 150 individual copies of traffic to each leaf. The corresponding P2MP 151 Policy consists of replication segments only for the root and the 152 leaves and they are connected via a SR Segment 154 A Point-to-Multipoint service delivery could also be via Downstream 155 Replication (aka TreeSID in some SR context), i.e., the root and some 156 downstream replication nodes replicate the traffic along the way as 157 it traverses closer to the leaves. 159 The leaves and the root can be explicitly configured on the PCE or 160 PCC can updates the PCE with the information of the discovered root 161 and leaves. As an example Multicast protocols like mvpn procedures 162 [RFC 6514, RFC 6513] or pim can be used to discovery the leaves and 163 roots on the PCC and update the PCE with these relevant information. 164 The controller can calculate the P2MP Policy based on these info. 166 In all of above cases a set of new PCEP object and TLVs are needed to 167 update and instantiate the P2MP tree. This draft explains the 168 procedure needed to instantiate a P2MP TreeSID. 170 2. Conventions used in this document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 3. Overview of PCEP Operation in SR P2MP Network 178 For a P2MP SR policy, a PCE calculates a P2MP tree and programs the 179 Root, Transit and Leaf nodes with information needed to forward a 180 multicast stream from the root to a set of leaves. The PCE discovers 181 the Root and the set of the Leaves via manual configuration on the 182 PCE. On other hand the PCC (Root of the P2MP Tree) can provide the 183 PCE with the relevant information by discovering the leaves via mvpn 184 procedures or pim . 186 After discovering the Root and Leaves and computing the MPLS P2MP 187 Tree and identifying the Replication routers, the PCE programs the 188 PCCs with relevant information needed to create a P2MP Tree. 190 As per draft draft-voyer-pim-sr-p2mp-policy a P2MP Policy is defined 191 by a root and set of leaves. A P2MP policy is a variant of SR policy 192 as such it uses the same concept as draft draft-darth-pce-sement- 193 routing-policy-cp. In short a P2MP policy uses a collection of SR 194 P2MP Candidate paths. Candidate paths are computed by the PCE and can 195 be used for P2MP Tree redundancy. Each candidate paths can be 196 globally optimized and is consists of multiple path-instances. A 197 path-instance can be thought of as a P2MP LSP. If a candidate path is 198 needed to be globally optimized two path-instances can be programmed 199 on the node and via make before procedures the candidate path can be 200 switched from path-instance 1 to the 2nd. The forwarding states of 201 these path-instances are build via replication segments. 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 and 205 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 such as 209 next-hops for link/node protection. 211 3.1. High level view of a P2MP Policy Objects 213 -SR P2MP Policy: 215 -Is only relevant on the root of the P2MP tree and is a policy on 216 PCE which contains information about: 218 - root node of the P2MP Segment 220 - leaf nodes of the P2MP Segment 222 - Tree-ID, which is a unique identifier of the P2MP tree on the 223 root 225 - It also contains a set of Candidate paths and their path- 226 instances for P2MP tree redundancy and global optimization 228 - optional constrains used to build these candidate paths 230 - Path-instances which are P2MP LSPs under each candidate path 231 for global optimization of the candidate path. 233 - P2MP policy information is downloaded only on the Root node and 234 is identified via 236 -Candidate Path: 238 - Is used for P2MP Tree redundancy where the P2MP LSP with the 239 highest preference is the active LSP 241 - It can contain up to two path-instance P2MP LSP global 242 optimization procedures, each identified with their own path- 243 instance-ID (i.e. make before break) 245 - Contains information about protocol-id, originator, 246 discriminator, preference, path-instances. 248 -Replication Segment: 250 - Is the forwarding information needed on each node for building 251 the datapath for each path-instance of the P2MP Candidate path. 253 o As it will be explained in upcoming sections there are 2 ways 254 to identify the replication segment, shared and non-shared trees 256 - Tree-ID and Root-ID and path-instance for non-shared trees. 258 - Its node-ID, Replication-id, for shared trees 260 - Contains forwarding instructions for the path-instances (P2MP 261 LSPs), these instructions can be a replication SID or a segment 262 list. 264 - Replication segment information downloaded on Root, Transit 265 and Leaf nodes respectively. 267 3.1.1. shared tree vs non-shared tree 269 A non-shared tree is used when the label field of the PMSI Tunnel 270 Attribute (PTA) is set to zero as per [draft-parekh-bess-mvpn-sr- 271 p2mp]. In short this tree is used when there is no upstream assigned 272 label in the PTA and aggregate of MVPNs into a single P-Tunnel is not 273 desired. 275 On other hand shared tree is used when the label field of the PTA is 276 NOT set to Zero and there is an upstream assigned label in the PTA. 277 In this case multiple MVPNs (VRFs) can be aggregate into a single P- 278 Tunnel and the upstream assigned label distinguishes the MVPNs. 280 3.1.1. Existing drafts used in defining the P2MP Policy 282 P2MP Policy reuses current drafts and PCEP objects to identify the 283 root and the leaves on the P2MP Segment and update the PCE with these 284 information, and also to have PCE initiate and update P2MP 285 Replication Policies on a the PCC. 287 In addition this draft will introduced new TLVs and Objects specific 288 to a P2MP Policy. 290 This draft reuses the following pcep drafts and concepts: 292 - [RFC8231] The bases for a stateful PCE, and reuses the following 293 objects or a variant of them 295 297 299 o A variation of the LSP identifier TLV is defined in this 300 draft, to support P2MP LSP Identifier 302 - [RFC8236] P2MP capabilities advertisement 304 - [draft-barth-pce-segment-routing-policy-cp-02] Candidate paths for 305 P2MP Policy is used for Tree Redundancy. As an example a P2MP Policy 306 can have multiple candidate paths each protecting the primary 307 candidate path. The active path is chosen via the preference of the 308 candidate path. 310 - [RFC 3209] defines the instance-ID, instance-ID is used for global 311 optimization of a candidate path with in a P2MP policy. Each 312 Candidate path can have 2 sub-lsps (instance-IDs) for MBB and global 313 optimization procedures. instance-ID is equivalent to LSP ID as per 314 [RFC 3209] 316 - [draft-ietf-spring-segment-routing-policy] segment-list, used for 317 connecting two non-adjacent replication policy via a unicast binding 318 SID or Segment-list. 320 - [RFC8306] P2MP End Point objects, used for the PCC to update the 321 PCE with discovered Leaves. 323 - [draft-sivabalan-pce-binding-label-sid-04#section-3] Path binding 324 TLV is used to indicate the incoming replication SID 326 - [draft-koldychev-pce-multipath-01] forwarding instruction for a 327 P2MP LSP is defined by a set of SR-ERO sub-objects in the ERO object, 328 ERO-ATTRIBUTES object and MULTIPATH-BACKUP TLV as defined in this 329 draft. 331 - [draft-ietf-pce-segment-routing] SR-ERO Sub Object used in the 332 multipath. 334 It should be noted that the [draft-dhs-spring-sr-p2mp-policy-yang] 335 can provide further details of the high level P2MP Policy Model. 337 3.1.2. P2MP Policy Identification 339 A P2MP Policy and its candidate path on the root can be identified on 340 the Root via the P2MP LSP Object, this Object is a variation of the 341 LSP ID Object defined in RFC 8231 and is as follow: 343 PLSP-ID: RFC 8231, is assigned by PCC and is unique per candidate 344 path. It is constant for the lifetime of a PCEP session. Stand-by 345 P2MP LSPs will be downloaded with a new PLSP-ID, since every P2MP LSP 346 is a candidate path on its own. It should be noted a stand-by LSP is 347 a LSP to protect the primary LSP and can be setup in parallel to the 348 primary LSP. 350 Root-ID: is equivalent to the first MPLS node on the path, as per 351 [RFC3209], Section 4.6.2.1 353 Tree-ID: is equivalent to Tunnel Identifier color which identifies a 354 unique P2MP segment at a ROOT and is advertised via the PTA in the 355 BGP AD route. 357 Instance-ID: LSP ID Identifier as defined in RFC 3209, and is used 358 for global optimization of a P2MP LSP (Candidate path) 360 Note that the Root-ID, Tree-ID and instance-ID are part of a new SR- 361 P2MP-LSP-IDENTIFIER TLV which will be identified in this draft. 363 3.1.3. Replication Segment Identification 365 The key to identify a replication segment is also the P2MP LSP 366 Object. 368 That said there are different rules for coding the SR-P2MP-LSP- 369 IDENTIFIER TLV which will be explained in later sections. 371 3.2 High-Level Procedures for P2MP SR LSP Instantiation 373 A P2MP policy is defined by Root, Tree-Id, set of Leaves. It also 374 contains a set of candidate-path and path-instances which are used 375 for global optimization of the candidate paths. The P2MP policy is 376 used to calculate and download a set of replication segment to 377 connect the root to a set of leaves, optionally via a set of transit 378 nodes. As mentioned previously a replication segments are set of 379 forwarding rules used on root, transit nodes and leaves. Each path- 380 instance of a candidate path will have a set of replication segments 381 to connect the root the leaves via a set of transit nodes. A path- 382 instance can be viewed as a P2MP LSP. 384 The Root and Leaves can be discovered via many methods. 386 - They can be configured and identified on a controller 388 - They can be configured on the root node PCC and the root updates 389 the PCE with this information 391 - They can be discovered via Multicast mechanisms like MVPN 392 procedures [RFC 6513] and [RFC 6514] or protocols like PIM. 394 3.2.1 MVPN procedures 396 In case of MVPN there can be pcc-initiated or pce-initiated p2mp 397 policy. In either case MVPN procedures [RFC6513, RFC6514] are used to 398 discover the leaves on PCC and report them up to the PCE. 400 1. PCE-initiated Procedure : 402 o PCE is informed of the P2MP request through it's API or 403 configuration mechanism to instantiate a P2MP tunnel. 405 o PCE will initiate the P2MP Tunnel for the request, by sending a PC 406 Initiate message to the Root and start programing the P2MP Policy on 407 the root. 409 o Root in response to the PC Initiate message. It will generate PLSP- 410 ID for the candidate paths, Path-Instance-ID for the P2MP LSP 411 contained with in a candidate path and tree-id for the candidate 412 paths and P2MP Policy. It will reports back the PLSP-ID, Instance ID 413 and tree-id, and any leaves that were discovered until then to PCE. 415 o PCE on discovering leaves from the root, will compute the P2MP 416 Policy from the Root to the leaves and downloads the replication 417 segment by sending PC Initiate message on the transit and leaf nodes. 419 o PCE will also sends a PC Initiate message to the Root for the 420 Replication Segment. 422 2. PCC Initiated Procedure: 424 After Root discovers the leaves (as an example via MVPN Procedures), 425 the following communication happens between the PCE and PCCs 427 o Root sends a PC Report for P2MP policy to PCE including the root, 428 tree-id, PLSP-ID, Path-Instance-ID, symbolic-path-name, and any 429 leaves discovered until then. 431 o PCE on receiving of this report, will compute the P2MP Policy and 432 its replication segments. 434 - On Root it will send and update for P2MP policy with the PLSP-ID 435 and the corresponding replication segment. It should be noted the 436 replication segment is downloaded via an update message also. 438 - It will download replication segments to leaves and transit nodes 439 using PC Initiate message with PLSP-ID = 0, symbolic path name, 440 Root-address, Tree-id(sent by the root), Instance-id(sent by root). 441 The replication segment information(containing TE-Path binding TLV, 442 ERO object, ERO attributes object, multipath backup TLV,SR-ERO sub- 443 objects). 445 Beyond this, procedures for (1) and (2) are same. 447 o Any new candidate path is downloaded by PCE to its connected Root 448 by sending a PC Initiate message to them. 450 - it should be noted, PLSP-ID, Path-Instance-ID and the Tree-ID are 451 generated by the PCC 453 o The replication segments are downloaded via a PC Initiate message 454 to the Root, Transit and Leaf nodes for these new candidate paths and 455 their Path-Instance-ID. 457 - it should be noted, a replication segment message never has the 458 association object. 460 o Every candidate path is a different P2MP Tree which gets a unique 461 PLSP-ID. All candidate path is associated to the same SR-P2MP policy. 463 o Any new leaves discovered from here on, are reported to PCE. 465 o If these leaves are discovered on routers that are part of the P2MP 466 LSP path, then PC Update is sent from PCE to necessary PCCs (LEAVES, 467 TRANSIT or ROOT) with the LSPs PLSP-ID. 469 o If the new leaves are discovered on routers that are not part of 470 the P2MP Tree yet, then a PC Initiate message is sent down with PLSP- 471 ID=0. 473 o The candidate-path that was informed by PCE to PCC, is active or 474 not is indicated by the PCC through the operational bits(Up/Active) 475 of the LSP object in the PC Report. If a candidate path needs to be 476 removed, PCE sends PC Initiate message, setting the R-flag in the LSP 477 object and R bit in the SRP-object. 479 o To remove the entire P2MP-LSP, PCE needs to send PC Initiate remove 480 messages for every candidate path of the SR-P2MP-POLICY to all the 481 PCE connected nodes along the P2MP-LSP path. The R bit in the LSP 482 Object as defined in rfc8231, refers to the removal of the LSP as 483 identified by the SR-P2MP-POLICY-ID-TLV (defined in this document). 484 An all zero (SR-P2MP-LSP-ID-TLV defines to remove all the state of 485 the corresponding PLSP-ID. 487 o A candidate path is made active based on the preference of the 488 path. If the Root gets paths one from the PCE and one from the CLI, 489 and based on its tie-breaking rules, if it selects the CLI path, it 490 will send a report to PCE for the PCE path indicating the status of 491 label-download and sets operational bit of the LSP object to UP and 492 Not Active . At any instance, only one path will be active. 494 o Discovery of local replication policies is outside the scope of 495 this document, however it may be achieved using methods such as 496 learning via NMS, NetConf or extending dynamic discovery protocols 497 such as extending draft-ietf-idr-te-lsp-distribution for sr 498 replication policies 500 3.2.2. Global Optimization for P2MP LSPs 502 When a P2MP LSP needs to be optimized for any reason (i.e. it is 503 taking a FRR tunnel or new routers are added to the network) a global 504 optimization is possible. At any instance, a PCE can download more 505 than one candidate path to the existing SR-P2MP policy. Each 506 candidate path has a unique PLSP-ID generated by PCC. Only one 507 candidate path can be active at any instance. A candidate path is 508 made active based on the preference of the path. On MBB, PCE will 509 update the candidate path with a new path, and two paths will briefly 510 co-exist. Two paths are uniquely identified by the Instance-ID in the 511 SR-P2MP-POLICY-ID-TLV (defined in this document). After the optimized 512 LSP has been downloaded successfully PCC MUST send two reports, 513 reporting UP of the new path indicating the new LSP-ID, and a second 514 reporting the tear down of the old path with the R bit of the LSP 515 Object SET with the old Instance-ID in the SR-P2MP-POLICY-ID-TLV. 517 3.2.3. Fast Reroute 519 Currently this draft identifies the Facility FRR procedures. In 520 addition, only LINK Protection procedures are defined. How the 521 Facility Path is built and instantiated is beyond the scope of this 522 document. 524 R 525 | | 526 T 527 | 528 --- 529 | | 530 L1 L2 532 Figure 1 534 R---F1 535 | | 536 T---F2 537 | 538 --- 539 | | 540 L1 L2 542 Figure 2 544 As an example, the bypass path (unicast bypass) between the PLR and 545 MP can be constructed via SR. 547 As an example, in figure 1 the detour path between R and T is the 2nd 548 fiber between these nodes. As such the bypass path could be setup on 549 the 2nd fiber. That said in figure 2 the bypass path is traversing 550 multiple nodes and this example a unicast SR path might be ideal for 551 setting up the detour path. 553 In addition, PHP procedure and implicit null label on the bypass path 554 can be implemented to reduce the PCE programming on the MP PCC. 556 3.2.3. Connecting Replication Segment via Segment List 558 There could be nodes between two replication segment that do not 559 understand P2MP Policy or Replication segment. It is possible to 560 connect two non-adjacent Replication segment via a unicast binding 561 SID or segment-list. 563 Replication segment does support the concept of a segment-list. A 564 list of unicast SIDs (Binding SID, Adjacency SIDs or Node SIDs) can 565 be programmed on a Replication segment via the SR-ERO sub-objects and 566 ERO-attributes object. 568 3.3. SR P2MP Policy and Replication Segment TLVs and Objects 569 3.3.1. SR P2MP Policy Objects 571 SR P2MP Policy can be constructed via the following objects 573 574 [] 575 576 [] 578 optionally if the root is updating the PCE with end point list the 579 end-point-list object can be added. 581 [] 583 3.3.2. Replication Segment Objects 585 Replication segment can be constructed via the following objects 587 588 [] 589 590 [] 591 as described in 592 [draft-sivabalan-pce-binding-label-sid-06#section-3] 593 [] 594 as per [draft-koldychev-pce-multipath] 596 3.3.3. P2MP Policy vs Replication Segment 598 Note P2MP Policy and Replication segments objects have a very close 599 definition. They can be told apart via the following abstracts: 601 o The P2MP Policy will always have an association list object at 602 least in its PC-Init message. While the replication segment does not 603 have the association list object. 605 o Both P2MP Policy and Replication segment have the PLSP-ID and it is 606 set to 0 in the PC-Init message. For both Objects the PLSP-ID is set 607 via the PCC. 609 3.3.4. P2MP Policy and Replication Segment general considerations 611 The above new objects and TLV's defined in this document can be 612 included in PcReport, PcInitiate and PcUpdate messages. 614 It should be noted that every PcReport, PcInitiate and PCUPdate 615 messages will contain full list of the Leaves and label and 616 forwarding information that is needed to build the P2MP LSP. They 617 will never send the delta information related to the new leaves that 618 need to be added or updated. This is necessary to ensure that PCE or 619 any new PCE is in sync with the PCC. 621 As such when a PcReport, PcInitiate and PCUPdate messages is send via 622 PCEP it maintains the previous ERO path Id and generates new path Id 623 for new instructions. This means the pathId are maintained for each 624 specific forwarding and label instructions until these instructions 625 are deleted. For example: When the first leaf is added I get 626 instructions, path-id A, path-id B on a node. On a second leaf add, 627 according to the path calculated, PCE might just append the existing 628 instruction A,B with C,D. This is done by sending a PC Update with 629 downstream-index A, B, C,D. 631 ERO path-Id requirements are mentioned in draft-koldychev-pce- 632 multipath-01 and MUST be followed. 634 4. Object Format 636 4.1. Open Message and Capability Exchange 638 Format of the open object 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Ver | Flags | Keepalive | DeadTimer | SID | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | 645 // Optional TLVs // 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 All the nodes need to establish a PCEP connection with the PCE. 651 During PCEP Initialization Phase, PCEP Speakers need to set flags N, 652 M, P in the STATEFUL-PCE-CAPABILITY TLV as defined in 653 https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-p2mp- 654 08#section-5.2 656 We extend the PCEP OPEN object by defining an optional TLV to 657 indicate the PCE's capability to perform SR-P2MP path computations, 658 New IANA capability type. The inclusion of this TLV in an OPEN object 659 indicates that the sender can perform SR-P2MP path computations. This 660 will be similar to the P2MP-CAPABILITY defined in 661 https://tools.ietf.org/html/rfc8306#section-3.1.2 and a new value 662 needs to be defined for SR-P2MP. 664 In addition a Assoc-Type-List TlV as per [draft-ietf-pce-association- 665 group-07] section 3.4 should be send via PCEP open object with 666 following association type 668 +-------------------+----------------------------+------------------+ 669 | Association Type | Association Name | Reference | 670 | Value | | | 671 +-------------------+----------------------------+------------------+ 672 | TBD1 | P2MP SR Policy Association | This document | 673 +-------------------+----------------------------+------------------+ 675 OP-CONF-Assoc-RANGE (Operator-configured Association Range)should not 676 be set for this association type and must be ignored. 678 Finally the open message needs to include the MULTIPATH CAPABILITY 679 TLV as defined in draft-koldychev-pce-multipath-01 681 4.2. Symbolic Name in PCInitiate message from PCC 683 As per RFC8231 section 7.3.2. a Symbolic Path Name TLV should 684 uniquely identify the P2MP path on the PCC. This symbolic path name 685 is a human-readable string that identifies an P2MP LSP in the 686 network. It needs to be constant through the life time of the P2MP 687 path. 689 As an example in the case of P2MP LSP the symbolic name can be p2mp 690 policy name + candidate path name of the LSP. 692 4.3. P2MP Policy Specific Objects and TLVs 694 4.3.1. P2MP Policy Association Group for P2MP Policy 696 Two ASSOCIATION object types for IPv4 and IPv6 are defined in [I- 697 D.ietf-pce-association-group]. The ASSOCIATION object includes 698 "Association type" indicating the type of the association group. This 699 document adds a new Association type. 701 Association type = TBD1 "P2MP SR Policy Association Type" for SR 702 Policy Association Group (P2MP SRPAG). 704 As per [draft-barth-pce-segment-routing-policy-cp] section 5, three 705 new TLVs are identified to carry association information: P2MP-SRPAG- 706 POL-ID-TLV, P2MP-SRPAG-CPATH-ID-TLV, P2MP-SRPAG-CPATH-ATTR-TLV 708 4.3.1.2. P2MP SR Policy Association Group Policy Identifiers TLV 710 The P2MP-SRPOLICY-POL-ID TLV is a mandatory TLV for the P2MP-SRPAG 711 Association. Only one P2MP-SRPOLICY-POL-ID TLV can be carried and 712 only the first occurrence is processed and any others MUST be 713 ignored. 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Type | Length | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Root | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | TREE-ID | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 Type: TBD2 for "P2MP-SRPOLICY-POL-ID" TLV. 727 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 729 Tunnel Sender Address : Can be either IPv4 or IPv6, this value is 730 the value of the root loopback IP. 732 Tree-ID: Tree ID that the replication segment is part of as per 733 draft-ietf-spring-sr-p2mp-policy 735 4.3.1.3. P2MP SR Policy Association Group Candidate Path Identifiers TLV 737 The P2MP-SRPOLICY-CPATH-ID TLV is a mandatory TLV for the P2MPSRPAG 738 Association. Only one P2MP-SRPOLICY-CPATH-ID TLV can be carried and 739 only the first occurrence is processed and any others MUST be 740 ignored. 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Type | Length | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Proto. Origin |Flags |A| Reserved | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Originator ASN | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | | 752 | Originator Address | 753 | | 754 | | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Discriminator | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Type: TBD3 for "P2MP-SRPOLICY-CPATH-ID" TLV. 761 Length: 28. 763 Protocol Origin: 8-bit value that encodes the protocol origin, as 764 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 766 Flags : A: This candidate path is active. At any instance only one 767 candidate path can be active. PCC indicates the active candidate path 768 to PCE through this bit. 770 Reserved: MUST be set to zero on transmission and ignored on 771 receipt. 773 Originator ASN: Represented as 4 byte number, part of the 774 originator identifier, as specified in [I-D.ietf-spring-segment- 775 routing-policy] Section 2.4. 777 Originator Address: Represented as 128 bit value where IPv4 778 address are encoded in lowest 32 bits, part of the originator 779 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 780 Section 2.4. 782 Discriminator: 32-bit value that encodes the Discriminator of the 783 candidate path. 785 4.3.1.4. P2MP SR Policy Association Group Candidate Path Attributes TLV 787 The P2MP-SRPOLICY-CPATH-ATTR TLV is an optional TLV for the SRPAG 788 Association. Only one P2MP-SRPOLICY-CPATH-ATTR TLV can be carried 789 and only the first occurrence is processed and any others MUST be 790 ignored. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Type | Length | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Preference | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Type: TBD4 for "P2MP-SRPOLICY-CPATH-ATTR" TLV. 802 Length: 4. 804 Preference: Numerical preference of the candidate path, as 805 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 807 If the TLV is missing, a default preference of 100 as specified in 809 [I-D.ietf-spring-segment-routing-policy] is used. 811 4.3.2. P2MP-END-POINTS OBJECT 813 In order for the Root to indicate operations of its 814 leaves(Add/Remove/Modify/DoNotModify), the PC Report message is 815 extended to include P2MP End Point Object which is 816 defined in [RFC8306] 818 The format of the PC Report message is as follow: 819 820 [] 821 822 [] 823 [] 825 IPV4-P2MP END-POINTS: 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Leaf type | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Source IPv4 address | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Destination IPv4 address | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 ~ ... ~ 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Destination IPv4 address | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 IPV6-P2MP END-POINTS: 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Leaf type | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | | 847 | Source IPv6 address (16 bytes) | 848 | | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | | 851 | Destination IPv6 address (16 bytes) | 852 | | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 ~ ... ~ 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | | 857 | Destination IPv6 address (16 bytes) | 858 | | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Leaf Types (derived from RFC 8306 section 3.3.2) : 863 1.New leaves to add (leaf type = 1) 865 2.Old leaves to remove (leaf type = 2) 867 3.Old leaves whose path can be modified/reoptimized (leaf type 868 = 3), Future reserved not used for tree SID as of now. 870 4.Old leaves whose path must be left unchanged (leaf type = 4) 872 A given P2MP END-POINTS object gathers the leaves of a given type. 873 Note that a P2MP report can mix the different types of leaves by 874 including several P2MP END-POINTS objects. The END-POINTS object body 875 has a variable length. These are multiples of 4 bytes for IPv4, 876 multiples of 16 bytes, plus 4 bytes, for IPv6. 878 4.4. P2MP Policy and Replication Segment Identifier Object and TLV 880 As it was mentioned previously both P2MP Policy and Replication 881 Segment are identified via the LSP object and more precisely via the 882 SR-P2MP-LSPID-TLV 884 The P2MP Policy uses the PLSP-ID to identify the candidate paths and 885 the Path-Instance-ID to identify a P2MP LSP under the candidate path. 887 On other hand the Replication Segment uses the SR-P2MP-LSPID-TLV to 888 identify and correlate a Replication Segment to a P2MP Policy 890 4.4.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV 892 The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 893 the PLSP-ID to uniquely identify an LSP that is constant for the life 894 time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID 895 identify a candidate path uniquely with in the P2MP policy. 897 The LSP Object MUST include the new SR-P2MP-POLICY-ID-TLV (IPV4/IpV6) 898 defined in this document below. This is a variation to the P2MP 899 object defined in [draft-ietf-pce-stateful-pce-p2mp] 901 SR-IPV4-P2MP-POLICY-ID TLV: 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 | Type=TBD | Length=10 | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Root | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Tree-ID | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Path-Instance-ID | Reserved | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 SR-IPV6-P2MP-POLICY-ID TLV : 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Type=TBD | Length=22 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | | 921 + + 922 | Root | 923 + (16 octets) + 924 | | 925 + + 926 | | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Tree-ID | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Path-Instance-ID | Reserved | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 The type (16-bit) of the TLV is TBD (need allocation by IANA). 935 Root: Source Router IP Address 936 Tree-ID: Unique Identifier of this P2MP LSP on the Root. 938 Instance-ID : Contains 16 Bit instance ID. 940 4.5. Replication Segment 942 As per draft-voyer-spring-sr-replication-segment-00 a replication 943 segment has a next-hop-group which MAY contain a single outgoing 944 replication sid OR a list of SIDs (sr-policy-sid-list) 946 In either case there needs to be a replication SID at the bottom of 947 the stack. This means two replication segments can be directly 948 connected or connected via a SR domain. 950 4.5.1. shared vs non-shared replication segment 952 A non-shared tree is used when the label field of the PMSI Tunnel 953 Attribute (PTA) is set to zero as per [draft-parekh-bess-mvpn-sr- 954 p2mp]. In this case is when there is no upstream assigned label in 955 the PTA and aggregation of MVPNs into one P-Tunnel is not desired. 957 A shared tree, on other hand, has a non Zero label field in the PTA 958 and is used when there is an upstream assigned label in the PTA and 959 aggregate of MVPNs into one P-Tunnel is desired. 961 4.5.2. The format of the replication segment message 963 As it was mentioned in previous chapters the format of the 964 replication segment message is close to P2MP Policy. That said the 965 P2MP Policy contains the association object and the replication 966 segment message does not contain the association object. 968 The replication segment uses SR-P2MP-LSPID-TLV as its identifier. 969 That said this TLV is coded differently for shared and on shared 970 case. 972 o In the case of a replication segment being shared, the Tree-ID in 973 the SR-P2MP-POLICY Identifier TLV is the replication-id of the 974 replication segment and Root = 0, Instance-Id = 0. When downloading a 975 shared replication segment from PCE through a PcInitiate message, the 976 SR-P2MP-POLICY Identifier TLV is all 0, and on the report back from 977 PCC, PCC generates PLSP-ID, Replication-id (Tree-id field will be 978 populated with replication-id). Instance-id will be 0. 980 4.5.3. Label action rules in replicating segment 982 If a node is ingress, transit, leaf or Bud, is implicitly identified 983 by the following information in the replication segment: 985 - If there is a next-hop with local loop back it is a Leaf 987 - If there is a next-hop with local loop back and a next-hop with 988 swap downstream it is a Bud 990 - If incoming label and next-hop is downstream node loop back ip and 991 there is p2mp policy then Ingress 993 - If incoming label and next-hop is downstream node loop back ip and 994 no p2mp policy then it is a Transit 996 5. Examples of PCEP messages between PCE and PCEP 998 +-------+ 999 | | 1000 +-------+ |LEAF D | +-------+ 1001 |Rep | | | | PCE | 1002 |Transit| +-------+ +-------+ 1003 +------|C | 1004 | Non | | +-------+ 1005 | Rep +-------+ | | 1006 | Transit| |LEAF E | 1007 +------| B | | | 1008 |Rep +--------+ +-------+ 1009 |ROOT | 1010 |A | 1011 +--------+ 1013 5.1. PCE Initiate and PCC Leaves Update 1015 For a PCE Initiate P2MP Policy a sample PC Initiate message from the 1016 PCE to the root is provided below. This is on reception of a P2MP 1017 Policy creation on the PCE: 1019 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 1020 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Flags = 0 | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | SRP-ID-number = 1 | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | | PST = TBD | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Type=17 | Length= | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | symbolic path name | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Type=TBD | Length | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | Root = A | 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Tree-ID = 0 | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Instance-id = 0 | Reserved | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Reserved | Flags |0| 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Association type= SR-P2MP-PAG | Association ID = z | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | IPv4 Association Source = | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Type | Length | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Root = A | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | TREE-ID = 0 | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Type | Length | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 |ProtOrigin 10 | Reserved | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Originator ASN | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | | 1069 | Originator Address = | 1070 | | 1071 | | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Discriminator = 1 | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Type | Length | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Preference = 100 | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 On Response to the above initiate message, PCC generates a Tree-ID, 1081 PLSP-ID, Instance-id for the candidate path identified by the 1082 candidate path identifier TLV and sends a report back to PCE. If 1083 leaves are discovered by the PCC at that point of time, that is 1084 communicated to the PCE in the same report message using the object in the Report message. 1087 For PCC initiated P2MP Policy, if the Root wants to send a P2MP 1088 request to the PCE, the same is achieved through Root sending a PC 1089 Report to PCE indicating a P2MP Request. 1091 Sample Report generated by the Root to the PCE for P2MP Request 1092 received from the Root Node: 1094 Sample Report generated by the Root to the PCE for Leaf Add 1096 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 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Flags = 0 | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | SRP-ID-number = 1 | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | | PST = TBD | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 1107 | PLSP-ID = 1 | A:1,D:1,N:1 | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Type=17 | Length= | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | symbolic path name | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Type=TBD | Length | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Root = A | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Tree-ID = Y | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Instance-ID =L1 | Reserved | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 1123 | Leaf type =1 | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Source IPv4 address = A | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Destination IPv4 address = D | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Destination IPv4 address = E | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 Presence of an association object with Tree-ID = 0 in the Initiate 1133 message, is an indication to the node to create a P2MP policy and 1134 associated candidate path. An initiate message without an association 1135 object, is an indication to the node to download the replication 1136 segment (forwarding instructions). 1138 5.2. PCE P2MP LSP Calculation and Replication Segment download 1139 Once the PC Report of leaves is sent to the PCE, PCE computes path 1140 to the leaf and would send a PC Initiate/ PC Update to the connected 1141 PCC's across the path to the leaf along with TE-PATH-BINDING TLV and 1142 label download information using ERO object, ERO-attribute object and 1143 SR-ERO sub-objects. 1145 For example, say PCE computed 2 candidate paths that 1146 needs to be downloaded on the transit and root node, sample messages 1147 are explained below. 1149 For cp1 -> on the root it will be a PC Update message sent from PCE, 1150 updating the empty candidate path it had sent earlier when it had 1151 intimated the root about the it had known from NMS. 1152 For cp2 -> on the root it will be a PC Initiate messages sent from 1153 PCE, initiating the new candidate path and associating it to the same 1154 SR-P2MP policy. 1156 On the transit - for cp1, and cp2 since PCE is initiating both newly 1157 on those nodes, PCE will send one PC Initiate message with two LSP 1158 objects, defining each candidate path. Or PCE can send separate PC 1159 Initiate message for every candidate path. As defined in draft-barth- 1160 pce-segment-routing-policy-cp-02 1162 A sample PC Update message sent to the Root for cp1 is as follows: 1164 Note Root is connected to the next replication Segment C via non 1165 replication segment B. Hence a segment List is used. 1167 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 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Flags = 0 | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | SRP-ID-number = 2 | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | | PST = TBD | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 1178 | PLSP-ID = 1 | A:1,D:1,N:1,C:0 | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Type=17 | Length= | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | symbolic path name | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Type=TBD | Length | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Root =A | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Tree-ID = Y | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Instance-ID = L1 | Reserved | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Type | Length | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | BT= 0 | Reserved | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | Binding value = incoming replication SID | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Flags | Oper| 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Type | Length | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 |1|0|0| Reserved | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | ERO-path Id = 1 | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | Back-up ero path id = 0 | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | SID = b | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | ipv4-address = NH | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | SID = c | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | ipv4-address = NH | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 A sample PC Initiate message to the Root for cp2 is as follows: 1225 Note cp2 can be either on the same path as cp1 or on a seprate 1226 path, assuming that there is a 2nd path connecting 1227 A to B to C 1229 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 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Flags = 0 | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | SRP-ID-number = 3 | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | | PST = TBD | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 1240 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Type=17 | Length= | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | symbolic path name | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Type=TBD | Length | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Root = A | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | Tree-ID = Y | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Instance-ID = 0 | reserved | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Type | Length | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | BT | Reserved | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Binding Value= incoming replication sid | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 1262 | Reserved | Flags |0| 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Association type= SR-P2MP-PAG | Association ID = z | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | IPv4 Association Source = | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Type | Length | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Root = A | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | TREE-ID = Y | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Type | Length | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 |ProtOrigin 10 | Reserved | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Originator ASN | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | | 1281 | Originator Address = | 1282 | | 1283 | | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Discriminator = 2 | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Type | Length | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Preference = 100 | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Flags | Oper| 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Type | Length | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 |1|0|0| Reserved | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | ERO-path Id = 2 | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Back-up ero path id = 0 | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | SID = b1 | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | ipv4-address = NH2 | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | SID = c1 | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | ipv4-address = NH2 | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 A sample PC Initiate message to the transit replication policy C 1318 for cp1 1319 Lets assume C is connected to D via 2 fiber hence Fast Reroute 1320 is possible: 1322 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 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Flags = 0 | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | SRP-ID-number = 4 | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | | PST = TBD | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 1333 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Type=17 | Length= | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | symbolic path name | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Type=TBD | Length | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Root=A | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Tree-ID = Y | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Instance-ID =L1 | Reserved | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Type | Length | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | BT | Reserved | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Binding Value= incoming replication sid = c1 | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 1355 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Flags | Oper| 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 | Type | Length | 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 |1|0|1| Reserved | 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | ERO-path Id = 3 | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | Back-up ero path id = 4 | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | SID = d | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | ipv4-address = NHD1 | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Flags | Oper| 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Type | Length | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 |0|1|0| Reserved | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | ERO-path Id = 4 | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Back-up ero path id = 0 | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | SID = d protect | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | ipv4-address = NHD2 | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 1395 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | Flags | Oper| 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | Type | Length | 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 |1|0|1| Reserved | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | ERO-path Id = 5 | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Back-up ero path id = 6 | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | SID = e | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | ipv4-address = NHE1 | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Flags | Oper| 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Type | Length | 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 |0|1|0| Reserved | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | ERO-path Id = 6 | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Back-up ero path id = 0 | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 |L| Type=36 | Length | NT= 1| Flags |0|0|0|0| 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | SID = e protect | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | ipv4-address = NHE2 | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 5.3. PCC Rpt for PCE Update and Init Messages 1436 In response to the PC Initiate message / PC Update message , PCC will 1437 send PC Reports to PCE indicating the state of the label download for 1438 that particular candidate path. PCC's will generate PLSP-ID for newly 1439 initiated candidate path. 1441 Here is an PC Report Message send for the root PCE Init message with 1442 cp2 on the root. 1444 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 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Flags = 0 | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | SRP-ID-number = 2 | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | | PST = TBD | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 1455 | PLSP-ID = 1 | O:1,A:1,D:1,N:1,C:1| 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Type=17 | Length= | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | symbolic path name | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Type=TBD | Length | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Root | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Tree-ID | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Instance-ID = L1 | Reserved | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Flags |O =Up| 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | Type | Length | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 |1|0|1| Reserved | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | ERO-path Id = 5 | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | Back-up ero path id = 6 | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 6. Tree Deletion 1485 To delete the entire tree (P2MP LSP) , Root send a PCRpt message with 1486 the R bit of the LSP object set and all the fields of the SR-P2MP- 1487 LSP-ID TLV set to 0(indicating to remove all state associated with 1488 this P2MP tunnel). The controller in response sends a PCInitiate 1489 message with R bit in the SRP object SET to all nodes along the path 1490 to indicate deletion of a label entry. 1492 7. Fragmentation 1494 The Fragmentation bit in the LSP object (F bit) can be used to 1495 indicate a fragmented PCEP message. 1497 8. Example workflow 1499 As per slides submitted in IETF 105. 1501 6. IANA Considerations 1503 This document contains no actions for IANA. 1505 7. Security Considerations 1507 TBD 1509 8. References 1511 8.1. Normative References 1513 8.2. Informative References 1515 [sr-p2mp-policy] D. Yoyer, Ed., C. Hassen, K. Gillis, C. Filsfils, R. 1516 Parekh, H.Bidgoli, "SR Replication Policy for P2MP Service Delivery", 1517 draft-voyer-spring-sr-p2mp-policy-01, April 2019. 1519 7. Acknowledgments 1521 The authors would like to thank Tanmoy Kundu and Stone Andrew at 1522 Nokia for Thier feedback and major contribution to this draft. 1524 Authors' Addresses 1526 Hooman Bidgoli 1527 Nokia 1528 600 March Rd. 1529 Ottawa, Ontario K2K 2E6 1530 Canada 1532 Email: hooman.bidgoli@nokia.com 1534 Daniel Voyer 1535 Bell Canada 1536 Montreal 1537 CA 1538 Email: daniel.voyer@bell.ca 1540 Siva Sivabalan 1541 Cisco Systems 1542 Ottawa 1543 Canada 1545 Email: msiva@cisco.com 1547 Jayant Kotalwar 1548 Nokia 1549 380 N Bernardo Ave, 1550 Mountain View, CA 94043 1551 US 1553 Email: jayant.kotalwar@nokia.com 1555 Saranya Rajarathinam 1556 Nokia 1557 380 N Bernardo Ave, 1558 Mountain View, CA 94043 1559 US 1561 Email: saranya.rajarathinam@nokia.com 1563 Takre Saad 1564 Juniper 1565 Ottawa 1566 Canada 1568 tsaad@juniper.net