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