idnits 2.17.1 draft-dhs-spring-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1873 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 128 looks like a reference -- Missing reference section? 'RFC3209' on line 178 looks like a reference -- Missing reference section? 'RFC8231' on line 354 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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. Yoyer, Ed. 5 Bell Canada 6 S. Rajarathinam 7 J. Kotalwar 8 Nokia 9 S. Sivabalan 10 Cisco System, Inc. 12 Expires: September 12, 2019 March 11, 2019 14 PCEP extensions for p2mp sr policy 15 draft-dhs-spring-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 . . . . . . . . . . . . . . . 3 66 3. Overview of PCEP Operation in SR P2MP Network . . . . . . . . . 3 67 3.1. P2MP Identification . . . . . . . . . . . . . . . . . . . . 4 68 3.2 High-Level Procedures for P2MP SR LSP Instantiation . . . . 4 69 3.2.1. New Objects for SR P2MP LSP instantiation . . . . . . . 5 70 3.3. High-Level Procedures for P2MP Global Optimization . . . . 5 71 3.4. High-Level Procedures for Fast Reroute . . . . . . . . . . 6 72 4. Object Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.1. Open Message and Capability Exchange . . . . . . . . . . . 7 74 4.2. Symbolic Name in PCInitiate message from PCC . . . . . . . 7 75 4.3. PCE Update, Root Report message . . . . . . . . . . . . . . 8 76 4.3.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV . . . . . 8 77 4.3.2 END-POINTS Objects . . . . . . . . . . . . . . . . . . . 9 78 4.4. PCInitiate Message and P2MP Tree Instantiation . . . . . . 12 79 4.4.1. New SR-P2MP-CCI Object . . . . . . . . . . . . . . . . 13 80 4.4.2. New Optional IPv4-ADDRESS TLV . . . . . . . . . . . . . 13 81 4.4.3. UNNUMBERED IPV4-ID-ADDRESS TLV: . . . . . . . . . . . . 15 82 4.4.4. New Optional IPv6-ADDRESS TLV . . . . . . . . . . . . . 15 83 4.5. Global Optimization and Make Before Break . . . . . . . . . 15 84 4.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 16 85 5. Example workflow . . . . . . . . . . . . . . . . . . . . . . . 16 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 The draft draft-voyer-spring-sr-p2mp-policy defines a variant of the 97 SR Policy [I-D. ietf-spring-segment-routing-policy] for constructing 98 a P2MP segment to support multicast service delivery. We call it an 99 SR Replication Policy. 101 A Point-to-Multipoint (P2MP) segment connects a Root node to a set of 102 Leaf nodes in a Segment Routing Domain. We define two types of a P2MP 103 segment: Spray and Tree. 105 Spray P2MP segment enables a Root node to directly replicate a packet 106 using a SR path to each Leaf node. 108 For a TreeSID P2MP segment, a controller computes a tree from a Root 109 node to a set of Leaf nodes via a set of Replication nodes. A packet 110 is replicated at the Root node and on Replication nodes towards each 111 Leaf node. 113 For a TreeSID the tree can be built manually via the PCE or PCC by 114 indicating the root and the leaves or dynamically via MVPN 115 procedures, where the root of a tree discovers the leafs via MVPN 116 procedures and updates the PCE of the root and the set of leaves. In 117 either case the PCE computes and programs the P2MP Tree on the PCCs. 119 In all of above cases a set of new PCEP object and TLVs are needed to 120 update and instantiate the P2MP tree. This draft explains the 121 procedure needed to instantiate a P2MP TreeSID. 123 2. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Overview of PCEP Operation in SR P2MP Network 131 For a Tree P2MP SR policy, TreeSID network, a PCE calculates a P2MP 132 tree and programs the Root, Replication and Leaf nodes with 133 information needed to forward a multicast stream from the root to a 134 set of leaves. The PCE discovers the Root and the set of the Leaves 135 via manual configuration on the PCE or PCC providing the PCE with the 136 relevant information. The PCC can discover the Root and the leaves 137 via MVPN procedures or via manual configuration. 139 After discovering the Root and Leaves and computing the MPLS P2MP 140 Tree and identifying the Replication routers, the PCE programs the 141 PCCs with relevant information needed to create a P2MP Tree from the 142 Root to the set of the Leaves. This information specifies label 143 operation on the relevant nodes. As an example for a label Push 144 operation, outgoing interface and their corresponding labels are 145 programmed on the PCC via the PCE. In the case of swap operation, an 146 incoming label and a set of outgoing interfaces and their 147 corresponding labels are programmed on the PCCs. In the Case of pop 148 operation, incoming label that needs to be removed is programmed. PCE 149 could also calculate and download additional information such as 150 next-hops for link/node protection or initiate a make-before-brake 151 for P2MP Path optimization. 153 3.1. P2MP Identification 155 The key to identify a P2MP LSP is in LSP object and is as follow: 157 PLSP-ID: RFC 8231, is assigned by PCC and is unique per LSP that is 158 constant for the lifetime of a PCEP session. When an LSP is being 159 globally optimized it will maintain its PLSP-ID over the 2 instances 160 of the LSP, the current LSP and the new optimized LSP. It is possible 161 to establish standby P2MP LSPs to protect primary P2MP SR policies, 162 and standby P2MP LSPs can be co-exist along with primary P2MP LSP. 163 Since PLSP-ID is unique per LSP, each standby P2MP LSP has a unique 164 PLSP-ID. 166 LSP-ID: is assigned by PCE for each PLSP-ID. It is used for global 167 optimization of an existing LSP via Make-Before-Break (MBB) 168 procedures. An optimized P2MP LSP is instantiated with the same PLSP- 169 ID but a unique LSP-ID. MBB procedures first switches traffic from 170 the previous to the new P2MP LSP, and then destroys the previous P2MP 171 LSP. 173 P2MP-ID: is equivalent to Path Identifier which identifies a unique 174 P2MP segment at a ROOT and is advertised via the PTA in the BGP AD 175 route. 177 IPv4/IPv6 Sender Address: is equivalent to the first MPLS node on the 178 path, as per [RFC3209], Section 4.6.2.1 180 3.2 High-Level Procedures for P2MP SR LSP Instantiation 182 A P2MP LSP's ROOT and Leaves can be discovered via MVPN procedures or 183 static configuration of the ROOT and Leaves on the PCE or PCC. 185 In case of MVPN Procedures, PCC will use Report messages to update 186 the PCE with discovered leaf or a set of leaves as per P2MP [draft- 187 sr-mvpn-procedure or alike]. PCC will assign a PLSP-ID and use the 188 P2MP-ID it had specified in the BGP MVPN PTA. PCC will update the PCE 189 with the root and discovered leaves via a PCRpt message. Note the 190 LSP-ID will be set to 0 or NA in this first report message as the PCE 191 has not instantiated the P2MP LSP yet. 193 PCE will instantiate the P2MP LSP and update PCC (root, transit and 194 leaves) via a PCInit message. The PCInit message will contain a valid 195 LSP-ID assigned by PCE for this P2MP path. It will also download the 196 corresponding label and local protection (Fast Re-Route) information. 198 In short, each P2MP LSP will have a unique PLSP-ID assigned by PCC 199 and LSP-ID assigned by PCE. This is true for LSP redundancy where the 200 Primary LSP is protected by one or multiple backup LSPs. The backup 201 LSPs will have a unique PLSP-ID and LSP-ID. PCE will use the same 202 PLSP-ID and LSP-ID for any new leaves that are discovered from here 203 on. If these leaves are discovered on routers that are part of the 204 P2MP LSP path, then PCUpd is sent from PCE to necessary PCCs (root, 205 transit and leaves) with the PLSP-ID and LSP-ID. If the new leaves 206 are discovered that are not part of the P2MP Tree yet, then an PCInit 207 message is sent down to the relevant transit and/or leaf nodes with 208 the current PLSP-ID and LSP-ID. 210 3.2.1. New Objects for SR P2MP LSP instantiation 212 A new object is defined for the controller to specify 213 the forwarding instructions (label instructions). This can be 214 included in PcRpt, PcInitiate and PcUpd messages. 216 It should be noted that every PcRpt, PcInitiate and PCUpd messages 217 will contain full list of the Leaves and labels and forwarding 218 information that is needed to build the P2MP LSP. They will never 219 send the delta information related to the new leaves that need to be 220 added or updated. This is necessary to ensure that PCE or any new 221 discovered PCE is in sync with the PCC. 223 As such when a PcReport, PcInitiate and PCUPdate messages is send via 224 PCEP it maintains the previous instruction CC-IDs and create new CC- 225 ID for the new instruction. This means the CC-IDs are maintained for 226 each specific forwarding and label instructions until these 227 instructions are deleted. 229 3.3. High-Level Procedures for P2MP Global Optimization 231 When a P2MP LSP needs to be optimized for any reason (i.e. it is 232 taking a FRR Path or new routers are added to the network) a global 233 optimization is possible. After the optimized LSP is downloaded a MBB 234 procedure is performed and the previous instance of the LSP is 235 deleted and removed from the corresponding PCCs. The globally 236 optimized LSP is instantiated via the PCInitiate message. The PLSP-ID 237 of this optimized LSP is same as the Current LSP which is being 238 optimized. That said the LSP-ID of the optimize LSP is uniquely 239 assigned by PCE and is different from that of thecurrent LSP which is 240 being optimized. In short, the LSP-ID uniquely identifies sub- 241 instances of an LSP for optimization. After the optimized LSP has 242 been downloaded and verified via PCC PCRpt message, the MBB procedure 243 can be performed to switch between the 2 instances of the LSP. The 244 previous instance will be removed from PCCs. 246 3.4. High-Level Procedures for Fast Reroute 248 Currently this draft identifies the Facility FRR procedures. In 249 addition, only LINK Protection procedures are defined. How the 250 Facility Path is built and instantiated is beyond the scope of this 251 document. 253 R 254 | | 255 T 256 | 257 --- 258 | | 259 L1 L2 261 Figure 1 263 R---F1 264 | | 265 T---F2 266 | 267 --- 268 | | 269 L1 L2 271 Figure 2 273 As an example, the bypass path (unicast bypass) between the PLR and 274 MP can be constructed via SR. The PCE needs to only update the PLR 275 PCC with bypass path outgoing label and nexthop information, also PCE 276 needs to update the MP PCC with bypass path ILM information. This 277 information is presented via a P bit in the optional IPv4/IPv6- 278 Address object as per section 4.4.2, 4.4.3, 4.4.4. 280 If one to one FRR is needed, then a second flag O should be defined 281 in the IPv4/IPv6-Address object in future. 283 As an example, in figure 1 the detour path between R and T is the 2nd 284 fiber between these nodes. As such the bypass path could be setup on 285 the 2nd fiber using treeSID procedures. That said in figure 2 the 286 bypass path is traversing multiple nodes and this example a unicast 287 SR path might be ideal for setting up the detour path. The PCE can 288 download the prefix SID for F2 as a bypass path for R-T to R. 289 Downloading the prefix SID for F2 will ensure an LFA detour for R-T. 290 In addition, PHP procedure and implicit null label on the bypass path 291 can be implemented to reduce the PCE programming on the MP PCC. 293 4. Object Format 295 4.1. Open Message and Capability Exchange 297 Format of the open object 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Ver | Flags | Keepalive | DeadTimer | SID | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 // Optional TLVs // 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 All the nodes need to establish a PCEP connection with the PCE. 310 During PCEP session establishment phase, PCEP Speakers advertise 311 their capabilities to support PCECC extensions to include the new 312 Path Setup Type as per draft-ietf-pce-pcep-extension-for-pce- 313 controller-00. In addition they need to set flags N, M, P in the 314 STATEFUL-PCE-CAPABILITY TLV as defined in draft-ietf-pce-stateful- 315 pce-p2mp-08 section-5.2. 317 We extend the PCEP OPEN object by defining an optional TLV to 318 indicate the PCE's capability to perform SR-P2MP path computations, 319 New IANA capability type. The inclusion of this TLV in an OPEN object 320 indicates that the sender can perform SR-P2MP path computations. This 321 will be similar to the P2MP-CAPABILITY defined in rfc8306 section- 322 3.1.2 and a new value needs to be defined for SR-P2MP. 324 4.2. Symbolic Name in PCInitiate message from PCC 326 As per RFC8231 section 7.3.2. a Symbolic Path Name TLV should 327 uniquely identify the P2MP path on the PCC. This symbolic path name 328 is a human-readable string that identifies an P2MP LSP in the 329 network. It needs to be constant through the life time of the P2MP 330 path. 332 As an example in the case of P2MP LSP the symbolic name can be the 333 source IP + P2MP-ID of the LSP. The P2MP-ID is a unique ID that 334 identifies the P2MP on the Root (Source) as such the combination of 335 Source IP + P2MP-ID will provide the P2MP LSP with a unique 336 identification throughout the network. Depending on the Source IP, 337 IPv4 vs. IPv6, the length of the TLV will vary. 339 4.3. PCE Update, Root Report message 341 The Root node on reception of a P2MP path request, via MVPN 342 procedures or manual Configuration on the PCCs, will initiates an 343 Report to PCE through a PCRpt message. 345 The format of the PC Report message is as follows: 347 348 [] 349 350 [ | ] 352 4.3.1 Extension of the LSP Object, SR-P2MP-LSPID-TLV 354 The LSP Object is defined in Section 7.3 of [RFC8231]. It specifies 355 the PLSP-ID to uniquely identify an LSP that is constant for the life 356 time of a PCEP session. Similarly for a P2MP tunnel, the PLSP-ID 357 identify a P2MP TE LSP uniquely. 359 The LSP Object MUST include the new SR-P2MP-LSPID-TLV (IPV4/IpV6). 360 This is a variation to the P2MP object defined in draft-ietf-pce- 361 stateful-pce-p2mp-08 363 SR-IPV4-P2MP-LSP-IDENTIFIER TLV: 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type=TBD | Length=12 | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | LSP ID | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | IPv4 Tunnel Sender Address | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | P2MP ID(color) | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 SR-IPV6-P2MP-LSP-IDENTIFIER TLV : 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type=TBD | Length=20 | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | LSP ID | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 + + 385 | IPv6 tunnel sender address | 386 + (16 octets) + 387 | | 388 + + 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | P2MP ID(color) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 The type (16-bit) of the TLV is TBD (need allocation by IANA). 396 LDS ID: is a unique ID assigned by PCE to indicate sub-instances of 397 an P2MP LSP for global or local optimization 399 IPv4/IPv6 Sender address: contains the sender node's IP address (Root 400 Node) 402 P2MP ID (Color): contains the 32-bit 'P2MP ID' identifier used in the 403 PTA of BGP AD Route. 405 4.3.2 END-POINTS Objects 407 In order for the Root to indicate the leaves and its corresponding 408 operation (Add/Remove/Modify/DoNotModify), the PC Report message is 409 extended to include P2MP End Point Object which is 410 defined in rfc8306 412 IPV4-P2MP END-POINTS: 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Leaf type | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Source IPv4 address | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Destination IPv4 address | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 ~ ... ~ 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Destination IPv4 address | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 IPV6-P2MP END-POINTS: 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Leaf type | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 | Source IPv6 address (16 bytes) | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | 438 | Destination IPv6 address (16 bytes) | 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 ~ ... ~ 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 | Destination IPv6 address (16 bytes) | 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Leaf Types (derived from RFC 8306 section 3.3.2) : 450 1.New leaves to add (leaf type = 1) 452 2.Old leaves to remove (leaf type = 2) 454 3.Old leaves whose path can be modified/reoptimized (leaf type 455 = 3), Future reserved not used for tree SID as of now. 457 4.Old leaves whose path must be left unchanged (leaf type = 4) 459 A given P2MP END-POINTS object gathers the leaves of a given type. 461 Note that a P2MP report can mix the different types of leaves by 462 including several P2MP END-POINTS objects. The END-POINTS object body 463 has a variable length. These are multiples of 4 bytes for IPv4, 464 multiples of 16 bytes, plus 4 bytes, for IPv6. 466 A sample Report message of a P2MP tunnel request, and leaf Add 467 report is noted below: 469 Note as it was mentioned before: 471 P2MP-ID (color) = Tunnel Identifier color which identifies a 472 unique P2MP segment at the Root and is advertised via the PTA 473 (BGP) 475 LSP ID is used for Global optimization of the P2MP Tree. 476 contains the 16-bit 'LSP ID' identifier 478 P2MP Tunnel Request, Report generated by the Root to the PCE. The 479 Root should populate the Tunnel-sender Addr, P2MP-ID(color), PLSP-ID. 480 While the LSP ID is set to 0 for the PCE to assign. 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Flags = 0 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | SRP-ID-number = 0 | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | PST = TBD | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | PLSP-ID = X | A:1,D:1,N:1 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type=TBD | Length=8 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | LSP ID = 0 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | IPv4 Tunnel Sender Address = x.y.z.w | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | P2MP_ID(color) = Y | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Report generated by the Root to the PCE for Leaf Add 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Flags = 0 | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | SRP-ID-number = 0 | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | TLV Type = 28 (PathSetupType)| TLV Len = 4 | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | PST = TBD | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | PLSP-ID = X | A:1,D:1,N:1 | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Type=TBD | Length=8 | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | LSP ID = 0 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | IPv4 Tunnel Sender Address = x.y.z.w | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | P2MP_ID(color) = Y | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Leaf type =1 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Source IPv4 address = x.y.z.w | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Destination IPv4 address = a.b.c.d | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Destination IPv4 address = a.b.c.e | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 4.4. PCInitiate Message and P2MP Tree Instantiation 535 In response to a new leaf add PCRpt message, the PCE calculates the 536 path and assigns labels along the path and sets up the path by 537 sending a PCInitiate Message(label download) to each node along the 538 path (Root, transits nodes and leaves). A new object is 539 defined for the controller to specify the forwarding instructions 540 (label instructions). This can be included in PCRpt, PcInitiate and 541 PcUpdate messages. 543 For optimization it is recommended for the PCE to send the PCInitiate 544 message starting from the LEAVES to the Transit nodes and finally the 545 Root. 547 The transit and leaf nodes generate a Path Computation State Report 548 (PCRpt) with SR-P2MP-LSP-ID TLV and SR-P2MP-CCI object to indicate 549 the state of the label download. Once the controller gets a report 550 from all the leaves and transit nodes that the label download was 551 successful, it will send a PCInit Message with the SR-P2MP-CCI 552 object(label instruction) to the Root node. 554 A successful report (including SR-P2MP-CCI object and P2MP LSP ID 555 TLV) back from the root for the label download, means the P2MP policy 556 is successfully UP. The PLSP-ID used in the PCInitiate message is the 557 original identifier used by the ingress PCC, so the transit LSR could 558 have multiple central controller instructions that have the same 559 PLSP-ID. The PLSP-ID in combination with the SR-P2MP-LSP-ID-TLV MUST 560 be unique. 562 Format of PC Initiate Message: 563 564 565 566 568 Format of Pc Update Message: is like PC Initiate Message, but the 569 Create Bit in the LSP Object will be Set to 0. 571 4.4.1. New SR-P2MP-CCI Object 573 This is a variation of the CC-ID object defined in draft-ietf-pce- 574 pcep-extension-for-pce-controller-00 SR-P2MP-CCI Object-Class is TBD. 576 CCI Object-Type is 1 for the MPLS Label. 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | CC-ID | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Reserved | Flags |0| 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 // Optional TLV // 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 589 creates an CC-ID for each instruction, the value is unique within 590 the scope of the PCE and is constant for the lifetime of a PCEP 591 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 592 used. 594 Flags: O - 0 - Down - means label download was not successful 1 - 595 Up - means label download was successful 597 4.4.2. New Optional IPv4-ADDRESS TLV 598 The IP-Address TLVs download the label and its instructions to the 599 PCC. These instructions could include information about local 600 Protection information or if the label is an incoming label or an 601 outgoing label. Additionally they could identify a node as a BUD node 602 or just a transit node. 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Type=TBD | Length = 12 | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Label | Rsvd | Flag|I|B|S|E|P| 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | IPv4 address | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Interface ID | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Flags: 617 I - Incoming Label: If set means In Label, If not set means 618 Out Label. 620 B - Bud Node Label: If set this label is a bud node, the 621 payload needs to be processed locally and also replicated if 622 the S bit is set. In short if B is set then S needs to set 623 also. 625 S - SWAP label: 627 0: If I bit is set and S bit is 0 it means pop the label 628 and if the label's S bit is set do a recursive lookup. 630 1 - If I bit is set and S bit is 1 it means swap this 631 label with out label. 633 P - Protection NextHop 635 0 - Label information is not w.r.t protection next-hop. 637 1 - Label information is w.r.t protection next-hop. 639 Note: P flag is used at the PLR and MP to identify the 640 facility tunnel. 642 E - Protected LTN, This bit is usually set with the an 643 outgoing label, when the outgoing label is protected via a 644 protection nextHop 646 0 - Label information does not have a protection next- 647 hop. 649 1 - Label information has a protection next-hop. 651 IPV4 address and Interface Id: correspond to the next-hop information 652 in case of an OUT Label, and it corresponds to incoming interface 653 information if it is an IN Label. 655 4.4.3. UNNUMBERED IPV4-ID-ADDRESS TLV: 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type=TBD | Length = 16 | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Label | Rsvd | Flag|I|B|S|E|P| 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Node-ID | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Interface ID | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 4.4.4. New Optional IPv6-ADDRESS TLV 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Type=TBD | Length = 24 | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Label | Rsvd | Flag|I|B|S|E|P| 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | | 677 // IPv6 address (16 bytes) // 678 | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Interface ID | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 4.5. Global Optimization and Make Before Break 685 If controller optimizes a tree for any reason, it will download the 686 tree with same PLSP-ID and P2MP-ID (Color) but a new LSP-ID . 688 The new optimize LSP is downloaded via the same mechanisms explained 689 above and a new LSP-ID for this instance of the LSP. 691 After the new tree is established and the report messages arrive from 692 the source, transit and leaf nodes confirming successful download, 693 the previous tree is deleted starting from the root. This delete of 694 the previous LSP-ID will force the root to do a switch (MBB) to the 695 new LSP-ID P2MP tree. 697 4.6. Tree Deletion 699 To delete the entire tree (P2MP LSP) , Root send a PCRpt message with 700 the R bit of the LSP object set and all the fields of the SR-P2MP- 701 LSP-ID TLV set to 0(indicating to remove all state associated with 702 this P2MP tunnel). The controller in response sends a PCInitiate 703 message with R bit in the SRP object SET to all nodes along the path 704 to indicate deletion of a label entry. 706 4.7. Fragmentation 708 The Fragmentation bit in the LSP object (F bit) can be used to 709 indicate a fragmented PCEP message. 711 5. Example workflow 713 In the workflow below after discovering the root and leaf nodes via 714 MVPN procedures the root generates a PCRpt message to the PCE with 715 the discovered root and leaves via the endpoint objects, which in 716 order forces the PCE to compute the P2MP Tree and generates a 717 PCInititate to the Root, downloading the label information to the 718 Root, Bud/Transit and Leaves. 720 A PC Initiate message on Root,transit and leaf nodes - indicates a 721 new label instruction and the existing label instruction should 722 remain unmodified(if any present). If the old instructions are no 723 longer needed, a PC Update message indicating the old label 724 instructions and the R bit in the LSP object SET is sent to the 725 nodes(to remove the labels). 727 A PCUpd message on any node (root, transit or leaf) - indicates an 728 overwrite of the existing label instruction if any present. 730 A sample message flow is depicted below: 732 When leaves(C,D) are discovered, at R a PCInitiate with 2 label 733 instruction is instantiated by the PCE. The two labels correspond to 734 an egress label and a protection nextHop for FRR. The PCE will 735 download a PCInitiate message with CC-ID X, egress label(A), flag 736 E(as the Protection NextHOP CCID will Follow) and a IPv4 nextHop of 737 N1, in addition CC-ID Y = egress label (B), flag P(as it is a 738 protection NextHOP) and IPv4 nextHop of N2, are instantiated by the 739 PCE. 741 The Root will use a PCRpt message to acknowledge this initiate. 743 The PC will also download the necessary information to the 744 BUD/Transit router. In case of the BUD/Transit router the flags 745 are set. This means that for the incoming label the label 746 should be swapped with an outgoing label, but also the payload should 747 be replicated and a copy forwarded locally as there is a BUD present 748 on this router. 750 The BUD/Transit node will use a PCRpt message to acknowledge this 751 update as well. The Leafs (not shown) will also get the PCInit 752 message with Flag of only which indicates a pop and forward 753 operation. 755 N4-------------------- 756 | | 757 | +-------+ +-------+ +-------+ 758 | N3--|LEAF C | |LEAF D | | PCE | 759 | | | | | | +-------+ 760 +------| | | | | 761 N2---- | | | | | 762 |N1-- | Bud/ +-------+ +-------+ | 763 | | | Transit| | | | 764 +------| B | | | | 765 |ROOT +--------+ | | | 766 |A | | | | | 767 +--------+ | | | | 768 | | | | | 769 | MVPN Procedures to discover the ROOT and the LEAVES | 770 | | | | | 771 |---PCRpt:SRP-ID=TBD,PLSP-ID=1,S=A,P2MP-ID=A,LSP-ID=NA | 772 | endpoint=------------------->| 773 | | | | | 774 | | | | | 775 |<--PCInit:SRP-ID=1,PLSP-ID=1,S=A,P2MP-ID=A,LSP-ID=1 | 776 | | P2MPCCI:CCID=X,Flag=E,Label=A,IPv4=N1 -----| 777 | | P2MPCCI:CCID=Y,Flag=P,Label=B,IPv4=N2 | 778 | | | | | 779 |---PCRpt:SRP-ID=1,PLSP-ID=1,S=A,P2MP-ID=1,LSP-ID=1 | 780 | P2MPCCI:CCID=X,Y---------------------------->| 781 | | | | | 782 | | | | | 783 | |<-PCInit:SRP-ID=2,PLSP-ID=1,S=A,P2MP-ID=A | 784 | | | LSP-ID=1,---------------------- | 785 | | | P2MPCCI:CCID=X2,FLAG=,Label=C | 786 | | | P2MPCCI:CCID=Y2,FLAG=0,Label=D, | 787 | | | IPv4=N3 | 788 | | | P2MPCCI:CCID=Z2,FLAG=0,Label=E, | 789 | | | IPv4=N4 | 790 | | | | | 791 | | PCRpt:SRP-ID=2,PLSP-ID=1,S=A,P2MP-ID=A, | 792 | |------ LSP-ID=1,--------------------------->| 793 | | | P2MPCCI:CCID=X2,Y2,Z2 | 794 | | | | | 796 6. IANA Considerations 798 This document contains no actions for IANA. 800 7. Security Considerations 802 TBD 804 8. References 806 8.1. Normative References 808 8.2. Informative References 810 [sr-p2mp-policy] D. Yoyer, Ed., C. Hassen, K. Gillis, C. Filsfils, R. 811 Parekh, H.Bidgoli, "SR Replication Policy for P2MP Service Delivery", 812 draft-voyer-spring-sr-p2mp-policy-01, April 2019. 814 7. Acknowledgments 816 The authors would like to thank Tanmoy Kundu at Nokia for his 817 feedback and major contribution to this draft. 819 Authors' Addresses 821 Hooman Bidgoli 822 Nokia 823 600 March Rd. 824 Ottawa, Ontario K2K 2E6 825 Canada 827 Email: hooman.bidgoli@nokia.com 829 Daniel Voyer 830 Bell Canada 831 Montreal 832 CA 834 Email: daniel.voyer@bell.ca 836 Siva Sivabalan 837 Cisco Systems 838 Ottawa 839 Canada 841 Email: msiva@cisco.com 843 Jayant Kotalwar 844 Nokia 845 380 N Bernardo Ave, 846 Mountain View, CA 94043 847 US 849 Email: jayant.kotalwar@nokia.com 850 Saranya Rajarathinam 851 Nokia 852 380 N Bernardo Ave, 853 Mountain View, CA 94043 854 US 856 Email: saranya.rajarathinam@nokia.com