idnits 2.17.1 draft-zhang-pce-resource-sharing-14.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 (April 16, 2021) is 1105 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: 'TBD2' is mentioned on line 444, but not defined == Unused Reference: 'RFC8800' is defined on line 688, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Xian Zhang 2 Internet Draft Haomian Zheng 3 Category: Standards track Huawei Technologies 4 Oscar Gonzales de Dios 5 Victor Lopez 6 Telefonica I+D 7 Yunbin Xu 8 CAICT 10 Expires: October 16, 2021 April 16, 2021 12 Extensions to the Path Computation Element Protocol (PCEP) to Support 13 Resource Sharing-based Path Computation 15 draft-zhang-pce-resource-sharing-14 17 Abstract 19 Resource sharing in a network means two or more Label Switched Paths 20 (LSPs) use common pieces of resource along their paths. This can 21 help save network resources and is useful in scenarios such as LSP 22 recovery or when two LSPs do not need to be active at the same time. 23 A Path Computation Element (PCE) is responsible for path computation 24 with such requirement. 26 Existing extensions to the Path Computation Element Protocol (PCEP) 27 allow one path computation request for an LSP to be associated with 28 other (existing) LSPs through the use of the PCEP Association 29 Object. 31 This document extends PCEP in order to support resource-sharing- 32 based path computation as another use of the Association Object to 33 enable better efficiency in the computation and in the resultant 34 paths and network resource usage. 36 Status of this Memo 38 This Internet-Draft is submitted to IETF in full conformance with 39 the provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six 47 months and may be updated, replaced, or obsoleted by other documents 48 at any time. It is inappropriate to use Internet-Drafts as 49 reference material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on October 16, 2021. 59 Copyright Notice 61 Copyright (c) 2020 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with 69 respect to this document. Code Components extracted from this 70 document must include Simplified BSD License text as described in 71 Section 4.e of the Trust Legal Provisions and are provided without 72 warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction and Motivation .................................. 3 77 1.1. Requirements Language.................................... 4 78 2. Motivation ................................................... 5 79 2.1. Single Domain Use Case .................................. 5 80 2.2. Multiple Layers/Domains Use Case ........................ 6 81 2.3. Bulk Path Computation Use Case .......................... 8 82 3. Extensions to PCEP .......................................... 10 83 3.1. Association Group and Type ............................. 10 84 3.2. Resource Sharing TLV ................................... 10 85 3.3. Processing Rules ....................................... 11 86 4. Implementation Status ....................................... 12 87 5. Manageability Considerations ............................... 12 88 5.1. Control of Function and Policy ......................... 13 89 5.2. Information and Data Models ............................ 13 90 5.3. Liveness Detection and Monitoring ...................... 13 91 5.4. Verify Correct Operations .............................. 13 92 5.5. Requirements on Other Protocols ........................ 13 93 5.6. Impact on Network Operations ........................... 13 94 6. Security Considerations ..................................... 13 95 7. IANA Considerations ......................................... 14 96 7.1. Association Object Type Indicators ..................... 14 97 7.2. PCEP TLV Definitions ................................... 14 98 8. References .................................................. 15 99 8.1. Normative References ................................... 15 100 8.2. Informative References ................................. 16 101 9. Acknowledgements ............................................ 17 102 10. Contributor's Address ...................................... 17 103 11. Authors' Addresses ......................................... 17 105 1. Introduction and Motivation 107 A Path Computation Element (PCE) is a way to provide path 108 computation function, and it is especially useful in the scenarios 109 where complex constraints and/or a demanding amount of computation 110 resource are required [RFC4655]. The development of PCE 111 standardization has evolved from stateless to stateful. A stateful 112 PCE has access to the LSP database information of the networks it 113 serves as a computation engine [RFC8231]. Unless specified, this 114 document assumes a PCE mentioned is a stateful PCE. 116 Resource sharing denotes that two or more Label Switched Paths 117 (LSPs) share common pieces of resource, (such as a common time slot 118 of a link in an Optical Transport Network (OTN)). This is usually 119 useful in the scenario where only one of the LSPs is active and the 120 benefit is to save network resources. A simple example of this is 121 dynamically calculating a recovery LSP for an existing LSP 122 undergoing a link failure. Note that resource sharing can be worked 123 out using a stateless PCE, but the mechanism may be complex and is 124 out the scope of this document. 126 This document considers the requirement that a new LSP may request 127 for resource sharing with one or multiple existing LSPs. Furthermore, 128 if there is resource sharing between a new LSP and existing an LSP, 129 the two LSPs cannot be used to carry traffic simultaneously, the new 130 LSP will take over the traffic from the existing LSP. 132 In a single domain, this is a common requirement in the recovery 133 cases especially in order to increase traffic resilience against 134 failure while reducing the amount of network resource used for 135 recovery purposes [RFC4428]. 137 The current protocol supporting the communication between a PCE and 138 a Path Computation Client (PCC), i.e. PCE Protocol (PCEP), allows 139 for re-optimization of an existing LSP [RFC5440]. This is achieved 140 by setting the R bit in the Request Parameter (RP) object, together 141 with some additional information if applicable, in the Path 142 Computation Request (PCReq) message sent from a PCC to the PCE. To 143 support this type of resource sharing, a PCC needs to ask a PCE to 144 compute a new path with the constraints of sharing resource with one 145 or multiple existing LSPs. It is worth noting the "resource sharing" 146 in this draft not only means one LSP re-using the same links of 147 another LSP, but also the same slice of bandwidth in the network. 148 This may occur when an LSP is required for re-routing, or online re- 149 optimization. Current PCEP specifications do not provide such 150 function. More specifically, this document describes the resource 151 sharing issue during the procedure when a new LSP is required to 152 replace an existing LSP for use together with Make-before-break 153 (MBB) described in [RFC3209]. 155 As mentioned in [RFC8231], the PLSP-ID provides a unique identifier 156 for an LSP during a PCEP session between PCC and PCE. Such 157 identification is helpful in supporting the resource sharing 158 requirement for stateful PCEs because it greatly simplifies the 159 operation of a PCC. Instead of the PCC determining all the resources 160 to be shared, the PCC can request that the PCE share the resources 161 of a specific LSP: the stateful PCE is able to determine those 162 resource itself. 164 Resource sharing can also be required in an inter-layer PCEP 165 session. This is similar to the previous requirement. However, it is 166 more complex and therefore deserves a more detailed explanation 167 here. 169 In a multi-layer network, LSPs in a lower layer are used to carry 170 higher-layer LSPs across the lower-layer network [RFC5623]. 171 Therefore, the resource sharing constraints in the higher layer 172 might actually relate to resource sharing in the lower layer. Thus, 173 it is useful to consider how this can be achieved and whether 174 additional extensions are needed using the models defined in 175 [RFC5623]. 177 In the next sections, use cases are provided to show what 178 information needs to be exchanged to fulfill these requirements. 179 This memo then provides extensions to PCEP to enable this function. 181 1.1. Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in 186 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 187 capitals, as shown here. 189 2. Motivation 191 2.1. Single Domain Use Case 193 There are two potential cases that request resource to be shared: 194 restoration and re-optimization. Figure 1 shows a single domain 195 network with a stateful PCE, and is used as an example for the 196 resource sharing application. 198 +--------------+ 199 | | 200 | Stateful PCE | 201 | | 202 +--------------+ 204 +------+ +------+ +------+ 205 | N1 +----------+ N2 +-----X---+ N3 | 206 +--+---+ +---+--+ +---+--+ 207 | | | 208 | +---------+ | 209 | | | 210 | +------+ +------+ | 211 +-----+ N5 +----------+ N4 +-----+ 212 +------+ +------+ 214 Figure 1: A Single Domain Example 216 LSP0 (existing): N1-N2-N3 217 LSP1 (restoration): N1-N2-N4-N3 218 LSP2 (re-optimization): N1-N5-N4-N3 220 For the failure restoration, we can assume a working LSP (LSP0) 221 exists in the network. When there is failure on the link N2-N3, it 222 is desired to set up a restoration path for this working LSP. 223 Suppose N1 serves as the PCC and sends a request to the stateful PCE 224 for such an LSP. Besides the head-end and tail-end node of the 225 working LSP, N1 may also need to check what policy should be applied 226 for the restoration. For example, it may evaluate resource sharing 227 and prefer to share as much resource with the working LSP as 228 possible and specify this policy as a special object in the PCReq 229 message. Given such policy, a probable outcome from the path 230 computation would be LSP1, which shares the link 'N1-N2' with the 231 existing LSP. The LSP1 will be set up by PCC via either PCInitiate 232 of RSVP. 234 Re-optimization does not usually result from a specific failure in 235 the network, but takes place on a stable network when more optimal 236 paths may have become available. Thus switching from the existing 237 LSP to the new LSP happens with live traffic. An example can be 238 found in Figure 1 without failure on the link N2-N3. Instead, an 239 online re-optimization is needed for the working LSP (LSP0) from the 240 stateful PCE. In such cases, the best choice is to set up a backup 241 LSP for the working LSP with totally separate routing (for example, 242 LSP2), and move the traffic to that backup LSP. After that, the 243 working LSP can be torn down, which will not result in any 244 interruption during the optimization procedure. This can actually be 245 implemented with existing PCEP mechanisms. However, if there is no 246 such separate path, existing PCEP mechanisms will return an error. A 247 secondary option for this case is to set up an LSP and complete re- 248 optimization with resource sharing, even if some interruption is 249 introduced. 251 In the example from Figure 1 it is assumed that the restored LSP or 252 re-optimized LSP have the same source and destination nodes. But in 253 some applications there is no restriction for this assumption, i.e., 254 after an LSP is failed, it can be restored as a new LSP with 255 different source/destination. 257 In the use cases above it is also assumed that the characteristics 258 of the restored LSP or re-optimized LSP are unchanged. However, it 259 is possible to have parameter changes during the resource sharing 260 computation. For example, the bandwidth of the request LSP may be 261 different from the existing LSP, while resource sharing is still 262 preferred by the PCC. The PCE should consider the sharing request 263 together with the policy and available resources in the network. 264 Details can be found in Section 3.3. 266 Conversely to resource sharing, it may also be required to apply a 267 disjoint constraint for the path computation. [ietf-pce-association- 268 diversity] discusses the solution under such a scenario, which is a 269 companion work to this document. 271 2.2. Multiple Layers/Domains Use Case 273 As Discussed in Section 3 of [RFC5623], there are three models for 274 inter-layer path computation. They are single PCE computation, 275 multiple PCE with inter-PCE communication, and multiple PCE without 276 inter-PCE communication. For the single PCE computation, the process 277 would be similar to that of the use case in Section 2.1. 279 An inter-layer path computation example is shown in Figure 2. Assume 280 an LSP (LSP1: H2-H3) has been established already, visible as H2-H3 281 from the view of the higher-layer PCE, and as H2-L1-L2-H3 from the 282 global view (or from the view of the lower-layer PCE). A new request 283 is received by H2 to establish a new LSP (LSP2: from H2 to H5), 284 given the constraint that it can share resources with LSP1. This 285 requirement is possible if only one of the LSPs needs to be active 286 and resource sharing is the target. 288 ----- 289 .................................| LSR | 290 .: | H5 | 291 .: /----- 292 .: / | 293 ----- -----.: ----- -----/ | 294 | LSR |--| LSR |.......................| LSR |--| LSR | / 295 | H1 | | H2 | | H3 | | H4 | / 296 ----- -----\ /----- ----- / 297 \ / / 298 \ / / 299 \ / / 300 \ / / 301 \----- -----/ / 302 | LSR |-| LSR | / 303 | L1 | | L2 | / 304 ----- -----\ / 305 | \ / 306 | \ / 307 | \ / 308 ----- \-----/ 309 | LSR |-----------| LSR | 310 | L3 | | L4 | 311 ----- ----- 312 Figure 2: A Two-layer Network Example 314 If the model of multiple PCEs with inter-PCE communication is 315 employed, the path computation request sent by H2 to higher-layer 316 PCE will be forwarded to lower-layer PCE since there is no resource 317 readily available in the higher layer. So it leaves the lower-layer 318 PCE to compute a path in the lower layer in order to support the 319 higher layer request. In this case, the lower-layer PCE is required 320 to compute a path between H2 and H5 under the constraint that it can 321 share the resource with that of LSP1. At this moment the lower-layer 322 PCE has knowledge of the mapping relationship between the higher- 323 layer link H2-H3 and the lower layer link L1-L2, and therefore can 324 convert the resource to be shared from higher layer to lower layer. 325 So when the lower-layer PCE computes the path for LSP2, it can 326 consider the resource used by L1-L2 as available with higher 327 priority. For example, the lower-layer PCE may choose H2-L1-L2-L4-H5 328 as the computation result. On the other hand, if the path 329 computation policy is to have a separate path with LSP1, the lower- 330 layer PCE may choose H2-L1-L3-L4-H5. 332 During this procedure the higher-layer PCE can only use information 333 about LSP1 (such as its five-tuple LSP information). An issue to 334 solve is how the lower-layer PCE can resolve this information to the 335 actual resource usage in its own layer, i.e. the lower layer. This 336 could be solved by the edge LSR (L1) reporting this higher-lower LSP 337 correlation to the lower-layer PCE as part of the LSP information 338 during the LSP state synchronization process. If needed, it can be 339 updated later when there is a change in this information. 340 Alternatively, the lower-layer PCE can get this information from 341 other sources, such as a network management system, where this 342 information should be stored. 344 If the model of multiple PCEs without inter-PCE communication is 345 employed, the path computation request in the lower layer will be 346 initiated by the border LSR node, i.e., L1. The process would be 347 similar to that of the previous scenario. A point worth noting is 348 that the border LSR node may be able to resolve the higher layer LSP 349 information itself, such as by mapping it to the corresponding LSP 350 in the lower layer, in this way the lower-layer PCE does not need to 351 perform this function. Otherwise, the mapping method mentioned above 352 can still be used. 354 2.3. Bulk Path Computation Use Case 356 There is a potential need for resource sharing during bulk path 357 computation, especially the processing of the "sticky resources" in 358 [RFC7399]. It would be useful to specify the resources that can be 359 shared among different paths, i.e., the bandwidth information. 361 Considering the H-PCE architecture in [RFC8751], when the parent PCE 362 asks for a single path across a few domains, such a request may 363 become a bulk path computation to a certain child PCE. Figure 3 364 shows an example of 3 domains. The parent PCE will select one of 365 these path for establishment. 367 +-------+ 368 /| P-PCE |\ 370 / +---+---+ \ 371 / | \ 372 / | \ 373 / | \ 374 / | \ 375 / | \ 376 / | \ 377 +-----/+ +---+---+ +\------+ 378 |C-PCE1| |C-PCE2 | |C-PCE3 | 379 +------+ +-------+ +-------+ 380 / | \ 381 --------------- ----------------------- ------------- 382 / \ / \ / \ 383 | +---+ +---+ | | +---+ +---+ +---+ | | +---+ +---+ | 384 | | A +-----+ B +-+--+--+ D +---+ E +---+ H +-+--+-+ J +----+ L | | 385 | +-\-+ +---+ | | +---+ +---+ +--\+ | | +---+ +-/-+ | 386 | \ | | / \ | | / | 387 | \ | | / \| | / | 388 | \ +---+ | | +---+ / |\\| +---+/ | 389 | \+ C +-+--+--+ G +/ | |----| K | | 390 \ +---+/ \ +---+ / \ +---+ / 391 ---------------- ----------------------- -------------- 392 Figure 3: Bulk Request example with Hierarchical PCEs 394 A 3-domain example is shown in Figure 3, with the hierarchical PCE 395 architecture. In this example nodes A/B/C belong to domain 1, nodes 396 D/E/G/H belong to domain 2, and nodes J/K/L belong to domain 3. 397 Inter-domain links are B-D/C-G between domains 1 and 2, and H-J/H-K 398 between domains 2 and 3. Given a path computation request from A to 399 L, a bulk request from P-PCE would be helpful to understand whether 400 it is possible to have different combinations on the inter-domain 401 links. However, the resources on some specific links become 'sticky' 402 and have to be indicated as 'sharing allowed' to avoid unnecessary 403 resource competition. For example, both the route A-B-D-E-H-J-L and 404 A-C-G-E-H-K-L are qualified, but these routes are competing for the 405 resource on the link E-H and cannot be established simultaneously, 406 so there must be one route failed to be reported to P-PCE. Given the 407 indication of allowing resource sharing on the link E-H, both of 408 these routes can be reported for P-PCE's decision, and there will 409 not be any competition as the P-PCE understands that only one path 410 needs to be set up. 412 3. Extensions to PCEP 414 3.1. Association Group and Type 416 According to the definition in [RFC8697], the association group is 417 used to associate multiple LSPs into one group for further path 418 computation considerations, such as disjointness and resource 419 sharing, in the messages when requesting path computation. An 420 association ID will be used to identify the resource sharing group. 421 An association type that described disjointness has been defined in 422 [ietf-pce-association-diversity]. In this document, a new 423 association type is defined as follows: 425 Association type = TBD1 ("Sharing Association Type"). 427 A sharing group should have multiple LSPs. The number of LSPs and 428 the criteria for how LSPs share among each other are dependent on 429 local policy. 431 3.2. Resource Sharing TLV 433 The PCEP Resource Sharing group MAY carry the following TLV. It MAY 434 be carried within a PCReq message from the network element (or other 435 PCCs) so as to indicate the desired resource sharing requirements to 436 be applied by the stateful PCE during path computation. 438 0 1 2 3 440 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type = [TBD2] | Length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Flags |B|S|N|L| 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Optional TLVs | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 The following flags are defined: 458 * L (Link share) bit: when set, this flag indicates that the PCE 459 should prioritize the links shared by existing LSPs within the 460 sharing group for path computation. The existing LSP identifier and 461 its available link identifiers can be contained in the optional 462 TLVs. 464 * N (Node share) bit: when set, this flag indicates that the PCE 465 should prioritize the nodes shared by existing LSPs within the 466 sharing group for path computation. The existing LSP identifier and 467 its available node identifiers can be contained in the optional 468 TLVs. 470 * S (SRLG share) bit: when set, this flag indicates that the PCE 471 should set the SRLG (Shared Risk Link Group) of the computed LSP to 472 the same as existing LSPs within the sharing group for path 473 computation. The existing LSP identifier and SRLG information can be 474 contained in the optional TLVs. 476 * B (Bandwidth share) bit: when set, this flag indicates that the 477 PCE should prioritize the bandwidth to be shared by LSPs within the 478 sharing group for bulk path computation. The LSP identifiers can be 479 contained in the optional TLVs. 481 It is worth noting that there can be multiple flags set which may 482 conflict with each other. In this scenario, the result for path 483 computation may not be unique, and is dependent on the 484 implementation. The selection among multiple computation results is 485 out of the scope of this document. 487 3.3. Processing Rules 489 To request a path allowing resource sharing with one or multiple 490 existing LSPs, a PCC includes a Resource Sharing TLV in the 491 Association Group Object in any kind of path computation request 492 message, such as the PCReq, PCUpd, or PCInitiate messages specified 493 in [RFC8231] and [RFC8281]. 495 On receipt of a PCEP message with a Resource Sharing TLV, a stateful 496 PCE MUST proceed as follows: 498 - If the Resource Sharing TLV is unknown/unsupported, the PCE will 499 follow procedures defined in [RFC5440]. That is, the PCE sends a 500 PCErr message with error type 26 (Association Error) and error 501 value 6 (Association Information Mismatch), and the related path 502 computation request is discarded. 504 - If the Resource Sharing TLV is extracted correctly, the PCE MUST 505 apply the requested resource sharing requirement, i.e., try to 506 share as much resource as possible with the LSP specified in 507 Resource Sharing TLV. 509 The procedure of setting flags follows the rules defined in Section 510 3.1. The flags in the Resource Sharing TLV may be locally configured 511 on the requesting nodes via external entities, such as a network 512 management system or the entity that imposes the resource sharing 513 requirement. 515 It is worth noting that the Resource Sharing TLV can be used 516 together with other path indication objects like the IRO/XRO, with 517 different objectives. The first difference is, the use of the 518 Resource Sharing TLV is to set up an alternative path, instead a new 519 path. It is also dependent on the knowledge held be the PCC, e.g., 520 if the PCC has full knowledge of the path information and has a 521 strong preference on the route, it may send the request message with 522 an IRO to specify the route. On the other hand, if the PCC does not 523 know how the path should go but just wants to set up a new LSP to 524 replace the old one, it may use the Resource Sharing TLV instead of 525 an IRO. The second difference is that the Resource Sharing TLV is a 526 loose requirement. For example, if the constraint specified in an 527 IRO/XRO in an A-Z path computation request cannot be satisfied, the 528 reply message from PCE to PCC would be unsuccessful. However it is 529 still possible to have a path from the A-Z. If the target 530 node/link/SRLG/Bandwidth is set in the Resource Sharing TLV rather 531 than an IRO, the PCE may feedback a path from A-Z that does not 532 share the target specified in the Resource Sharing TLV. 534 4. Implementation Status 536 [Note to the RFC Editor - remove this section before publication, as 537 well as remove the reference to [RFC7942]. 539 Currently the authors are not aware of any implementations. 541 5. Manageability Considerations 543 All manageability requirements and considerations listed in 544 [RFC5440] and [RFC8231] apply to the PCEP protocol extensions 545 defined in this document. In addition, requirements and 546 considerations listed in this section apply. 548 5.1. Control of Function and Policy 550 A PCE or PCC implementation MUST allow operator-configured 551 associations and SHOULD allow setting of the resource sharing TLV 552 (Section 3.4) as described in this document. 554 5.2. Information and Data Models 556 An implementation SHOULD allow the operator to view the resource 557 sharing configured or created dynamically. Further implementation 558 SHOULD allow to view resource sharing associations reported by each 559 peer, and the current set of LSPs in the association. The PCEP YANG 560 module [ietf-pce-pcep-yang] includes association groups information. 562 5.3. Liveness Detection and Monitoring 564 Mechanisms defined in this document do not imply any new liveness 565 detection and monitoring requirements in addition to those already 566 listed in [RFC5440]. 568 5.4. Verify Correct Operations 570 Mechanisms defined in this document do not imply any new operation 571 verification requirements in addition to those already listed in 572 [RFC5440] and [RFC8231]. 574 5.5. Requirements on Other Protocols 576 Mechanisms defined in this document do not imply any new 577 requirements on other protocols. The configuration on local policy 578 may be accomplished by other protocols, such as Netconf. 580 5.6. Impact on Network Operations 582 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 583 extensions defined in this document. 585 6. Security Considerations 587 Security of PCEP is discussed in [RFC5440] and [RFC6952]. The 588 extensions in this document do not change the fundamentals of 589 security for PCEP. 591 However, the introduction of the Resource Sharing TLV in the 592 Association Group Object provides a vector that may be used to probe 593 for information from a network. For example, a PCC that wants to 594 discover the path of an LSP with which it is not involved can issue 595 a request message with a Resource Sharing TLV and may be able to get 596 back quite a lot of information about the path of the LSP through 597 issuing multiple such requests for different endpoints and analyzing 598 the received results. To protect against this, a PCE SHOULD be 599 configured with access and authorization controls such that only 600 authorized PCCs (for example, those within the network) can make 601 computation requests, only specifically authorized PCCs can make 602 requests for resource sharing, and such requests relating to 603 specific LSPs are further limited to a select few PCCs. How such 604 access controls and authorization is managed is outside the scope of 605 this document, but it will at the least include Access Control 606 Lists. 608 Furthermore, a PCC must be aware that setting up an LSP that shares 609 resources with another LSP may be a way of attacking the other LSP, 610 for example by depriving it of the resources it needs to operate 611 correctly. Thus it is important that, both in PCEP and the 612 associated signaling protocols, only authorized resource sharing is 613 allowed. 615 7. IANA Considerations 617 7.1. Association Object Type Indicators 619 IANA maintains a registry called the "Path Computation Element 620 Protocol (PCEP) Numbers" registry with a subregistry called the 621 "Association Type Field" subregistry. IANA is requested to make an 622 assignment from that subregistry as follows: 624 Object Name Object Reference 625 Class Type 626 ------------------------------------------------------------ 628 TBD1 Sharing-group Association Type [this document] 630 7.2. PCEP TLV Definitions 632 This document defines the following TLVs to support the resource 633 sharing scenario: 635 Value Name Reference 636 ------------------------------------------------------------ 638 TBD2 Resource-sharing TLV [this document] 640 IANA is requested to allocate the following bit numbers in the flag 641 spaces of Resource-sharing TLV: 643 Bit Flag name Reference 645 31 Link Share [this document] 647 30 Node Share [this document] 649 29 SRLG Share [this document] 651 28 Bandwidth Share [this document] 653 8. References 655 8.1. Normative References 657 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 658 requirements levels", RFC 2119, March 1997. 659 . 661 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 662 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 663 Tunnels", RFC 3209, December 2001. . 666 [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation 667 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 668 March 2009. . 670 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 671 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 672 May 2017, . 674 [RFC8231] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 675 Extensions for Stateful PCE", RFC8231, June 2017. 676 . 678 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 679 Extensions for PCE-initiated LSP Setup in a Stateful PCE 680 Model", RFC 8281, October 2017. . 683 [RFC8697] Minei, I., Crabbe E., Sivabalan S., Ananthakrishnan H., 684 Dhody D., Tanaka Y., "PCEP Extensions for Establishing 685 Relationships Between Sets of LSPs", RFC8697, January 686 2020. . 688 [RFC8800] Litkowski, S., Sivabalan, S., Barth, C., Dhody, D., "Path 689 Computation Element communication Protocol extension for 690 signaling LSP diversity constraint", June 2020, 691 . 693 8.2. Informative References 695 [RFC4428] Papadimitriou, D., Mannie., E., "Analysis of Generalized 696 Multi-Protocol Label Switching (GMPLS)-based Recovery 697 Mechanisms (including Protection and Restoration)", 698 RFC4428, March 2006. . 701 [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path 702 Computation Element (PCE)-Based Architecture", RFC 4655, 703 August 2006. . 705 [RFC5623] Oki., E., Takeda, T., Le Roux, JL., Farrel, A., "Framework 706 for PCE-Based Inter-Layer MPLS and GMPLS Traffic 707 Engineering", RFC5623, September 2009. . 710 [RFC6952] Jethanandani, M., Patel, K., Zheng, L., "Analysis of BGP, 711 LDP, PCEP, and MSDP Issues According to the Keying and 712 Authentication for Routing Protocols (KARP) Design Guide", 713 RFC6952, May 2013. . 716 [RFC7399] Farrel, A., King, D., "Unanswered Questions in the Path 717 Computation Element Architecture", RFC7399, October 2014. 718 . 720 [RFC7942] Sheffer, Y., Farrel, A., "Improving Awareness of Running 721 Code: The Implementation Status Section", RFC7942, July 722 2016. . 724 [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 725 Gonzalez de Dios, O., "Hierarchical Stateful Path 726 Computation Element (PCE)", RFC8751, March 2020. 727 . 729 [ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., Tantsura, 730 J., "A YANG Data Model for Path Computation Element 731 Communications Protocol(PCEP)", work in progress. 733 9. Acknowledgements 735 The authors would like to thank Adrian Farrel for his review and 736 valuable comments. 738 10. Contributor's Address 740 Dhruv Dhody 741 Huawei Technologies 742 Email: dhruv.dhody@huawei.com 744 Igor Bryskin 745 Huawei Technologies 746 Email: Igor.Bryskin@huawei.com 748 11. Authors' Addresses 750 Xian Zhang 751 Huawei Technologies 752 Email: zhang.xian@huawei.com 754 Haomian Zheng 755 Huawei Technologies 756 Email: zhenghaomian@huawei.com 758 Oscar Gonzalez de Dios 759 Telefonica I+D/gCTIO 760 Distrito Telefonica 761 E-28050 Madrid, Spain 762 EMail: oscar.gonzalezdedios@telefonica.com 764 Victor Lopez 765 Telefonica I+D/gCTIO 766 Distrito Telefonica 767 E-28050 Madrid, Spain 768 EMail: victor.lopezalvarez@telefonica.com 770 Yunbin Xu 771 CAICT 772 xuyunbin@caict.ac.cn