idnits 2.17.1 draft-hsd-pce-sr-p2mp-policy-03.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 6 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 25, 2021) is 1066 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-spring-segment-routing-policy' is mentioned on line 813, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Bidgoli, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track V. Voyer 5 Expires: November 26, 2021 Bell Canada 6 S. Rajarathinam 7 Nokia 8 E. Hemmati 9 Cisco System 10 T. Saad 11 Juniper Networks 12 S. Sivabalan 13 Ciena 14 May 25, 2021 16 PCEP extensions for p2mp sr policy 17 draft-hsd-pce-sr-p2mp-policy-03 19 Abstract 21 SR P2MP policies are set of policies that enable architecture for 22 P2MP service delivery. This document specifies extensions to the 23 Path Computation Element Communication Protocol (PCEP) that allow a 24 stateful PCE to compute and initiate P2MP paths from a Root to a set 25 of Leaves. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 26, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . 4 63 3. Overview of PCEP Operation in SR P2MP Network . . . . . . . . 4 64 3.1. High level view of P2MP Policy Objects . . . . . . . . . 5 65 3.1.1. Shared Tree vs Non-Shared Replication Segment . . . . 6 66 3.2. Existing drafts used for defining a P2MP Policy . . . . . 7 67 3.2.1. Existing Documents used by this draft . . . . . . . . 7 68 3.2.2. P2MP Policy Identification . . . . . . . . . . . . . 8 69 3.2.3. Replication Segment Identification . . . . . . . . . 9 70 3.2.4. PCECC Use in Replication Segment . . . . . . . . . . 9 71 3.3. High Level Procedures for P2MP SR LSP Instantiation . . . 9 72 3.3.1. PCE-Init Procedure . . . . . . . . . . . . . . . . . 9 73 3.3.2. PCC-Init Procedure . . . . . . . . . . . . . . . . . 10 74 3.3.3. Common Procedure . . . . . . . . . . . . . . . . . . 10 75 3.3.4. Global Optimization of the Candidate Path . . . . . . 11 76 3.3.5. Fast Reroute . . . . . . . . . . . . . . . . . . . . 12 77 3.3.6. Connecting Replication Segment via Segment List . . . 13 78 3.4. SR P2MP Policy and Replication Segment TLVs and Objects . 13 79 3.4.1. SR P2MP Policy Objects . . . . . . . . . . . . . . . 13 80 3.4.2. Replication Segment Objects . . . . . . . . . . . . . 14 81 3.4.3. P2MP Policy and Replication Segment general 82 considerations . . . . . . . . . . . . . . . . . . . 14 83 4. Object Format . . . . . . . . . . . . . . . . . . . . . . . . 15 84 4.1. Open Message and Capability Exchange . . . . . . . . . . 15 85 4.1.1. PCECC Path Setup Capability . . . . . . . . . . . . . 15 86 4.1.2. Association Type Capability . . . . . . . . . . . . . 16 87 4.2. Symbolic Name in PCInit Message from PCC . . . . . . . . 16 88 4.3. P2MP Policy Specific Objects and TLVs . . . . . . . . . . 16 89 4.3.1. P2MP Policy Association Group for P2MP Policy . . . . 16 90 4.3.1.1. P2MP SR Policy Association Group Policy 91 Identifiers TLV . . . . . . . . . . . . . . . . . 16 92 4.3.1.2. P2MP SR Policy Association Group Candidate Path 93 Identifiers TLV . . . . . . . . . . . . . . . . . 17 94 4.3.1.3. P2MP SR Policy Association Group Candidate Path 95 Attributes TLV . . . . . . . . . . . . . . . . . 18 96 4.3.2. P2MP-END-POINTS Object . . . . . . . . . . . . . . . 18 98 4.4. P2MP Policy and Replication Segment Identifier Object and 99 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 4.4.1. Extension of the LSP Object, SR-P2MP-LSPID-TLV . . . 21 101 4.5. Replication Segment . . . . . . . . . . . . . . . . . . . 22 102 4.5.1. The format of the replication segment message . . . . 23 103 4.5.2. PCECC . . . . . . . . . . . . . . . . . . . . . . . . 23 104 4.5.3. Label action rules in replicating segment . . . . . . 26 105 4.5.4. SR-ERO Rules . . . . . . . . . . . . . . . . . . . . 27 106 4.5.4.1. SR-ERO subobject changes . . . . . . . . . . . . 27 107 5. Tree Deletion . . . . . . . . . . . . . . . . . . . . . . . . 28 108 6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 28 109 7. Example Workflows . . . . . . . . . . . . . . . . . . . . . . 28 110 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 33 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 112 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 114 11.1. Normative References . . . . . . . . . . . . . . . . . . 34 115 11.2. Informative References . . . . . . . . . . . . . . . . . 34 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 118 1. Introduction 120 The draft [draft-ietf-pim-sr-p2mp-policy] defines a variant of the SR 121 Policy [draft-ietf-spring-segment-routing-policy] for constructing a 122 P2MP segment to support multicast service delivery. 124 A Point-to-Multipoint (P2MP) Policy connects a Root node to a set of 125 Leaf nodes, optionally through a set of intermediate replication 126 nodes. A Replication segment 127 [draft-ietf-spring-sr-replication-segment], which corresponds to the 128 state of a P2MP segment on a particular node which provide forwarding 129 instructions for the segment. 131 A P2MP Policy is relevant on the root of the P2MP Tree and it 132 contains candidate paths. The candidate paths are made of path- 133 instances and each path-instance is constructed via replication 134 segments. These replication segments are programmed on the root, 135 leaves and optionally intermediate replication nodes. 137 A replication segments MAY be connected directly, or they MAY be 138 connected or steered via unicast SR segment or a segment list. 140 For a P2MP Tree, a controller may be used to compute paths from a 141 Root node to a set of Leaf nodes, optionally via a set of replication 142 nodes. A packet is replicated at the root node and optionally on 143 Replication nodes towards each Leaf node. 145 There are two types of a P2MP Tree: Spray and Replication. 147 A Point-to-Multipoint service delivery could be via Ingress 148 Replication, known as Spray. The root unicasts individual copies of 149 traffic to each leaf. The corresponding P2MP Policy consists of 150 replication segments only for the root and the leaves and they are 151 connected via a unicast SR Segment. 153 A Point-to-Multipoint service delivery could also be via Downstream 154 Replication, known as Replication. The root and some downstream 155 replication nodes replicate the traffic along the way as it traverses 156 closer to the leaves. 158 The leaves and the root can be explicitly configured on the PCE or 159 PCC can update the PCE with the information of the discovered root 160 and leaves. As an example Multicast protocols like MVPN procedures 161 [RFC6513] or PIM can be used to discovery the leaves and roots on the 162 PCC and update the PCE with these relevant information. The 163 controller can calculate the P2MP Policy and any of its associated 164 replication segments with these info. 166 This document defines PCEP objects, TLVs and the procedures to 167 instantiate a P2MP Policy and Replication Segments. 169 2. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 3. Overview of PCEP Operation in SR P2MP Network 177 After discovering the root and the leaves on the PCE (via different 178 mechanism mentioned in previous sections), the PCE computes the P2MP 179 Tree and identifying the relevant Replication routers, then it 180 programs the PCCs with relevant information needed to create a P2MP 181 Tree. 183 As per draft [draft-ietf-pim-sr-p2mp-policy] a P2MP Policy is defined 184 by Root-ID, Tree-ID and a set of leaves. A P2MP policy is a variant 185 of SR policy as such it uses the same concept as draft 186 [draft-ietf-pce-segment-routing-policy-cp]. A P2MP policy is 187 composed of a collection of SR P2mp Candidate Paths. Candidate paths 188 are computed by the PCE and can be used for P2MP Tree redundancy. 189 Only a single candidate path may be active at each time. Each 190 candidate paths can be globally optimized, therefore it is consists 191 of multiple path-instances. A path-instance can be considered to a 192 P2MP LSP. If a candidate path needs to be globally optimized two 193 path-instances can be programmed on the root node and via make before 194 break procedures the candidate path can be switched from path- 195 instance 1 to the 2nd path-instance. The forwarding states of these 196 path-instances are build via replication segments, in short each 197 path-instance initiated on the root has its own set of replication 198 segments on the Root, Transit and Leaf nodes. 200 A replication segment is set of forwarding instructions on a specific 201 node. Each instruction may be a PUSH or SWAP operation before 202 forwarding out of an interface, or a POP action on bud and leaf 203 nodes. 205 PCE could also calculate and download additional information for the 206 replication segments, such as protections next-hops for link 207 protection (FRR). 209 3.1. High level view of P2MP Policy Objects 211 o SR P2MP Policy 213 * Is only relevant on the Root of the P2MP path and is a policy 214 on PCE. It is downloaded only on the rootnode and is 215 identified via It contains the following 216 information: 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 223 the Root 225 + A set of Candidate paths belonging to the policy 227 + Optional Constraints used to build these candidate paths 229 o Candidate Path: 231 * Is used for P2MP Tree redundancy where the candidate path with 232 the highest preference is the active path. 234 * It can contain two path-instance for global optimization 235 procedures (i.e. make before break) 237 * Contains information regarding protocol-id, originator, 238 discriminator, preference, path-instances 240 o Replication Segment: 242 * Is the forwarding information needed on each node for building 243 the forwarding path for each path-instance of the P2MP 244 Candidate path. 246 * Explained further in upcoming sections, there are 2 ways to 247 identify the replication segment, depending if they are shared 248 and non-shared 250 + It is identified via Tree-ID and Root-ID and path-instance 251 for non-shared replication segment. 253 + It is identified via Node-ID, Replication-ID, for shared 254 replication segment 256 + Contains forwarding instructions, in the form of a list of 257 outgoing segments each of which may be a list 259 + On the forwarding plane the Replication Segment is 260 identified via the incoming Replication SID. 262 + Replication segment information is downloaded on Root, 263 Transit and Leaf nodes respectively. 265 3.1.1. Shared Tree vs Non-Shared Replication Segment 267 A non-shared Replication Segment is used when the label field of the 268 PMSI Tunnel Attribute (PTA) is set to zero as per 269 [draft-parekh-bess-mvpn-sr-p2mp]. This is used when there is no 270 upstream assigned label in the PTA (provider tunnel attribute) and 271 aggregate of MVPNs into a single P-Tunnel is not desired. 273 An alternative shared Replication Segment is used when the label 274 field of the PTA is not set to Zero and there is an upstream assigned 275 label in the PTA. In this case multiple MVPNs (VRFs) can be 276 aggregate into a single Provider Tunnel and the upstream assigned 277 label distinguishes the MVPNs context. 279 It should be noted that the shared Replication Segment can also be 280 used to build a bypass tunnel for the purpose of fast re-route. This 281 might be desirable if the bypass tunnel is build via the PCE and 282 downloaded to the PCC for link protection. In doing so, multiple 283 non-shared Replication Segments can use the shared replication 284 segment as their bypass tunnel for link protection. The replication 285 segments used in this bypass tunnel should only create a unicast 286 bypass tunnel to protect the link between two replication segments on 287 the primary path. 289 3.2. Existing drafts used for defining a P2MP Policy 291 This document attempts to leverage existing IETF draft and RFC 292 documents which define PCEP objects, to update the PCE with Root and 293 Leaves information when PCC Initiated method is used. Similarly, 294 existing documents are utilized where feasible to update the PCC with 295 relevant information to build the P2MP Policy and its Replication 296 Segments. This document introduces new TLVs and Objects specific to 297 a programing P2MP policy and its replication segment. 299 3.2.1. Existing Documents used by this draft 301 o [RFC8231] The bases for a stateful PCE, and reuses the following 302 objects or a variant of them 304 * 306 * 308 * A variation of the LSP identifier TLV is defined in this draft, 309 to support P2MP LSP Identifier 311 o [RFC8236] P2MP capabilities advertisement 313 o [draft-ietf-pce-segment-routing-policy-cp] Candidate paths for 314 P2MP Policy is used for Tree Redundancy. As an example, a P2MP 315 Policy can have multiple candidate paths. Each protecting the 316 primary candidate path. The active path is chosen via the 317 preference of the candidate path. 319 o [RFC3209] Defines the instance-ID, instance-ID is used for global 320 optimization of a candidate path with in a P2MP policy. Each 321 Candidate path can have 2 path-instances. These path-instances 322 are equivalent to sub-lsps (instance-IDs). There are used for MBB 323 and global optimization procedures. instance-ID is equivalent to 324 LSP ID 326 o [draft-ietf-spring-segment-routing-policy] Segment-list, used for 327 connecting two non-adjacent replication policy via a unicast 328 binding SID or Segment-list. 330 o [RFC8306] P2MP End Point objects, used for the PCC to update the 331 PCE with discovered Leaves. 333 o [draft-ietf-pce-pcep-extension-for-pce-controller] for programming 334 and identifying the Replication Segment. A new PCE CC Capability 335 sub Tlv is introduced to indicated the support to handle PCE CC 336 based label download for SR P2MP. 338 o [draft-ietf-pce-multipath] Forwarding instruction for a P2MP LSP 339 is defined by a set of SR-ERO sub-objects in the ERO object, ERO- 340 ATTRIBUTES object and MULTIPATH-BACKUP TLV as defined in this 341 draft. 343 o [RFC8664] SR-ERO Sub Object used in the multipath. 345 It should be noted that the [draft-dhs-spring-sr-p2mp-policy-yang] 346 can provide further details of the high level P2MP Policy Model. 348 3.2.2. P2MP Policy Identification 350 A P2MP Policy and its candidate path can be identified on the root 351 via the P2MP LSP Object. This Object is a variation of the LSP ID 352 Object defined in [RFC8231] and is as follow: 354 o PLSP-ID: [RFC8231], is assigned by PCC and is unique per candidate 355 path. It is constant for the lifetime of a PCEP session. Stand- 356 by candidate paths will be assigned a new PLSP-ID by PCC. Stand- 357 by candidate paths can co-exist with the active candidate path. 359 * Note: Every candidate path in the SR-P2MP Policy is unique with 360 its own unique PLSP-ID and Instance-ID. But the same Tree-ID 361 is used for all candidate paths as they are part of the same 362 P2MP Tree. 364 o Root-ID: is equivalent to the first node on the P2MP path, as per 365 [RFC3209], Section 4.6.2.1 367 o Tree-ID: is equivalent to Tunnel Identifier color which identifies 368 a unique P2MP Policy at a ROOT and is advertised via the PTA in 369 the BGP AD route or can be assigned manually on the root. Tree-ID 370 needs to be unique on the root. 372 o Instance-ID: LSP ID Identifier as defined in RFC 3209, is the 373 path-instance identifier and is assigned by the PCC. As it was 374 mentioned the candidate path can have up to two path-instance for 375 global optimization. Note that the Root-ID, Tree-ID and Instance- 376 ID are part of a new SR- P2MP-LSP-IDENTIFIER TLV which will be 377 identified in this draft. 379 * Note: each Path-instance on the Root node is assigned a unique 380 Instance-ID 382 3.2.3. Replication Segment Identification 384 The key to identify a replication segment is also a P2MP LSP Object. 385 With varying encoding rules for the SR-P2MP-LSP- IDENTIFIER TLV which 386 will be explained in later sections. 388 3.2.4. PCECC Use in Replication Segment 390 PCECC and a variant of CCI object is used in Replication Segment to 391 identify a cross connect. A cross connect is a incoming SID and set 392 of outgoing interfaces and their corresponding SID. The CCI objects 393 contains the incoming SID while the outgoing interfaces are presented 394 via the ERO objects, which each may contain a list of segments. 396 3.3. High Level Procedures for P2MP SR LSP Instantiation 398 A P2MP policy can be instantiated via the PCC or the PCE depending on 399 how the root and the leaves are discovered. This document describes 400 two way to discover the root and the leaves: 402 o They can be configured and identified on the controller and are 403 considered PCE initiated. 405 o They can be discovered on the PCC via MVPN procedures [RFC6513] or 406 legacy multicast protocols like PIM or IGMP etc... and are 407 considered PCC initiated. 409 3.3.1. PCE-Init Procedure 411 o PCE is informed of the P2MP request through its API or 412 configuration mechanism to instantiate a P2MP tunnel. 414 o PCE will initiate the P2MP Policy for the request, by sending a 415 PCInitiate message to the Root. 417 o Root in response to the PCInitiate message, will generate PLSP-ID 418 for the candidate paths and an Instance-ID for the Path-Instance 419 (LSP-ID) contained with in the candidate path. The tree-id for 420 the P2MP Policy is also filled. PCC will reports back the PLSP- 421 ID, Instance-ID and tree-id via PCRpt message 423 * Optionally, the Root can add any additional leaves that were 424 discovered by multicast procedures in this PCRpt message. 426 o PCE will send a PCInitiate message to the Root, Transit and the 427 Leaf nodes to download the Replication Segment information. These 428 messages will utilize the CCI object to encode the forwarding 429 instruction information. 431 o PCE will then send a PCUpdate to the root indicating the 432 association information (Candidate path) , and implicitly indicate 433 it to bind to the latest CCI information downloaded. 435 3.3.2. PCC-Init Procedure 437 After Root (PCC) discovers the leaves (as an example via MVPN 438 Procedures or other mechanism), the following communication happens 439 between the PCE and PCCs 441 o Root sends a PCRpt message for P2MP policy to PCE including the 442 Root-ID, Tree-ID, PLSP-ID, Instance-ID, symbolic-path-name, and 443 any leaves discovered until then. 445 o PCE on receiving of this report, will compute the P2MP Policy and 446 its replication segments. 448 * PCE will send a PCInitiate message to the Root, Transit and the 449 Leaf nodes to download the Replication Segment information. 450 These messages will utilize the CCI object to encode the 451 forwarding instruction information. 453 * PCE will then send a PCUpdate to the root indicating the 454 association information (Candidate path) , and implicitly 455 indicate it to bind to the latest CCI information downloaded. 457 3.3.3. Common Procedure 459 The following procedures are the same for PCE or PCC Init. 461 o PCE will download the replication segments for the Candidate- 462 path's path-instances to all the leaves and transit nodes using 463 PCInitiate message with PLSP-ID = 0, Instance-ID =0, symbolic path 464 name, Root-address, Tree-id(assigned by the root). This 465 PCInitiate message includes the EROs needed for the replication 466 segments. These messages will utilize the CCI object to encode 467 the forwarding instruction information. 469 o Any new candidate path for the P2MP Policy is downloaded by PCE to 470 the Root by sending a PCInitiate message 472 * it should be noted, PLSP-ID, Path-Instance ID and the Tree-ID 473 are generated by the PCC for these new candidate paths and 474 their Path-instances 476 * Any update to the Candidate Paths or Replication Segments is 477 done via the PCUpd message. Association object need to be 478 present for Candidate Path updates and CCI object for the 479 replication segment updates. 481 o The PCE will also download the necessary replication segment for 482 the candidate path and its path-instances to the root, leaves and 483 the transit nodes via a PCInit message 485 o New leaves can be discovered via Multicast procedures, and new 486 replication segments can be instantiated or existing one updated 487 to reach these leaves 489 * If these leaves reside on routers that are part of the P2MP LSP 490 path, then PCUpd is sent from PCE to necessary PCCs (LEAVES, 491 TRANSIT or ROOT) with the correct PLSP-ID, Instance-ID, Tree-ID 492 and CC-ID. 494 * If the new leaves are residing on routers that are not part of 495 the P2MP Tree yet, then a PCInitiate message is sent down with 496 PLSP- ID=0 and Instance-ID=0 on the corresponding routers. 498 o The active candidate-path is indicated by the PCC through the 499 operational bits(Up/Active) of the LSP object in the PCRpt 500 message. If a candidate path needs to be removed, PCE sends PC 501 Initiate message, setting the R-flag in the LSP object and R bit 502 in the SRP-object. 504 o To remove the entire P2MP-LSP, PCE needs to send PCInitiate remove 505 messages for every candidate path of the P2MP POLICY to the root 506 and send PCInitiate remove messages for every Replication Regment 507 on all the PCCs on the P2MP Tree. The R bit in the LSP Object as 508 defined in [RFC8231], refers to the removal of the LSP as 509 identified by the SR-P2MP-POLICY-ID-TLV (defined in this 510 document). An all zero (SR-P2MP-LSP-ID-TLV defines to remove all 511 the state of the corresponding PLSP-ID. 513 o A candidate path is made active based on the preference of the 514 path. If the Root is programed with multiple candidate paths from 515 different sources, as an example PCE and CLI, based on its tie- 516 breaking rules, if it selects the CLI path, it will send a report 517 to PCE for the PCE path indicating the status of label-download 518 and sets operational bit of the LSP object to UP and Not Active . 519 At any instance, only one path will be active 521 3.3.4. Global Optimization of the Candidate Path 523 When a P2MP LSP needs to be optimized for any reason (i.e. it is 524 taking a FRR tunnel or new routers are added to the network) a global 525 optimization of the candidate path is possible. 527 Each Candidate Path can contain two Path-Instances. The current 528 unoptimized Path-Instance is the active instance and its replication 529 segments are forwarding the multicast PDUs from the root to the 530 leaves. However the second optimized Path-Instance will be setup 531 with its own unique replication segments throughout the network, from 532 the Root to the leaves. These two Path-Instances can co-exist. The 533 two Path-Instances are uniquely identified by their Instance-ID in 534 the SR-P2MP-POLICY-ID-TLV (defined in this document). After the 535 optimized LSP has been downloaded successfully PCC MUST send two 536 reports, reporting UP of the new path indicating the new LSP-ID, and 537 a second reporting the tear down of the old path with the R bit of 538 the LSP Object SET with the old Instance-ID in the SR-P2MP-POLICY-ID- 539 TLV. This MBB procedure will move the multicast PDUs to the 540 optimized Path-Instance. 542 The leaf should be able to accept traffic from both Path-Instances to 543 minimize the traffic outage by the Make Before Break process. 545 3.3.5. Fast Reroute 547 Currently this draft identifies the Facility FRR procedures. In 548 addition, only LINK Protection procedures are defined. How the 549 Facility Path is built and instantiated is beyond the scope of this 550 document. 552 R 553 | | 554 T 555 | 556 --- 557 | | 558 L1 L2 560 Figure 1 562 R---F1 563 | | 564 T---F2 565 | 566 --- 567 | | 568 L1 L2 570 Figure 2 572 As an example, the bypass path (unicast bypass) between the PLR and 573 MP can be constructed via SR or even via a shared tree (replication 574 segment). 576 As an example, in figure 1 the detour path between R and T is the 2nd 577 fiber between these nodes. As such the bypass path could be setup on 578 the 2nd fiber. That said in figure 2 the bypass path is traversing 579 multiple nodes and this example a unicast SR path might be ideal for 580 setting up the detour path. 582 In addition, PHP procedure and implicit null label on the bypass path 583 can be implemented to reduce the PCE programming on the MP PCC. 585 Optional shared replication segments can be used in networks that do 586 not have unicast SR turned on. These shared replication segments can 587 be programmed on the bypass nodes without a P2MP Policy. The 588 replication segments on primary path can use these shared replication 589 segments as a protection tunnel to protect links. 591 3.3.6. Connecting Replication Segment via Segment List 593 There could be nodes between two replication segment that do not 594 support P2MP Policy or Replication segment. It is possible to 595 connect two non-adjacent Replication segments via a unicast segment 596 routing path via a SID list, comprised of any IGP supported segment 597 types (ex: Binding, Adjacency, Node) to forward to the next 598 replicating node. This information is encoded via the SR-ERO sub- 599 objects and ERO-attributes objects. The last segment in an encoding 600 SID list MUST be a replication segment 602 3.4. SR P2MP Policy and Replication Segment TLVs and Objects 604 3.4.1. SR P2MP Policy Objects 606 SR P2MP Policy can be constructed via the following objects 608 610 612 614 [] 616 optionally if the root is updating the PCE with end point list the 617 end-point-list object can be added. 619 [] 621 3.4.2. Replication Segment Objects 623 Replication segment can be constructed via the following objects 625 626 627 628 (| 629 ()) 630 ::= 631 [] 632 ::= (() 633 []) 635 Path-attribute as per [draft-ietf-pce-multipath] 637 3.4.3. P2MP Policy and Replication Segment general considerations 639 The above new objects and TLV's defined in this document can be 640 included in PCRpt, PcInitiate and PcUpd messages. 642 It should be noted that every PcRpt, PcInitiate and PCUpd messages 643 will contain full list of the Leaves and segment and forwarding 644 information that is needed to build the Candidate path and its 645 Replication segments. They will never send the delta information 646 related to the new leaves or forwarding information that need to be 647 added or updated. This is necessary to ensure that PCE or any new 648 PCE is in sync with the PCC. 650 When a PCRpt, PCInitiate and PCUpd messages is sent via PCEP it 651 maintains the previous ERO Path IDs and generates new Path IDs for 652 new instructions, as per [draft-ietf-pce-multipath]. The PATH IDs 653 are maintained for each specific forwarding instructions until the 654 instructions are deleted. For example: When the first leaf is added, 655 the PCE will update with PathI ID 1 to the PCC. When the second leaf 656 is added, according to the path calculated, PCE might just append the 657 existing instruction Path ID 1 with a new Path ID 2 to construct the 658 new PCUpd message. 660 The CCI Object is used to identify the entire cross connect of 661 incoming segment and the set of outgoing Interfaces and their 662 corresponding SIDs/SIDList. Any modification to the cross connect 663 should use this CCI ID to identify the cross connect uniquely. 664 Leaves and their corresponding Path IDs can be removed from the cross 665 connect identified via the CCI. The CC-ID is assigned by the PCE. 667 4. Object Format 669 4.1. Open Message and Capability Exchange 671 Format of the open Object: 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Ver | Flags | Keepalive | DeadTimer | SID | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | | 678 // Optional TLVs // 679 | | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 All the nodes need to establish a PCEP connection with the PCE. 684 During PCEP Initialization Phase, PCEP Speakers need to set flags N, 685 M, P in the STATEFUL-PCE-CAPABILITY TLV as defined in 686 [draft-ietf-pce-stateful-pce-p2mp] section-5.2 688 This draft extends the PCEP OPEN object by defining an optional TLV 689 to indicate the PCE's capability to perform SR-P2MP path computations 690 with a new IANA capability type. 692 The inclusion of this TLV in an OPEN object indicates that the sender 693 can perform SR-P2MP path computations. This will be similar to the 694 P2MP-CAPABILITY defined in [RFC8306] section-3.1.2 and a new value 695 needs to be defined for SR-P2MP. 697 4.1.1. PCECC Path Setup Capability 699 A PST of PCECC is also added as per 700 [draft-ietf-pce-pcep-extension-for-pce-controller]. 702 This document also introduces a new bit S in the SR PCECC capacity 703 Sub TLV indicating the support to handle PCECC based label download 704 for Replication segment. 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Type=1 | Length=4 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Flags |S|M|L| 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Also, the N,M,P bits in STATEFUL-PCE-CAPABILITY TLV should be SET. 714 4.1.2. Association Type Capability 716 A Assoc-Type-List TLV as per [RFC8697] section 3.4 should be send via 717 PCEP open object with following association type 719 +-------------------+----------------------------+------------------+ 720 | Association Type | Association Name | Reference | 721 | Value | | | 722 +-------------------+----------------------------+------------------+ 723 | TBD1 | P2MP SR Policy Association | This document | 724 +-------------------+----------------------------+------------------+ 726 OP-CONF-Assoc-RANGE (Operator-configured Association Range)should not 727 be set for this association type and must be ignored. 729 The open message MUST include the MULTIPATH CAPABILITY TLV as defined 730 in [draft-ietf-pce-multipath] 732 4.2. Symbolic Name in PCInit Message from PCC 734 As per [RFC8231] section 7.3.2. a Symbolic Path Name TLV should 735 uniquely identify the P2MP path on the PCC. This symbolic path name 736 is a human-readable string that identifies an P2MP LSP in the 737 network. It needs to be constant through the lifetime of the P2MP 738 path. 740 As an example in the case of P2MP LSP the symbolic name can be p2mp 741 policy name + candidate path name of the LSP. 743 4.3. P2MP Policy Specific Objects and TLVs 745 4.3.1. P2MP Policy Association Group for P2MP Policy 747 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 748 [RFC8697]. The ASSOCIATION object includes "Association type" 749 indicating the type of the association group. This document adds a 750 new Association type. Association type = TBD1 "P2MP SR Policy 751 Association Type" for SR Policy Association Group (P2MP SRPAG). As 752 per [draft-barth-pce-segment-routing-policy-cp] section 5, three new 753 TLVs are identified to carry association information: P2MP-SRPAG- 754 POL-ID-TLV, P2MP-SRPAG-CPATH-ID-TLV, P2MP-SRPAG-CPATH-ATTR-TLV 756 4.3.1.1. P2MP SR Policy Association Group Policy Identifiers TLV 758 The P2MP-SRPOLICY-POL-ID TLV is a mandatory TLV for the P2MP-SRPAG 759 Association. Only one P2MP-SRPOLICY-POL-ID TLV can be carried and 760 only the first occurrence is processed and any others MUST be 761 ignored. 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Root | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | TREE-ID | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Type: TBD2 for "P2MP-SR-POLICY-POL-ID" TLV. 775 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 777 Tunnel Sender Address : Can be either IPv4 or IPv6, this value is the 778 value of the root loopback IP. 780 Tree-ID: Tree ID that the replication segment is part of as per 781 draft-ietf-spring-sr-p2mp-policy 783 4.3.1.2. P2MP SR Policy Association Group Candidate Path Identifiers 784 TLV 786 The P2MP-SRPOLICY-CPATH-ID TLV is a mandatory TLV for the P2MPSRPAG 787 Association. Only one P2MP-SRPOLICY-CPATH-ID TLV can be carried and 788 only the first occurrence is processed and any others MUST be 789 ignored. 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Type | Length | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Proto. Origin |Flags |A| Reserved | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Originator ASN | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | | 801 | Originator Address | 802 | | 803 | | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Discriminator | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Type: TBD3 for "P2MP-SR-POLICY-CPATH-ID" TLV. 810 Length: 28. 812 Protocol Origin: 8-bit value that encodes the protocol origin, as 813 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 815 Flags : A: This candidate path is active. At any instance only one 816 candidate path can be active. PCC indicates the active candidate 817 path to PCE through this bit. Reserved: MUST be set to zero on 818 transmission and ignored on receipt. 820 Originator ASN: Represented as 4 byte number, part of the originator 821 identifier, as specified in 822 [draft-ietf-spring-segment-routing-policy] Section 2.4. 824 Originator Address: Represented as 128 bit value where IPv4 address 825 are encoded in lowest 32 bits, part of the originator identifier, as 826 specified in [draft-ietf-spring-segment-routing-policy] Section 2.4. 828 Discriminator: 32-bit value that encodes the Discriminator of the 829 candidate path. 831 4.3.1.3. P2MP SR Policy Association Group Candidate Path Attributes TLV 833 The P2MP-SRPOLICY-CPATH-ATTR TLV is an optional TLV for the SRPAG 834 Association. Only one P2MP-SRPOLICY-CPATH-ATTR TLV can be carried 835 and only the first occurrence is processed and any others MUST be 836 ignored. 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Type | Length | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Preference | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 Type: TBD4 for "P2MP-SRPOLICY-CPATH-ATTR" TLV. 848 Length: 4. Preference: Numerical preference of the candidate path, 849 as specified in [draft-ietf-spring-segment-routing-policy] 850 Section 2.7. 852 If the TLV is missing, a default preference of 100 as specified in 853 [draft-ietf-spring-segment-routing-policy] is used. 855 4.3.2. P2MP-END-POINTS Object 857 In order for the Root to indicate operations of its 858 leaves(Add/Remove/Modify/DoNotModify), the PC Report message is 859 extended to include P2MP End Point Object which is 860 defined in [RFC8306] 862 The format of the PC Report message is as follow: 864 866 [] 868 870 [] 872 [] 873 IPV4-P2MP END-POINTS: 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Leaf type | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Source IPv4 address | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Destination IPv4 address | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 ~ ... ~ 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Destination IPv4 address | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 IPV6-P2MP END-POINTS: 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Leaf type | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | | 895 | Source IPv6 address (16 bytes) | 896 | | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | | 899 | Destination IPv6 address (16 bytes) | 900 | | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 ~ ... ~ 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | | 905 | Destination IPv6 address (16 bytes) | 906 | | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Leaf Types (derived from [RFC8306] section 3.3.2) : 911 1. New leaves to add (leaf type = 1) 913 2. Old leaves to remove (leaf type = 2) 915 3. Old leaves whose path can be modified/reoptimized (leaf type = 916 3), Future reserved not used for tree SID as of now. 918 4. Old leaves whose path must be left unchanged (leaf type = 4) 919 5. the entire pce leaf list is overwritten and replaced with the new 920 leaf list (leaf type = 5) 922 A given P2MP END-POINTS object gathers the leaves of a given type. 923 Note that a P2MP report can mix the different types of leaves by 924 including several P2MP END-POINTS objects. The END-POINTS object 925 body has a variable length. These are multiples of 4 bytes for IPv4, 926 multiples of 16 bytes, plus 4 bytes, for IPv6. 928 4.4. P2MP Policy and Replication Segment Identifier Object and TLV 930 As it was mentioned previously both P2MP Policy and Replication 931 Segment are identified via the LSP object and more precisely via the 932 SR-P2MP-LSPID-TLV 934 The P2MP Policy uses the PLSP-ID to identify the Candidate Paths and 935 the Instance-ID to identify a Path-Instance with in the Candidate 936 path. 938 On other hand the Replication Segment uses the SR-P2MP-LSPID-TLV to 939 identify and correlate a Replication Segment to a P2MP Policy 941 As it was noted previously on the Root, the P2MP Policy and the 942 Replication Segment is downloaded via the same PCUpd message. 944 4.4.1. Extension of the LSP Object, SR-P2MP-LSPID-TLV 946 The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 947 the PLSP-ID to uniquely identify an LSP that is constant for the life 948 time of a PCEP session. Similarly, for a P2MP tunnel, the PLSP-ID 949 identify a Candidate Path uniquely with in the P2MP policy. 951 The LSP Object MUST include the new SR-P2MP-POLICY-ID-TLV (IPV4/IpV6) 952 defined in this document below. This is a variation to the P2MP 953 object defined in [draft-ietf-pce-stateful-pce-p2mp] 955 SR-IPV4-P2MP-POLICY-ID TLV: 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Type=TBD | Length=10 | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Root | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Tree-ID | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Path-Instance-ID | Reserved | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 SR-IPV6-P2MP-POLICY-ID TLV : 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Type=TBD | Length=22 | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | | 975 + + 976 | Root | 977 + (16 octets) + 978 | | 979 + + 980 | | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Tree-ID | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Path-Instance-ID | Reserved | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 The type (16-bit) of the TLV is TBD (need allocation by IANA). 989 Root: Source Router IP Address 991 Tree-ID: Unique Identifier of this P2MP LSP on the Root. 993 Instance-ID : Contains 16 Bit instance ID. 995 4.5. Replication Segment 997 As per [draft-ietf-spring-sr-replication-segment] a replication 998 segment has a next-hop-group which MAY contain a single outgoing 999 replication SID or a list of SIDs (sr-policy-sid-list) In either case 1000 there needs to be a replication SID at the bottom of the stack. This 1001 means two replication segments can be directly connected or connected 1002 via a SR domain. 1004 4.5.1. The format of the replication segment message 1006 The format of a Replication Segment message encoding is similar to 1007 P2MP Policy. However, the P2MP Policy contains the association 1008 object and the replication segment message does not contain the 1009 association object. In addition the replication segment uses the CCI 1010 object to identify a P2MP cross connect. The replication segment is 1011 downloaded individually to the root, transit and leaf nodes without 1012 the P2MP Policy. The P2MP Policy is a Root Concept. The replication 1013 segment uses SR-P2MP-LSPID-TLV as its identifier. The TLV is coded 1014 differently for shared and non-shared case. 1016 o In the case of a replication segment being shared, the Tree-ID in 1017 the SR-P2MP-POLICY Identifier TLV is the replication-id of the 1018 Replication Segment and Root = 0, Instance-Id = 0. When 1019 downloading a shared replication segment from PCE through a 1020 PcInitiate message, the SR-P2MP-POLICY Identifier TLV is all 0, 1021 and on the report back from PCC, PCC generates PLSP-ID, 1022 Replication-id (Tree-id field will be populated with replication- 1023 id). Instance-id will be 0. 1025 4.5.2. PCECC 1027 The CCI Object as defined in 1028 [draft-ietf-pce-pcep-extension-for-pce-controller] is used to 1029 identify a forwarding instruction in the Replication Segment. A 1030 forwarding instruction is incoming SID and a set of outgoing 1031 branches. The CCI Object-Type of 1 is used for the MPLS Label. The 1032 label in the CCI Object is the incoming SID. The outgoing SIDs are 1033 defined by the ERO Objects. 1035 The CCI Object can be include in Reports, initiate and Update 1036 messages for Replication Segments. 1038 The PCInitiate message defined in [RFC8281] and extended in 1039 [draft-ietf-pce-pcep-extension-for-pce-controller] is further 1040 extended to support SR-P2MP replication segment based central control 1041 instructions. 1043 The format of the extended PCInitiate message is as follows: 1044 ::= 1045 1046 Where: 1047 is defined in [RFC5440] 1049 ::= 1050 [] 1052 ::= 1053 (| 1054 | 1055 ) 1057 ::= 1058 1059 (| 1060 ()) 1062 ::= 1063 [] 1065 ::= (() 1066 []) 1068 Where: 1069 and 1070 are as per 1071 [RFC8281]. 1073 The LSP and SRP object is defined in [RFC8231]. The 1074 is as per [RFC8281] [draft-ietf-pce-multipath] (PATH-ATTRIB and ERO). 1076 The format of the PCRpt message is as follows: 1078 ::= 1079 1080 Where: 1082 ::= [] 1084 ::= (| 1085 ) 1087 ::= [] 1088 1089 1091 ::= [] 1092 1093 (| 1094 ()) 1096 ::= 1097 [] 1099 Where: 1100 is as per [RFC8231] and the LSP and SRP object are 1101 also defined in [RFC8231]. 1102 The is as per [draft-ietf-pce-multipath] (PATH-ATTRIB 1103 and ERO). 1105 This document extends the use of PCUpd message with SR-P2MP CCI as 1106 follows: 1108 ::= 1109 1110 Where: 1112 ::= [] 1114 ::= (| 1115 ) 1117 ::= 1118 1119 1121 ::= 1122 1123 () 1125 Where: 1126 is as per [RFC8231] and the LSP and SRP object are 1127 also defined in [RFC8231]. 1128 The is as per [draft-ietf-pce-multipath] (PATH-ATTRIB 1129 and ERO). 1131 4.5.3. Label action rules in replicating segment 1133 The node action and role of ingress, transit, leaf or bud, is 1134 indicated via a new Node Role TLV. This document introduces a new 1135 SR-P2MP-NODE-ROLE TLV (Type To be assigned by IANA) that will be 1136 present in the PATH-ATTRIB object. 1138 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 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Type=TBD | Length=4 | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Role Type | Reserved | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 o ingress, role type = 1 1147 o transit, role type = 2 1149 o leaf, role type = 3 1151 o bud, role type = 4 1153 4.5.4. SR-ERO Rules 1155 Forwarding information of a replication segment can be configured and 1156 steered via many different mechanisms. 1158 As an example a replication SID can be steered via: 1160 1. Replication SID steered with an IPv4/IPv6 directly connected 1161 nexthop 1163 * In this case there will two SR-ERO in the ERO Object, with the 1164 Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO 1165 on the top. 1167 2. Replication SID steered with an IPv4/IPv6 loopback address that 1168 reside on the directly connected router. 1170 * In this case there will two SR-ERO in the ERO Object, with the 1171 Replication SID SR-ERO at the bottom and the IPv4/IPv6 SR-ERO 1172 on the top. 1174 * In addition a new flag D is added to the SR-ERO to signal that 1175 the Loopback nexthop is connected to the directly attached 1176 router. 1178 3. Replication SID steered with unnumbered IPv4/IPv6 directly 1179 connected Interface 1181 4. Replication SID steered via a SR adjacency or node SID 1183 * In this case even a sid-list can be used to traffic engineer 1184 the path between two Replication Segment 1186 * The Replication SID SR-ERO is at the bottom while the segments 1187 describing the path are on top in order. 1189 4.5.4.1. SR-ERO subobject changes 1191 SR-ERO from RFC 8664 is used to construct the forwarding information 1192 needed for Replication Segment. 1194 A new D flag was added to indicate a loopback nexthop that is 1195 residing on the directly attached router. It should be noted that 1196 this flag should be set only for the loopback case and not for a 1197 local interface as a nexthop. 1199 0 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 |L| Type=36 | Length | NT | Flags |D|F|S|C|M| 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | SID (optional) | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 // NAI (variable, optional) // 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 Flags : F, S, C, M are already defined in rfc8664. 1211 This document defines a new flag D: If the next-hop in NAI field is 1212 system IP or loopback, this bit indicates whether the system IP / 1213 loopback is directly connected router or not. If set indicates 1214 directly connected address. When this bit is set, F bit should be 0 1215 (meaning NAI should be present) 1217 5. Tree Deletion 1219 To delete the entire tree (P2MP LSP), Root send a PCRpt message with 1220 the R bit of the LSP object set and all the fields of the SR-P2MP- 1221 LSP-ID TLV set to 0(indicating to remove all state associated with 1222 this P2MP tunnel). The PCE in response sends a PCInitiate message 1223 with R bit in the SRP object SET to all nodes along the path to 1224 indicate deletion of the entries. 1226 6. Fragmentation 1228 The Fragmentation bit in the LSP object (F bit) can be used to 1229 indicate a fragmented PCEP message 1231 7. Example Workflows 1233 PCC-Initiated Workflow 1235 +-------+ +-------+ 1236 |PCC | | PCE | 1237 |Root | +-------+ 1238 +------| | | 1239 | PCC +-------+ | 1240 | Transit| | | 1241 +------| | |---PCRpt,PLSP-ID=1,D=1-------------->| PCECC LSP 1242 |PCC +--------+ | N=1,root-addr,tree-id=a, | SR-Policy 1243 | | | | instance-id =b, | Report to 1244 |Leaf | | | p2mp-end-points(LeafType=5) | PCE 1245 +--------+ | | | 1246 | | | | 1247 | | |<--PCUpdate,PLSP-ID=1, SRP-ID =1, | Update 1248 | | | root-addr,tree-id=a,instance-id=b,| CP 1249 | | | p2mp-end-points, association-obj | 1250 | | | | 1251 | | |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->| 1252 | | | root-addr,tree-id=a,instance-id=b,| 1253 | | | p2mp-end-points(LeafType=5) | 1254 | | | association-object, | 1255 | | | | 1256 |<---------------PCInitiate,PLSP-ID=0, -------------| Download 1257 | | | root-addr,tree-id=a,instance-id=0,| Leaf 1258 | | | CC-ID=Z,C=0, | Replication 1259 | | | O=0,L=z,path-attribute,ERO,SR-ERO | Segment(RS) 1260 | | | | 1261 |---------------------PCRpt,PLSP-ID=1-------------->| 1262 | | | root-addr,tree-id=a,instance-id=b,| 1263 | | | CC-ID=Z,Label=z,O=0, | 1264 | | | path-attribute,ERO,SR-ERO | 1265 | | | | 1266 | |<-------PCInitiate,PLSP-ID=0, -------------| Download 1267 | | | root-addr,tree-id=a,instance-id=0,| Transit 1268 | | | CC-ID=Y,C=0, | RS 1269 | | | O=0,L=y,path-attribute,ERO,SR-ERO | 1270 | | | | 1271 | |-------------PCRpt,PLSP-ID=2-------------->| 1272 | | | root-addr,tree-id=a,instance-id=c,| 1273 | | | CC-ID=Y,Label=y,O=0, | 1274 | | | path-attribute,ERO,SR-ERO | 1275 | | | | 1276 | | |<--PCInitiate,PLSP-ID=1, | Download 1277 | | | root-addr,tree-id=a,instance-id=b,| Root 1278 | | | CC-ID=X,C=0, | RS 1279 | | | O=0,L=x,p2mp-end- | 1280 | | | points(LeafType=5),path-attribute,| 1281 | | | ERO,SR-ERO | 1282 | | | | 1283 | | |-------PCRpt,PLSP-ID=1-------------->| 1284 | | | root-addr,tree-id=a,instance-id=b,| 1285 | | | CC-ID=X,Label=x,O=0, | 1286 | | | p2mp-end-points(LeafType=5) | 1287 | | | path-attriute,ERO,SR-ERO | 1288 | | | | 1289 | | |<--PCUpdate,PLSP-ID=1, SRP-ID =2, | 1290 | | | root-addr,tree-id=a,instance-id=b,| Activate 1291 | | | p2mp-end-points | CP to last 1292 | | | | RS 1293 | | |-------PCRpt,PLSP-ID=1, SRP-ID =2, ->| 1294 | | | root-addr,tree-id=a,instance-id=b,| 1295 | | | p2mp-end-points(LeafType=5) | 1296 | | | | 1298 Note that on transit / leaf Initiate is with PLSP-ID = 0. Therefore 1299 PLSP-ID is locally unique to a node. It should be noted that the CC- 1300 ID does not need to be constant across all nodes that make up the 1301 path. 1303 PCE-Initiated workflow 1305 +-------+ +-------+ 1306 |PCC | | PCE | 1307 |Root | +-------+ 1308 +------| | | 1309 | PCC +-------+ | 1310 | Transit| | | 1311 +------| | | | PCECC LSP 1312 |PCC +--------+ | | 1313 | | | | | 1314 |Leaf | | | | 1315 +--------+ | | | 1316 |<---------------PCInitiate,PLSP-ID=0, -------------| Download 1317 | | | root-addr,tree-id=a,instance-id=0,| Leaf RS 1318 | | | CC-ID=Z,C=0, | 1319 | | | O=0,L=z,path-attribute,ERO,SR-ERO | 1320 | | | | 1321 |---------------------PCRpt,PLSP-ID=1-------------->| 1322 | | | root-addr,tree-id=a,instance-id=b,| 1323 | | | CC-ID=Z,Label=z,O=0, | 1324 | | | path-attribute,ERO,SR-ERO | 1325 | | | | 1326 | |<-------PCInitiate,PLSP-ID=0, -------------| Download 1327 | | | root-addr,tree-id=a,instance-id=0,| Transit RS 1328 | | | CC-ID=Y,C=0, | 1329 | | | O=0,L=y,path-attribute,ERO,SR-ERO | 1330 | | | | 1331 | |-------------PCRpt,PLSP-ID=2-------------->| 1332 | | | root-addr,tree-id=a,instance-id=c,| 1333 | | | CC-ID=Y,Label=y,O=0, | 1334 | | | path-attribute,ERO,SR-ERO | 1335 | | | | 1336 | | |<--PCInitiate,PLSP-ID=0, | Initiate 1337 | | | root-addr,tree-id=0,instance-id=0,| CP 1338 | | | p2mp-end-points, association-obj | 1339 | | | | 1340 | | |-------PCRpt,PLSP-ID=1,------------->| 1341 | | | root-addr,tree-id=a,instance-id=b,| 1342 | | | p2mp-end-points(LeafType=5) | 1343 | | | association-object, | 1344 | | | | 1345 | | |<--PCInitiate,PLSP-ID=1, | Download 1346 | | | root-addr,tree-id=a,instance-id=b,| Root RS 1347 | | | CC-ID=X,C=0, | 1348 | | | O=0,L=x,p2mp-end- | 1349 | | | points(LeafType=5),path-attribute,| 1350 | | | ERO,SR-ERO | 1351 | | | | 1352 | | |-------PCRpt,PLSP-ID=1-------------->| 1353 | | | root-addr,tree-id=a,instance-id=b,| 1354 | | | CC-ID=X,Label=x,O=0, | 1355 | | | p2mp-end-points(LeafType=5) | 1356 | | | path-attriute,ERO,SR-ERO | 1357 | | | | 1358 | |<-------PCInitiate,PLSP-ID=0, -------------| 1359 | | | root-addr,tree-id=a,instance-id=0,| 1360 | | | CC-ID=Y,C=0, | 1361 | | | O=0,L=y,path-attribute,ERO,SR-ERO | 1362 | | | | 1363 | |-------------PCRpt,PLSP-ID=2-------------->| 1364 | | | root-addr,tree-id=a,instance-id=c,| 1365 | | | CC-ID=Y,Label=y,O=0, | 1366 | | | path-attribute,ERO,SR-ERO | 1367 | | | | 1368 | | |<--PCUpdate,PLSP-ID=1, SRP-ID =1, | Bind and 1369 | | | root-addr,tree-id=a,instance-id=b,| Activate 1370 | | | p2mp-end-points, | CP to last 1371 | | | | RS 1372 | | |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->| 1373 | | | root-addr,tree-id=a,instance-id=b,| 1374 | | | p2mp-end-points(LeafType=5) | 1376 MBB Workflow: 1378 Common (PCE-INIT, PCC-INIT) MBB 1380 +-------+ +-------+ 1381 |PCC | | PCE | 1382 |Root | +-------+ 1383 +------| | | 1384 | PCC +-------+ | 1385 | Transit| | | 1386 +------| | | | PCECC LSP 1387 |PCC +--------+ | | 1388 | | | | | 1389 |Leaf | | | | 1390 +--------+ | | | 1391 |<---------------PCInitiate,PLSP-ID=1, -------------| Download 1392 | | | root-addr,tree-id=a,instance-id=b,| new RS on 1393 | | | CC-ID=Z1,C=0, | Leaf 1394 | | | O=0,L=z1,path-attribute,ERO,SR-ERO | 1395 | | | | 1396 |---------------------PCRpt,PLSP-ID=1-------------->| 1397 | | | root-addr,tree-id=a,instance-id=b,| 1398 | | | CC-ID=Z1,Label=z1,O=0, | 1399 | | | path-attribute,ERO,SR-ERO | 1400 | | | | 1401 | |<-------PCInitiate,PLSP-ID=2, -------------| Download 1402 | | | root-addr,tree-id=a,instance-id=c,| new RS on 1403 | | | CC-ID=Y1,C=0, | Transit 1404 | | | O=0,L=y1,path-attribute,ERO,SR-ERO | 1405 | | | | 1406 | |-------------PCRpt,PLSP-ID=2-------------->| 1407 | | | root-addr,tree-id=a,instance-id=c,| 1408 | | | CC-ID=Y1,Label=y1,O=0, | 1409 | | | path-attribute,ERO,SR-ERO | 1410 | | | | 1411 | | |<--PCInitiate,PLSP-ID=1, | Download 1412 | | | root-addr,tree-id=a,instance-id=b,| new RS on 1413 | | | CC-ID=X1,C=0, | Root 1414 | | | O=0,L=x1,p2mp-end- | 1415 | | | points(LeafType=5),path-attribute,| 1416 | | | ERO,SR-ERO | 1417 | | | | 1418 | | |-------PCRpt,PLSP-ID=1-------------->| 1419 | | | root-addr,tree-id=a,instance-id=b,| 1420 | | | CC-ID=X1,Label=x1,O=0, | 1421 | | | p2mp-end-points(LeafType=5) | 1422 | | | path-attriute,ERO,SR-ERO | 1423 | | | | 1424 | | |<--PCUpdate,PLSP-ID=1, SRP-ID =1, | Bind and 1425 | | | root-addr,tree-id=a,instance-id=b,| Activate 1426 , | | | p2mp-end-points, | CP to last 1427 | | | | RS 1428 | | |-------PCRpt,PLSP-ID=1, SRP-ID = 1,->| 1429 | | | root-addr,tree-id=a,instance-id=b,| 1430 | | | p2mp-end-points(LeafType=5) | 1431 | | | | 1432 | | |<--PCInitiate,PLSP-ID=1,R=1 | Remove 1433 | | | root-addr,tree-id=a,instance-id=b,| the old RS 1434 | | | CC-ID=X1,C=0 | from Leaf 1435 | | | O=0,L=x1,p2mp-end- | 1436 | | | points(LeafType=5),path-attribute,| 1437 | | | ERO,SR-ERO | 1438 | | | | 1439 | | |-------PCRpt,PLSP-ID=1, R=1--------->| 1440 | | | root-addr,tree-id=a,instance-id=b,| 1441 | | | CC-ID=X1,Label=x1,O=0, | 1442 | | | p2mp-end-points(LeafType=5) | 1443 | | | path-attriute,ERO,SR-ERO | 1444 | | | | 1445 | |<-------PCInitiate,PLSP-ID=2, R=1----------| Remove the 1446 | | | root-addr,tree-id=a,instance-id=c,| old RS from 1447 | | | CC-ID=Y1,C=0, | Transit 1448 | | | O=0,L=y1,path-attribute,ERO,SR-ERO | 1449 | | | | 1450 | |-------------PCRpt,PLSP-ID=2, R=1--------->| 1451 | | | root-addr,tree-id=a,instance-id=c,| 1452 | | | CC-ID=Y1,Label=y1,O=0, | 1453 | | | path-attribute,ERO,SR-ERO | 1454 | | | | 1455 |<---------------PCInitiate,PLSP-ID=1,R=1-----------| Remove the 1456 | | | root-addr,tree-id=a,instance-id=b,| old RS from 1457 | | | CC-ID=Z1,C=0, | Root 1458 | | | O=0,L=z1,path-attribute,ERO,SR-ERO | 1459 | | | | 1460 |---------------------PCRpt,PLSP-ID=1,R=1---------->| 1461 | | | root-addr,tree-id=a,instance-id=b,| 1462 | | | CC-ID=Z1,Label=z1,O=0, | 1463 | | | path-attribute,ERO,SR-ERO | 1465 8. IANA Consideration 1467 1. This draft extends the PCEP OPEN object by defining an optional 1468 TLV to indicate the PCE's capability to perform SR-P2MP path 1469 computations with a new IANA capability type (TBD). 1471 2. PCEP open object with a new association type " P2MP SR Policy 1472 Association " value (TBD). 1474 3. A new Association type. Association type = TBD1 "P2MP SR Policy 1475 Association Type" for SR Policy Association Group (P2MP SRPAG) 1477 1. three new TLVs are identified to carry association 1478 information: P2MP-SRPAG- POL-ID-TLV, P2MP-SRPAG-CPATH-ID-TLV, 1479 P2MP-SRPAG-CPATH-ATTR-TLV 1481 4. Two new TLVs for Identifying the P2MP Policy and the Replication 1482 segment SR-IPV4-P2MP-POLICY-ID TLV and SR-IPV6-P2MP-POLICY-ID TLV 1484 5. A new SR-P2MP-NODE-ROLE TLV (Type To be assigned by IANA) that 1485 will be present in the PATH-ATTRIB object 1487 9. Security Considerations 1489 TBD 1491 10. Acknowledgments 1493 The authors would like to thank Tanmoy Kundu and Stone Andrew at 1494 Nokia for their feedback and major contribution to this draft. 1496 11. References 1498 11.1. Normative References 1500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1501 Requirement Levels", BCP 14, RFC 2119, 1502 DOI 10.17487/RFC2119, March 1997, 1503 . 1505 11.2. Informative References 1507 [draft-barth-pce-segment-routing-policy-cp] 1508 . 1510 [draft-dhs-spring-sr-p2mp-policy-yang] 1511 . 1513 [draft-ietf-pce-multipath] 1514 . 1516 [draft-ietf-pce-pcep-extension-for-pce-controller] 1517 . 1519 [draft-ietf-pce-segment-routing-policy-cp] 1520 . 1522 [draft-ietf-pce-stateful-pce-p2mp] 1523 . 1525 [draft-ietf-pim-sr-p2mp-policy] 1526 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 1527 "draft-voyer-pim-sr-p2mp-policy"", October 2019. 1529 [draft-ietf-spring-segment-routing-policy] 1530 . 1532 [draft-ietf-spring-sr-replication-segment] 1533 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 1534 "draft-voyer-pim-sr-p2mp-policy "draft-voyer-spring-sr- 1535 replication-segment"", July 2020. 1537 [draft-parekh-bess-mvpn-sr-p2mp] 1538 . 1540 [draft-sivabalan-pce-binding-label-sid] 1541 . 1543 [RFC3209] . 1545 [RFC5440] . 1547 [RFC6513] . 1549 [RFC8231] . 1551 [RFC8236] . 1553 [RFC8281] . 1555 [RFC8306] . 1557 [RFC8664] . 1559 [RFC8697] . 1561 Authors' Addresses 1563 Hooman Bidgoli (editor) 1564 Nokia 1565 Ottawa 1566 Canada 1568 Email: hooman.bidgoli@nokia.com 1570 Daniel Voyer 1571 Bell Canada 1572 Montreal 1573 Canada 1575 Email: daniel.yover@bell.ca 1576 Saranya Rajarathinam 1577 Nokia 1578 Mountain View 1579 US 1581 Email: saranya.Rajarathinam@nokia.com 1583 Ehsan Hemmati 1584 Cisco System 1585 San Jose 1586 USA 1588 Email: ehemmati@cisco.com 1590 Tarek Saad 1591 Juniper Networks 1592 Ottawa 1593 Canada 1595 Email: tsaad@juniper.com 1597 Siva Sivabalan 1598 Ciena 1599 Ottawa 1600 Canada 1602 Email: ssivabal@ciena.com