idnits 2.17.1 draft-hsd-pce-sr-p2mp-policy-00.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 5 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 (July 6, 2019) is 1755 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? 'RFC2119' on line 171 looks like a reference -- Missing reference section? 'RFC6513' on line 342 looks like a reference -- Missing reference section? 'RFC8231' on line 776 looks like a reference -- Missing reference section? 'RFC8236' on line 267 looks like a reference -- Missing reference section? 'RFC 3209' on line 277 looks like a reference -- Missing reference section? 'RFC8306' on line 959 looks like a reference -- Missing reference section? 'RFC3209' on line 440 looks like a reference -- Missing reference section? 'RFC6514' on line 342 looks like a reference -- Missing reference section? 'I-D.ietf-spring-segment-routing-policy' on line 743 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 10 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. 12 Expires: January 7, 2020 July 6, 2019 14 PCEP extensions for p2mp sr policy 15 draft-hsd-pce-sr-p2mp-policy-00 17 Abstract 19 SR P2MP policies are set of policies that enable architecture for 20 P2MP service delivery. 22 This document specifies extensions to the Path Computation Element 23 Communication Protocol (PCEP) that allow a stateful PCE to compute 24 and initiate P2MP paths from a Root to a set of Leaves. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." The list 40 of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on October 8, 2017. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions used in this document . . . . . . . . . . . . . . . 4 66 3. Overview of PCEP Operation in SR P2MP Network . . . . . . . . . 4 67 3.1. High level view of a P2MP Policy Objects . . . . . . . . . 5 68 3.1.1. Existing drafts used in defining the P2MP Policy . . . 6 69 3.1.2. P2MP Identification . . . . . . . . . . . . . . . . . . 7 70 3.2 High-Level Procedures for P2MP SR LSP Instantiation . . . . 7 71 3.2.1 MVPN procedures . . . . . . . . . . . . . . . . . . . . 8 72 3.2.2. Global Optimization for P2MP LSPs . . . . . . . . . . . 10 73 3.2.3. Fast Reroute . . . . . . . . . . . . . . . . . . . . . 10 74 3.2.3. Connecting Replication Policy via Segment List . . . . 11 75 3.3. SR P2MP New TLVs and Objects . . . . . . . . . . . . . . . 12 76 4. Object Format . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.1. Open Message and Capability Exchange . . . . . . . . . . . 12 78 4.2. Symbolic Name in PCInitiate message from PCC . . . . . . . 13 79 4.3. Replication policy . . . . . . . . . . . . . . . . . . . . 14 80 4.3.1 P2MP Policy Association Group . . . . . . . . . . . . . 14 81 4.3.1.1 P2MP SR Policy Association Group Policy 82 Identifiers TLV . . . . . . . . . . . . . . . . . . 14 83 4.3.1.2 P2MP SR Policy Association Group Candidate Path 84 Identifiers TLV . . . . . . . . . . . . . . . . . . 15 85 4.3.1.3 P2MP SR Policy Association Group Candidate Path 86 Attributes TLV . . . . . . . . . . . . . . . . . . . 16 87 4.4. PCEP Message Exchanges . . . . . . . . . . . . . . . . . . 17 88 4.4.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV . . . . . 17 89 4.5. SR-P2MP-CCI Object . . . . . . . . . . . . . . . . . . . . 18 90 4.5.1 Optional IP-Address TLVs . . . . . . . . . . . . . . . . 19 91 4.6. Root PCE Report message . . . . . . . . . . . . . . . . . . 21 92 4.6.1 END-POINTS Objects . . . . . . . . . . . . . . . . . . . 21 93 5. Examples of PCEP messages between PCE and PCEP . . . . . . . . 23 94 5.1. PCE Initiate and PCC Leaves Update . . . . . . . . . . . . 23 95 5.2. PCE P2MP LSP Calculation and Replication Policy download . 27 96 5.3. PCC Rpt for PCE Update and Init Messages . . . . . . . . . 35 97 6. Tree Deletion . . . . . . . . . . . . . . . . . . . . . . . . . 37 98 7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . 37 99 8. Example workflow . . . . . . . . . . . . . . . . . . . . . . . 37 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 37 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 103 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 104 8.2. Informative References . . . . . . . . . . . . . . . . . . 38 105 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 38 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 108 1. Introduction 110 The draft [draft-voyer-spring-sr-p2mp-policy] defines a variant of 111 the SR Policy [I-D. ietf-spring-segment-routing-policy] for 112 constructing a P2MP segment to support multicast service delivery. 114 A Point-to-Multipoint (P2MP) segment connects a Root node to a set of 115 Leaf nodes in a Segment Routing Domain. We also define a Replication 116 segment, which corresponds to the state of a P2MP segment on a 117 particular node. 119 A P2MP segment consists of replication segments for the root, leaves 120 and optionally intermediate replication nodes. 122 A replication segment defines the forwarding behavior on a particular 123 node on a particular P2MP segment. 125 For a P2MP segment, a controller may be used to compute paths from a 126 Root node to a set of Leaf nodes, optionally via a set of replication 127 nodes. A packet is replicated at the root node and optionally on 128 Replication nodes towards each Leaf node. 130 We define two types of a P2MP segment: Spray and Replication. 132 A Point-to-Multipoint service delivery could be via Ingress 133 Replication (aka Spray in some SR context), i.e., the root unicasts 134 individual copies of traffic to each leaf. The corresponding P2MP 135 segment consists of replication segments only for the root and the 136 leaves. 138 A Point-to-Multipoint service delivery could also be via Downstream 139 Replication (aka TreeSID in some SR context), i.e., the root and some 140 downstream replication nodes replicate the traffic along the way as 141 it traverses closer to the leaves. 143 Notice that Spray is actually a special form of TreeSID. Also notice 144 that, the explicit path from the root or a replication node to a leaf 145 or a downstream replication node can optionally be partially or 146 completely specified by the controller PCE or determined locally via 147 static configuration. 149 A PCE could computes a tree from a Root node to a set of Leaf nodes 150 via a set of Replication nodes. A packet is replicated at the Root 151 node and on Replication nodes towards each Leaf node. It should be 152 noted that two replication nodes can be connected directly, or they 153 can be connected via unicast SR segment or a segment list. 155 The leaves and the root can be explicitly configured on the PCE or 156 PCC can updates the PCE with the information of the discovered root 157 and leaves. As an example Multicast protocols like mvpn procedures or 158 pim can be used to discovery the leaves and roots on the PCC and 159 update the PCE with these relevant information. The controller can 160 calculate the P2MP Segment based on these info. 162 In all of above cases a set of new PCEP object and TLVs are needed to 163 update and instantiate the P2MP tree. This draft explains the 164 procedure needed to instantiate a P2MP TreeSID. 166 2. Conventions used in this document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119]. 172 3. Overview of PCEP Operation in SR P2MP Network 174 For a P2MP SR policy, a PCE calculates a P2MP tree and programs the 175 Root, Replication and Leaf nodes with information needed to forward a 176 multicast stream from the root to a set of leaves. The PCE discovers 177 the Root and the set of the Leaves via manual configuration on the 178 PCE. On other hand the PCC (Root of the P2MP Tree) can providing the 179 PCE with the relevant information by discovering the leaves via mvpn 180 procedures or pim . 182 After discovering the Root and Leaves and computing the MPLS P2MP 183 Tree and identifying the Replication routers, the PCE programs the 184 PCCs with relevant information needed to create a P2MP Tree. 186 As per draft draft-voyer-spring-sr-p2mp-policy a P2MP Policy is 187 defined by a root and set of leaves. A P2MP Policy contains 188 replication policies. A replication policy is set of forwarding 189 instructions on a specific node. As an example the push information 190 on the Root node or swap and outgoing interface information on the 191 transit nodes or pop information on the bud and leaves nodes. In 192 addition since a P2MP policy is a variant of SR policy it uses the 193 same concept as draft draft-darth-pce-sement-routing-policy-cp. In 194 short a replication policy uses a collection of SR P2MP Candidate 195 paths. The candidate paths are computed by the PCE and can be used 196 for P2MP LSP redundancy. In short each candidate path in the 197 replication policy is a unique P2MP lsp. 199 PCE could also calculate and download additional information such as 200 next-hops for link/node protection or initiate a make-before-brake 201 procedure for global Path optimization. 203 3.1. High level view of a P2MP Policy Objects 205 -SR P2MP Policy: 207 -Is a policy on PCE which contains information about: 209 - root node of the P2MP Segment 211 - leaf nodes of the P2MP Segment 213 - optionally constrains used to build the tree from leaf nodes to 214 the root node. 216 - Tree-ID, which is a unique identifier of the P2MP tree on the 217 root 219 -Replication Policy: 221 - Is the forwarding information needed on each node and is 222 contained by P2MP policy. It is identified via: 224 - Its node-ID, the node that replication policy belongs to. 226 - The root of the P2MP Tree 228 - Tree-ID, which is a unique identifier of the P2MP Tree on the 229 root. As an example the could be MP-BGP opaque value as per 230 [RFC6513] 232 - It also contains a set of Candidate paths for P2MP tree 233 redundancy 235 -Candidate Path: 237 - Is used for P2MP Tree redundancy where the P2MP LSP with the 238 highest preference is the active LSP 240 - It option can contain up to two P2MP LSP global optimization 241 procedures, each identified with their own LSP-ID (i.e. make before 242 break) 244 - It also contains the forwarding information for the P2MP LSPs, 245 these forwarding information can be a replication SID or a segment 246 list. 248 3.1.1. Existing drafts used in defining the P2MP Policy 250 P2MP Policy reuses current drafts and PCEP objects to identify the 251 root and the leaves on the P2MP Segment and update the PCE with these 252 information, and also to have PCE initiate and update P2MP 253 Replication Policies on a the PCC. 255 In addition this draft will introduced new TLVs and Objects specific 256 to a P2MP Policy. 258 This draft reuses the following pcep drafts: 260 - [RFC8231] The bases for a stateful PCE, and reuses the following 261 objects or a variant of them 263 265 267 - [RFC8236] P2MP capabilities advertisement 269 Also a variation of the P2MP LSP Identifier specified in above RFC 271 - [draft-barth-pce-segment-routing-policy-cp-02] Candidate paths for 272 P2MP Policy is used for Tree Redundancy. As an example a P2MP Policy 273 can have multiple candidate paths each protecting the primary 274 candidate path. The active path is chosen via the precedence of the 275 candidate path. 277 - [RFC 3209] defines the LSP-ID, LSP-ID is used for global 278 optimization of a candidate path with in a P2MP policy. Each 279 Candidate path can have 2 sub-lsps (LSP-IDs) for MBB and global 280 optimization procedures. 282 - [draft-ietf-spring-segment-routing-policy] segment-list, used for 283 connecting two non-adjacent replication policy via a unicast binding 284 SID or Segment-list. 286 - [draft-ietf-pce-pcep-extension-for-pce-controller] a variant of CCI 287 Object, used for downloading the replication policy forwarding 288 instructions. These instructions can be incoming label and set of 289 outgoing labels or fast reroute procedures or even downloading of a 290 segment-list connecting two non-adjacent replication policy. 292 - [RFC8306] P2MP End Point objects, used for the PCC to update the 293 PCE with discovered Leaves. 295 It should be noted that the [draft-dhs-spring-sr-p2mp-policy-yang] 296 can provide farther details of the high level P2MP Policy Model. 298 3.1.2. P2MP Identification 300 The key to identify a P2MP LSP is in LSP object and is as follow: 302 PLSP-ID: RFC 8231, is assigned by PCC and is unique per candidate 303 path. It is constant for the lifetime of a PCEP session. Since PLSP- 304 ID is unique per LSP, Stand-by P2MP LSPs will be downloaded with a 305 new PLSP-ID. It should be noted a stand-by LSP is a LSP to protect 306 the primary LSP and can be setup in parallel to the primary LSP. 307 These stand-by LSPs are identified by the candidate path. 309 LSP-ID: LSP ID Identifier as defined in rfc 3209, and is used for 310 global optimization of a P2MP LSP (Candidate path) 312 Tree-ID: is equivalent to Tunnel Identifier color which identifies a 313 unique P2MP segment at a ROOT and is advertised via the PTA in the 314 BGP AD route. 316 Root: is equivalent to the first MPLS node on the path, as per 317 [RFC3209], Section 4.6.2.1 319 Note that the Tree-ID, Root and LSP-ID are part of a new SR-P2MP- 320 LSP_Identifier TLV which will be identified in this draft. 322 3.2 High-Level Procedures for P2MP SR LSP Instantiation 324 A P2MP policy is consistent of Root and a set of Leaves and as such a 325 set of replication policies for each node within the path of the P2MP 326 segment. As mentioned previously a replication policy is a set of 327 forwarding rules used on root, transit nodes and leaves. 329 The Root and Leaves can be discovered via many methods. 331 - They can be configured and identified on a controller 333 - They can be configured on the root node PCC and the root updates 334 the PCE with this information 336 - They can be discovered via Multicast mechanisms like MVPN 337 procedures or protocols like PIM. 339 3.2.1 MVPN procedures 341 In case of MVPN there can be pcc-initiated or pce-initiated p2mp 342 policy. In either case MVPN procedures [RFC6513, RFC6514] are used to 343 discover the leaves on PCC and report them up to the PCE. 345 1. PCE-initiated Procedure : 347 PCE is informed of the P2MP request through it's API or configuration 348 mechanism to instantiate a P2MP tunnel. PCE will initiate the P2MP 349 LSP for the request, by sending a PC Initiate message to the Root. 350 The above PC Initiate message to the Root will contain the following 351 information. PLSP-ID = 0, LSP-ID (SR-P2MP-LSP-ID-TLV defined in this 352 document), symbolic path name, association object (association-id 353 defined by PCE, association-type SR-P2MP-PAG), policy identifier 354 TLV(root and tree-id(0)), candidate path identifier tlv(protocol, 355 origin, discriminator (32 bit value, which needs to be generated by 356 PCE, and uniquely identifies a candidate path. This will increment 357 for every candidate path and starts from 0)). The CC-ID list will be 358 empty since PCE has not discovered any leaves yet. Root in response 359 to the PC Initiate message will generate PLSP-ID and tree-id for the 360 LSP Identifier and the candidate path that was downloaded by the PCE 361 for this replication policy. PCC reports back the PLSP-ID, LSP_ID(SR- 362 P2MP-LSP-ID-TLV defined in this document) and tree-id, and any leaves 363 that were discovered until then to PCE. PCE on discovering leaves 364 from the root, will compute the path to the leaves and downloads the 365 label-information by sending PC Initiate message on the transit and 366 leaf nodes connected to PCE and sends a PC Update message to the 367 Root. The PC Initiate message to the transit and leaf is like the PC 368 Initiate message that was sent to the Root, but the Tree-ID will not 369 be 0 and will be the Tree-ID that the Root communicated through the 370 Pc Report. 372 2. PCC Initiated Procedure: 374 Root sends a PC Report to PCE including the root, tree-id, PLSP-ID, 375 LSP-ID(SR-P2MP-LSP-ID-TLV defined in this document), symbolic-path- 376 name, and any leaves learnt until then. PCE on receiving this report, 377 will compute the path and download label information on the leaf and 378 transit using PC Initiate message as PLSP-ID = 0, symbolic path name, 379 association object (association-id defined by PCE, association-type 380 SR-P2MP-PAG), policy identifier TLV(root and tree-id), candidate path 381 identifier tlv(protocol, origin, discriminator (32 bit value, which 382 needs to be generated by PCE, and uniquely identifies a candidate 383 path. This will increment for every candidate path and starts from 384 0), CC-ID list of label downloads. On the root it will be an update 385 message containing the PLSP-ID and other information that was earlier 386 communicated by the Root. The association-ID used in the Root, 387 transit and leaves will be the same for all candidate paths. Transit 388 and Leaf on receiving the Initiate message will generate a PLSP-ID 389 and report the status of the label downloads. 391 Beyond this, procedures for (1) and (2) are same. 393 [draft-ietf-pce-pcep-extension-for-pce-controller] indicates the 394 PLSP-ID used in PC Initiate messages is the PLSP-ID defined at the 395 ingress node, to allow correlation between transit instructions and 396 the ingress LSP entity. For Replication Policy,as defined in the 397 above procedures, other identifiers allow correlation of transit to 398 root/ingress instructions to the downstream so the same PLSP-ID is 399 not required. PLSP-ID's are individually generated by every PCC in 400 the P2MP path. 402 Any new leaves discovered from here on, are reported to PCE using the 403 PLSP-ID of the active candidate path. If these leaves are discovered 404 on routers that are part of the P2MP LSP path, then PC Update is sent 405 from PCE to necessary PCCs (LEAVES, TRANSIT or ROOT) with the LSPs 406 PLSP-ID. If the new leaves are discovered on routers that are not 407 part of the P2MP Tree yet, then a PC Initiate message is sent down 408 with PLSP-ID=0. 410 Any new candidate path is downloaded by PCE to its connected Root, 411 transit and leaves by sending a PC Initiate message to them. Every 412 candidate path is a different P2MP LSP which gets a unique PLSP-ID. 413 Multiple candidate path are associated to the same Replication policy 414 and each used as a redundant P2MP LSP. 416 If a candidate path needs to be removed, PCE sends PC Initiate 417 message, setting the R-flag in the LSP object and R bit in the SRP- 418 object. To remove the entire P2MP-LSP, PCE needs to send PC Initiate 419 remove messages for every candidate path of the SR-P2MP-POLICY to all 420 the PCE connected nodes along the P2MP-LSP path. The R bit in the LSP 421 Object as defined in rfc8231, refers to the removal of the LSP as 422 identified by the SR-P2MP-LSP-ID-TLV (defined in this document). An 423 all zero (SR-P2MP-LSP-ID-TLV defines to remove all the state of the 424 corresponding PLSP-ID. 426 A candidate path is made active based on the preference of the path. 427 If the Root gets paths one from the PCE and one from the CLI, and 428 based on its tie-breaking rules, if it selects the CLI path, it will 429 send a report to PCE for the PCE path indicating the status of label- 430 download and sets operational bit of the LSP object to UP and Not 431 Active . At any instance, only one path will be active. 433 3.2.2. Global Optimization for P2MP LSPs 435 When a P2MP LSP needs to be optimized for any reason (i.e. it is 436 taking a FRR Path or new routers are added to the network) a global 437 optimization is possible. Note that optimization works per candidate 438 path. Each candidate path is capable of global optimization. To do so 439 each candidate path contains two P2MP LSP, each P2MP LSP is 440 identified via the LSP-ID [RFC3209]. After calculating an optimized 441 P2MP LSP path the PCE will program the candidate path with a 2nd LSP- 442 ID and its set of CCI instructions. After the optimized LSP is 443 downloaded a MBB procedure is performed and the previous instance of 444 the P2MP LSP is deleted and removed from the corresponding PCCs. The 445 globally optimized LSP is instantiated via the PCInitiate message. 446 The PLSP-ID of this optimized LSP is same as the Current LSP which is 447 being optimized, this is because both LSPs belong to the same 448 candidate path. That said the LSP-ID of the optimize LSP is uniquely 449 assigned by PCE and is different from that of the current LSP which 450 is being optimized. In short, the LSP-ID uniquely identifies sub- 451 instances of an LSP for optimization with in that candidate path. 452 After the optimized LSP has been downloaded and verified via PCC 453 PCRpt message, the MBB procedure can be performed to switch between 454 the two instances of the LSP. The previous instance will be removed 455 from PCCs. 457 3.2.3. Fast Reroute 459 Currently this draft identifies the Facility FRR procedures. In 460 addition, only LINK Protection procedures are defined. How the 461 Facility Path is built and instantiated is beyond the scope of this 462 document. 464 R 465 | | 466 T 467 | 468 --- 469 | | 470 L1 L2 472 Figure 1 474 R---F1 475 | | 476 T---F2 477 | 478 --- 479 | | 480 L1 L2 482 Figure 2 484 As an example, the bypass path (unicast bypass) between the PLR and 485 MP can be constructed via SR. The PCE needs to only update the PLR 486 PCC with bypass path outgoing label and nexthop information, also PCE 487 needs to update the MP PCC with bypass path ILM information. This 488 information is presented via a P bit in the optional IPv4/IPv6- 489 Address object as per upcoming section. 491 If one to one FRR is needed, then a second flag O should be defined 492 in the IPv4/IPv6-Address object in future. 494 As an example, in figure 1 the detour path between R and T is the 2nd 495 fiber between these nodes. As such the bypass path could be setup on 496 the 2nd fiber using treeSID procedures. That said in figure 2 the 497 bypass path is traversing multiple nodes and this example a unicast 498 SR path might be ideal for setting up the detour path. The PCE can 499 download the prefix SID for F2 as a bypass path for R-T to R. 500 Downloading the prefix SID for F2 will ensure an LFA detour for R-T. 501 In addition, PHP procedure and implicit null label on the bypass path 502 can be implemented to reduce the PCE programming on the MP PCC. 504 3.2.3. Connecting Replication Policy via Segment List 506 There could be nodes between two replication segment that do not 507 understand P2MP Policy or Replication policy. It is possible to 508 connected two non-adjacent Replication segment via a unicast binding 509 SID or segment-list. 511 Replication policy does support the concept of a segment-list. A list 512 of unicast SIDs (Binding SID, Adjacency SIDs or Node SIDs) can be 513 programmed on a Replication segment via the P2MP CCI object. 515 3.3. SR P2MP New TLVs and Objects 517 A new object is defined for the controller to specify 518 the forwarding instructions (label instructions) of the replication 519 policy. 521 A new Association Type (P2MP SR Policy) is defined. Also a SR-P2MP 522 policy identifiers TLV is defined to communicate the SR-P2MP policy 523 and candidate path information. 525 A new P2MP-LSP identifier TLV is included to indicate the P2MP 526 identifiers (Root, Tree-ID, LSP-ID). 528 The above new objects and TLV's defined in this document can be 529 included in PcReport, PcInitiate and PcUpdate messages. 531 It should be noted that every PcReport, PcInitiate and PCUPdate 532 messages will contain full list of the Leaves and label and 533 forwarding information that is needed to build the P2MP LSP. In short 534 the PCC or PCE should never send the delta information related to the 535 new leaves that need to be added or updated. This is necessary to 536 ensure that PCE or any new PCE is in sync with the PCC. 538 As such when a PcReport, PcInitiate and PCUPdate messages is send via 539 PCEP it maintains the previous instruction CC-IDs and create new CC- 540 ID for the new instruction. This means the CC-IDs are maintained for 541 each specific forwarding and label instructions until these 542 instructions are deleted. For example, When the first leaf is added 543 PCC gets instructions, CC-ID A on a particular transit node. On a 544 second leaf add, according to the path calculated, PCE might just 545 append the existing instruction A with B. This is done by sending a 546 PC Update with CC-ID A and B. 548 4. Object Format 550 4.1. Open Message and Capability Exchange 552 Format of the open object 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Ver | Flags | Keepalive | DeadTimer | SID | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | | 558 // Optional TLVs // 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 All the nodes need to establish a PCEP connection with the PCE. 564 During PCEP Initialization Phase, PCEP Speakers advertise their 565 support of PCECC extensions to include the new Path Setup Type 566 [draft-ietf-pce-pcep-extension-for-pce-controller]. Also need to set 567 flags N, M, P in the STATEFUL-PCE-CAPABILITY TLV as defined in 568 [draft-ietf-pce-stateful-pce-p2mp] section capability advertisement. 570 We extend the PCEP OPEN object by defining an optional TLV to 571 indicate the PCE's capability to perform SR-P2MP path computations, 572 New IANA capability type. The inclusion of this TLV in an OPEN object 573 indicates that the sender can perform SR-P2MP path computations. This 574 will be similar to the P2MP-CAPABILITY defined in [RFC8306] section 575 3.1.2 and a new value needs to be defined for P2MP Policy. 577 In addition a Assoc-Type-List TlV as per [draft-ietf-pce-association- 578 group-07] section 3.4 should be send via PCEP open object with 579 following association type 581 +-------------------+----------------------------+------------------+ 582 | Association Type | Association Name | Reference | 583 | Value | | | 584 +-------------------+----------------------------+------------------+ 585 | TBD1 | P2MP SR Policy Association | This document | 586 +-------------------+----------------------------+------------------+ 588 OP-CONF-Assoc-RANGE (Operator-configured Association Range)should not 589 be set for this association type and must be ignored. 591 4.2. Symbolic Name in PCInitiate message from PCC 593 As per RFC8231 section 7.3.2. a Symbolic Path Name TLV should 594 uniquely identify the P2MP path on the PCC. This symbolic path name 595 is a human-readable string that identifies an P2MP LSP in the 596 network. It needs to be constant through the life time of the P2MP 597 path. 599 As an example in the case of P2MP LSP the symbolic name can be Root + 600 Tree-ID of the LSP. The Tree-ID is a unique ID that identifies the 601 P2MP LSP on the Root (Source) as such the combination of Root + Tree- 602 ID will provide the P2MP LSP with a unique identification throughout 603 the network. Depending on the Source IP, IPv4 vs. IPv6, the length of 604 the TLV will vary. 606 4.3. Replication policy As per [draft-voyer-spring-sr-p2mp-policy]a 607 replication policy is build of candidate paths. Each candidate path 608 contains p2mp-cci object which may contain a single outgoing label, 609 in case it is directly connected to another replication segment, or a 610 segment list to connect two non adjacent replication segments. 612 The candidate path and segment list has been described in [draft- 613 ietf-spring-segment-routing-policy]. 615 Candidate paths can be used for P2MP LSP redundancy where the active 616 candidate path in a replication policy has a higher precedence over 617 other candidate paths. 619 As such and as per [draft-barth-pce-segment-routing-policy-cp] 620 section-3.1 each candidate path of a Replication policy appears as a 621 different SR P2MP LSP (identified via a PLSP-ID) in PCEP, it is 622 useful to group together all the candidate paths that belong to the 623 same Replicaton policy. Furthermore, it is useful for the PCE to have 624 knowledge of the P2MP SR candidate path parameters such as Root, 625 Tree-ID, protocol origin,discriminator, and preference. 627 In this draft we define new association group objects to make above 628 possible. 630 4.3.1 P2MP Policy Association Group 632 Two ASSOCIATION object types for IPv4 and IPv6 are defined in [I- 633 D.ietf-pce-association-group]. The ASSOCIATION object includes 634 "Association type" indicating the type of the association group. This 635 document adds a new Association type. 637 Association type = TBD1 "P2MP SR Policy Association Type" for SR 638 Policy Association Group (P2MP SRPAG). 640 As per [draft-barth-pce-segment-routing-policy-cp] section 5, three 641 new TLVs are identified to carry association information: P2MP-SRPAG- 642 POL-ID-TLV, P2MP-SRPAG-CPATH-ID-TLV, P2MP-SRPAG-CPATH-ATTR-TLV 644 4.3.1.1 P2MP SR Policy Association Group Policy Identifiers TLV 646 The P2MP-SRPOLICY-POL-ID TLV is a mandatory TLV for the P2MP-SRPAG 647 Association. Only one P2MP-SRPOLICY-POL-ID TLV can be carried and 648 only the first occurrence is processed and any others MUST be 649 ignored. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Length | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Root | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | TREE-ID | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Type: TBD2 for "P2MP-SRPOLICY-POL-ID" TLV. 663 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 665 Tunnel Sender Address : Can be either IPv4 or IPv6, this value is 666 the value of the root loopback IP. 668 Tree-ID: Tree ID that the replication segment is part of as per 669 draft-ietf-spring-sr-p2mp-policy 671 4.3.1.2 P2MP SR Policy Association Group Candidate Path Identifiers TLV 673 The P2MP-SRPOLICY-CPATH-ID TLV is a mandatory TLV for the P2MPSRPAG 674 Association. Only one P2MP-SRPOLICY-CPATH-ID TLV can be carried and 675 only the first occurrence is processed and any others MUST be 676 ignored. 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type | Length | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Proto. Origin |Flags |A| Reserved | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Originator ASN | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | | 688 | Originator Address | 689 | | 690 | | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Discriminator | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Type: TBD3 for "P2MP-SRPOLICY-CPATH-ID" TLV. 696 Length: 28. 698 Protocol Origin: 8-bit value that encodes the protocol origin, as 699 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 701 Flags : A: This candidate path is active. At any instance only one 702 candidate path can be active. PCC indicates the active candidate path 703 to PCE through this bit. 705 Reserved: MUST be set to zero on transmission and ignored on 706 receipt. 708 Originator ASN: Represented as 4 byte number, part of the 709 originator identifier, as specified in [I-D.ietf-spring-segment- 710 routing-policy] Section 2.4. 712 Originator Address: Represented as 128 bit value where IPv4 713 address are encoded in lowest 32 bits, part of the originator 714 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 715 Section 2.4. 717 Discriminator: 32-bit value that encodes the Discriminator of the 718 candidate path. 720 4.3.1.3 P2MP SR Policy Association Group Candidate Path Attributes TLV 722 The P2MP-SRPOLICY-CPATH-ATTR TLV is an optional TLV for the SRPAG 723 Association. Only one P2MP-SRPOLICY-CPATH-ATTR TLV can be carried 724 and only the first occurrence is processed and any others MUST be 725 ignored. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Type | Length | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Preference | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Type: TBD4 for "P2MP-SRPOLICY-CPATH-ATTR" TLV. 737 Length: 4. 739 Preference: Numerical preference of the candidate path, as 740 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 742 If the TLV is missing, a default preference of 100 as specified in 743 [I-D.ietf-spring-segment-routing-policy] is used. 745 4.4. PCEP Message Exchanges 747 PCE is informed of the P2MP request through manual configuration of 748 root and leaves on the controler or through a Report from Root. On 749 Reception of the P2MP Request, PCE initiates the P2MP LSP on the 750 nodes connected along the P2MP Policy path that are connected to PCE. 751 The object ordering of PC-Init, PC-Update and PC-Report messages are 752 as per [draft-ietf-pce-association-group] section-6.3 (object 753 Encoding in PCEP messages) 755 Format of PC InitiateMessage: 756 757 758 759 760 762 Format of PC Update Message: 763 764 765 766 767 769 Every SR-P2MP-LSP's LSP Object MUST include the SR-P2MP-LSP-ID-TLV 770 (IPV4/IpV6) which is defined by this document as below. This is a 771 variation to the P2MP object defined in [draft-ietf-pce-stateful-pce- 772 p2mp] 774 4.4.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV 776 The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 777 the PLSP-ID to uniquely identify an LSP that is constant for the life 778 time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID 779 identify a candidate path (P2MP-LSP) uniquely with in the Replication 780 policy. 782 The LSP Object MUST include the new SR-P2MP-LSPID-TLV (IPV4/IpV6). 783 This is a variation to the P2MP object defined in [draft-ietf-pce- 784 stateful-pce-p2mp] 786 SR-IPV4-P2MP-LSP-IDENTIFIER TLV: 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type=TBD | Length=10 | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Root | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Tree-ID | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | LSP-ID | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 SR-IPV6-P2MP-LSP-IDENTIFIER TLV : 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Type=TBD | Length=22 | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | | 806 + + 807 | Root | 808 + (16 octets) + 809 | | 810 + + 811 | | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Tree-ID | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | LSP-ID | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 The type (16-bit) of the TLV is TBD (need allocation by IANA). 820 LSP-ID : Contains 16 Bit LSP ID defined in rfc 3209. 822 Root: Source Router IP Address 824 Tree-ID: Unique Identifier of this P2MP LSP on the Root. 826 4.5. SR-P2MP-CCI Object 828 This is a variation of the CC-ID object defined in [draft-ietf-pce- 829 pcep-extension-for-pce-controller] 831 The SR-P2MP-CCI is used to download label instruction to the nodes. 833 It can contain optional IPv4/IPv6 IP-Address TLVs that include 834 forwarding instructions. These instructions includes incoming label 835 (incoming replication SID), or out-going label for adjacent 836 replication policies or Fast Reroute labels. Even segment list labels 837 connecting two non adjacent replication policy can be downloaded via 838 this object. 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | CC-ID | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Reserved | Flags |0| 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 // Optional TLV // 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 851 creates an CC-ID for each instruction, the value is unique within the 852 scope of the PCE and is constant for the lifetime of a PCEP session. 853 The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. Flags: 854 0 - Down - means label download was not successful 1 - Up - 855 means label download was successful 857 4.5.1 Optional IP-Address TLVs 859 These optional IPv4/IPv6 TLVs can be including in P2MP CCI Object for 860 forwarding information download. 862 Optional TLV:IPV4-ADDRESS TLV: 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Type=TBD | Length = 12 | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | SID-List Size |Rsvd | Flag|I|B|S|E|P| 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | IPv4 address | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Interface ID | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 ~ labels ~ 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 SID-List Size: 878 is the number of SIDs in the SID List 880 Flags: 882 I - Incoming Label: 883 If set means In Label, If not set means Out Label. 885 B - Bud Node Label: 886 If set this label is a bud node, the payload needs to be 887 processed locally and also replicated if the S bit is set. In 888 short if B is set then S needs to set also. 890 S - SWAP label: 891 0: If I bit is set and S bit is 0 it means pop the label and if 892 the label's S bit is set do a recursive lookup. 894 1 - If I bit is set and S bit is 1 it means swap this label with 895 out label. 897 P - Protection NextHop 898 0 - Label information is not w.r.t protection next-hop. 900 1 - Label information is w.r.t protection next-hop. 902 Note: P flag is used at the PLR and MP to identify the facility 903 tunnel. 905 E - Protected LTN, This bit is usually set with the an outgoing 906 label, when the outgoing label is protected via a protection 907 nextHop 908 0 - Label information does not have a protection next-hop. 910 1 - Label information has a protection next-hop. 912 IPV4 address and Interface Id: 913 correspond to the next-hop information in case of an OUT Label, and 914 it corresponds to incoming interface information if it is an IN 915 Label. 917 Labels: 918 can be a single label or a list of labels, with the first label in 919 the list being the label on top of the stack and the last label in 920 the list being the label at the bottom of the stack. 922 IPV6-ADDRESS TLV: 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type=TBD | Length = 24 | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | SID-List Size | Flag |I|B|S|E|P| 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | | 931 // IPv6 address (16 bytes) // 932 | | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Interface ID | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 ~ labels ~ 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 UNNUMBERED-IPV4-ID-ADDRESS TLV: 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Type=TBD | Length = 16 | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | SID-List Size | Flag |I|B|S|E|P| 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Node-ID | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Interface ID | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 ~ labels ~ 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 4.6. Root PCE Report message 956 In order for the Root to indicate operations of its 957 leaves(Add/Remove/Modify/DoNotModify), the PC Report message is 958 extended to include P2MP End Point Object which is 959 defined in [RFC8306] 961 The format of the PC Report message is as follow: 962 963 [] 964 965 [] 966 [ | ] 968 4.6.1 END-POINTS Objects 969 IPV4-P2MP END-POINTS: 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Leaf type | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Source IPv4 address | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Destination IPv4 address | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 ~ ... ~ 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Destination IPv4 address | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 IPV6-P2MP END-POINTS: 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Leaf type | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | | 991 | Source IPv6 address (16 bytes) | 992 | | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | | 995 | Destination IPv6 address (16 bytes) | 996 | | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 ~ ... ~ 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | | 1001 | Destination IPv6 address (16 bytes) | 1002 | | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Leaf Types (derived from RFC 8306 section 3.3.2) : 1007 1.New leaves to add (leaf type = 1) 1009 2.Old leaves to remove (leaf type = 2) 1011 3.Old leaves whose path can be modified/reoptimized (leaf type 1012 = 3), Future reserved not used for tree SID as of now. 1014 4.Old leaves whose path must be left unchanged (leaf type = 4) 1016 A given P2MP END-POINTS object gathers the leaves of a given type. 1017 Note that a P2MP report can mix the different types of leaves by 1018 including several P2MP END-POINTS objects. The END-POINTS object body 1019 has a variable length. These are multiples of 4 bytes for IPv4, 1020 multiples of 16 bytes, plus 4 bytes, for IPv6. 1022 5. Examples of PCEP messages between PCE and PCEP 1024 +-------+ 1025 | | 1026 +-------+ |LEAF D | +-------+ 1027 |Rep | | | | PCE | 1028 |Transit| +-------+ +-------+ 1029 +------|C | 1030 | Non | | +-------+ 1031 | Rep +-------+ | | 1032 | Transit| |LEAF E | 1033 +------| B | | | 1034 |Rep +--------+ +-------+ 1035 |ROOT | 1036 |A | 1037 +--------+ 1039 5.1. PCE Initiate and PCC Leaves Update 1041 For a PCE Initiate P2MP Policy a sample PC Initiate message from the 1042 PCE to the root is provided below. This is on reception of a P2MP 1043 Policy creation on the PCE: 1045 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 1046 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | Flags = 0 | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | SRP-ID-number = 1 | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | | PST = TBD | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Type=17 | Length= | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | symbolic path name | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type=TBD | Length | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Root = A | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Tree-ID | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | LSP-ID =L1 | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Reserved | Flags |0| 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Association type= SR-P2MP-PAG | Association ID = z | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | IPv4 Association Source = | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Type | Length | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Root = A | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | TREE-ID = 0 | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Type | Length | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 |ProtOrigin 10 |Flags |0| Reserved | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Originator ASN | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | | 1095 | Originator Address = | 1096 | | 1097 | | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Discriminator = 0 | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Type | Length | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Preference = 100 | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 On Response to the above initiate message, PCC generates a Tree-ID, 1107 PLSP-ID for the candidate path identified by the candidate path 1108 identifier TLV and sends a report back to PCE. If leaves are 1109 discovered by the PCC at that point of time, that is communicated to 1110 the PCE in the same report message using the object 1111 in the Report message. 1113 For PCC initiated P2MP Policy, if the Root wants to send a P2MP 1114 request to the PCE, the same is achieved through Root sending a PC 1115 Report to PCE indicating a P2MP Request. 1117 Sample Report generated by the Root to the PCE for P2MP Request 1118 received from the Root Node: 1120 Sample Report generated by the Root to the PCE for Leaf Add 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Flags = 0 | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | SRP-ID-number = 1 | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | | PST = TBD | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 1133 | PLSP-ID = 1 | A:1,D:1,N:1 | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Type=17 | Length= | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | symbolic path name | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Type=TBD | Length | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Root = A | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | Tree-ID = Y | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | LSP-ID =L1 | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Reserved | Flags |0| 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Association type= SR-P2MP-PAG | Association ID = z | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | IPv4 Association Source = | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Type | Length | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Root = A | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | TREE-ID = Y | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Type | Length | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 |ProtOrigin 10 |Flags |0| Reserved | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Originator ASN | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | | 1168 | Originator Address = | 1169 | | 1170 | | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Discriminator = 0 | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | Type | Length | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | Preference = 100 | 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 1179 | Leaf type =1 | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Source IPv4 address = A | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Destination IPv4 address = D | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Destination IPv4 address = E | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 5.2. PCE P2MP LSP Calculation and Replication Policy download 1190 Once the PC Report of leaves is sent to the PCE, PCE computes path 1191 to the leaf and would send a PC Initiate/ PC Update to the connected 1192 PCC's across the path to the leaf along with association 1193 object(defining association parameters, SR-P2MP policy identifier 1194 TLV, SR-P2MP-candidate path identifier TLV, candidate path attributes 1195 TLV) and label download information (SR-P2MP-CCI). 1197 For example, say PCE computed 2 candidate paths that 1198 needs to be downloaded on the transit and root node, sample messages 1199 are explained below. 1201 For cp1 -> on the root it will be a PC Update message sent from PCE, 1202 updating the empty candidate path it had sent earlier when it had 1203 intimated the root about the it had known from NMS. 1204 For cp2 -> on the root it will be a PC Initiate messages sent from 1205 PCE, initiating the new candidate path and associating it to the same 1206 SR-P2MP policy. 1208 On the transit - for cp1, and cp2 since PCE is initiating both newly 1209 on those nodes, PCE will send one PC Initiate message with two LSP 1210 objects, defining each candidate path. Or PCE can send separate PC 1211 Initiate message for every candidate path. As defined in [draft- 1212 barth-pce-segment-routing-policy-cp] section multiple candidate paths 1214 A sample PC Update message sent to the Root for cp1 is as follows: 1216 Note Root is connected to the next replication Segment C via non 1217 replication segment B. Hence a segment List is used. 1219 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 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Flags = 0 | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | SRP-ID-number = 2 | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | | PST = TBD | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 1230 | PLSP-ID = 1 | A:1,D:1,N:1,C:0 | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Type=17 | Length= | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | symbolic path name | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Type=TBD | Length | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Root =A | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Tree-ID = Y | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | LSP-ID = L1 | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 1246 | Reserved | Flags |0| 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Association type= SR-P2MP-PAG | Association ID = z | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | IPv4 Association Source = | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Type | Length | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Root = A | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | TREE-ID = Y | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Type | Length | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 |ProtOrigin 10 |Flags |0| Reserved | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Originator ASN | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | | 1265 | Originator Address = | 1266 | | 1267 | | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Discriminator = 0 | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Type | Length | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Preference = 100 | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 1276 | CC-ID = z | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Reserved | Flags |0| 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | Type=TBD | Length = 12 | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | sid-list-size = 2 | Rsvd | Flag|0|0|0|0|0| 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | IPv4 address = NH | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Interface ID | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Label= b,c | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 A sample PC Initiate message to the Root for cp2 is as follows: 1292 Note cp2 can be either on the same path as cp1 or on a seprate 1293 path, assuming that there is a 2nd path connecting 1294 A to B to C 1296 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 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Flags = 0 | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | SRP-ID-number = 3 | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | | PST = TBD | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 1307 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Type=17 | Length= | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | symbolic path name | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Type=TBD | Length | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Root | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | Tree-ID | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | LSP-ID =L2 | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 1323 | Reserved | Flags |0| 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Association type= SR-P2MP-PAG | Association ID = z | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | IPv4 Association Source = | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Type | Length | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Root = A | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | TREE-ID = Y | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Type | Length | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 |ProtOrigin 10 |Flags |0| Reserved | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Originator ASN | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | | 1342 | Originator Address = | 1343 | | 1344 | | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Discriminator = 1 | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Type | Length | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Preference = 100 | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 1353 | CC-ID = z10 | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 | Reserved | Flags |0| 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Type=TBD | Length = 12 | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | sid-list-size = 2 | Rsvd | Flag|0|0|0|0|0| 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | IPv4 address = NH2 | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Interface ID | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Label= c1, b1 | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 A sample PC Initiate message to the transit replication policy C 1369 for cp1 1370 Lets assume C is connected to D and C via 2 fiber hence Fast Reroute 1371 is possible: 1373 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 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Flags = 0 | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | SRP-ID-number = 4 | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | | PST = TBD | 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 1384 | PLSP-ID = 0 | A:1,D:1,N:1,C:1 | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Type=17 | Length= | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | symbolic path name | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Type=TBD | Length | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Root=A | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Tree-ID | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | LSP-ID =L1 | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 1400 | Reserved | Flags |0| 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Association type= SR-P2MP-PAG | Association ID = z | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | IPv4 Association Source = | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Type | Length | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | Root = A | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | TREE-ID | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Type | Length | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 |ProtOrigin 10 |Flags |0| Reserved | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 | Originator ASN | 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | | 1419 | Originator Address = | 1420 | | 1421 | | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Discriminator = 0 | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Type | Length | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Preference = 100 | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 1430 | CC-ID = z20 | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Reserved | Flags |0| 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | Type=TBD | Length = 12 | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | sid-list-size = 1 | Rsvd | Flag|E|0|0|0|0| 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | IPv4 address | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | Interface ID | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | Label= c1 | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 1445 | CC-ID = z21 | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Reserved | Flags |0| 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Type=TBD | Length = 12 | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | sid-list-size = 1 | Rsvd | Flag|0|0|S|E|0| 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | IPv4 address =NHD1 | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Interface ID | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | Label= D1 | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 1460 | CC-ID = z22 | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Reserved | Flags |0| 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Type=TBD | Length = 12 | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | sid-list-size = 1 | Rsvd | Flag|0|0|0|0|P| 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | IPv4 address =NHD2 | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | Interface ID | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Label= D1Protect | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 1475 | CC-ID = z23 | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Reserved | Flags |0| 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Type=TBD | Length = 12 | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | sid-list-size = 1 | Rsvd | Flag|0|0|S|E|0| 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | IPv4 address =NHE1 | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Interface ID | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Label= E1 | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 1490 | CC-ID = z24 | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Reserved | Flags |0| 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Type=TBD | Length = 12 | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | sid-list-size = 1 | Rsvd | Flag|0|0|0|0|P| 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | IPv4 address =NHE2 | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Interface ID | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Label= E1Protect | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 5.3. PCC Rpt for PCE Update and Init Messages 1507 In response to the PC Initiate message / PC Update message , PCC will 1508 send PC Reports to PCE indicating the state of the label download for 1509 that particular candidate path. PCC's will generate PLSP-ID for newly 1510 initiated candidate path. 1512 Here is an PC Report Message send for the root PCE Init message with 1513 cp2 on the root. 1515 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 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Flags = 0 | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | SRP-ID-number = 2 | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | | PST = TBD | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 1526 | PLSP-ID = 1 | O:1,A:1,D:1,N:1,C:1| 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Type=17 | Length= | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | symbolic path name | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Type=TBD | Length | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Root | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Tree-ID | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | LSP-ID = L1 | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 1542 | Reserved | Flags |0| 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | Association type= SR-P2MP-PAG | Association ID = z | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | IPv4 Association Source = | 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Type | Length | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Tunnel Sender Address Ipv4 or IPv6 =A | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | TREE-ID = Y | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | Type | Length | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 |ProtOrigin 10 |Flags |1| Reserved | 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Originator ASN | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | | 1561 | Originator Address = | 1562 | | 1563 | | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | Discriminator = 1 | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 | Type | Length | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 | Preference = 100 | 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | CC-ID = z | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | Reserved | Flags |1| 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 6. Tree Deletion 1580 To delete the entire tree (P2MP LSP) , Root send a PCRpt message with 1581 the R bit of the LSP object set and all the fields of the SR-P2MP- 1582 LSP-ID TLV set to 0(indicating to remove all state associated with 1583 this P2MP tunnel). The controller in response sends a PCInitiate 1584 message with R bit in the SRP object SET to all nodes along the path 1585 to indicate deletion of a label entry. 1587 7. Fragmentation 1589 The Fragmentation bit in the LSP object (F bit) can be used to 1590 indicate a fragmented PCEP message. 1592 8. Example workflow 1594 As per slides submitted in IETF 105. 1596 6. IANA Considerations 1598 This document contains no actions for IANA. 1600 7. Security Considerations 1602 TBD 1604 8. References 1606 8.1. Normative References 1607 8.2. Informative References 1609 [sr-p2mp-policy] D. Yoyer, Ed., C. Hassen, K. Gillis, C. Filsfils, R. 1610 Parekh, H.Bidgoli, "SR Replication Policy for P2MP Service Delivery", 1611 draft-voyer-spring-sr-p2mp-policy-01, April 2019. 1613 7. Acknowledgments 1615 The authors would like to thank Tanmoy Kundu and Stone Andrew at 1616 Nokia for Thier feedback and major contribution to this draft. 1618 Authors' Addresses 1620 Hooman Bidgoli 1621 Nokia 1622 600 March Rd. 1623 Ottawa, Ontario K2K 2E6 1624 Canada 1626 Email: hooman.bidgoli@nokia.com 1628 Daniel Voyer 1629 Bell Canada 1630 Montreal 1631 CA 1633 Email: daniel.voyer@bell.ca 1635 Siva Sivabalan 1636 Cisco Systems 1637 Ottawa 1638 Canada 1640 Email: msiva@cisco.com 1642 Jayant Kotalwar 1643 Nokia 1644 380 N Bernardo Ave, 1645 Mountain View, CA 94043 1646 US 1648 Email: jayant.kotalwar@nokia.com 1650 Saranya Rajarathinam 1651 Nokia 1652 380 N Bernardo Ave, 1653 Mountain View, CA 94043 1654 US 1655 Email: saranya.rajarathinam@nokia.com