idnits 2.17.1 draft-ietf-pce-stateful-hpce-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 5, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-pce-pcep-yang' is defined on line 770, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-11 == Outdated reference: A later version (-12) exists of draft-ietf-pce-applicability-actn-03 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-02 == Outdated reference: A later version (-11) exists of draft-ietf-pce-hierarchy-extensions-03 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-06 == Outdated reference: A later version (-04) exists of draft-dugeon-pce-stateful-interdomain-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Y. Lee 4 Intended status: Informational Huawei Technologies 5 Expires: September 6, 2018 D. Ceccarelli 6 Ericsson 7 J. Shin 8 SK Telecom 9 D. King 10 Lancaster University 11 O. Gonzalez de Dios 12 Telefonica I+D 13 March 5, 2018 15 Hierarchical Stateful Path Computation Element (PCE). 16 draft-ietf-pce-stateful-hpce-03 18 Abstract 20 A Stateful Path Computation Element (PCE) maintains information on 21 the current network state, including: computed Label Switched Path 22 (LSPs), reserved resources within the network, and pending path 23 computation requests. This information may then be considered when 24 computing new traffic engineered LSPs, and for associated 25 and dependent LSPs, received from Path Computation Clients (PCCs). 27 The Hierarchical Path Computation Element (H-PCE) architecture, 28 provides an architecture to allow the optimum sequence of 29 inter-connected domains to be selected, and network policy to be 30 applied if applicable, via the use of a hierarchical relationship 31 between PCEs. 33 Combining the capabilities of Stateful PCE and the Hierarchical PCE 34 would be advantageous. This document describes general considerations 35 and use cases for the deployment of Stateful PCE(s) using the 36 Hierarchical PCE architecture. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 Copyright Notice 55 Copyright (c) 2018 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Hierarchical Stateful PCE . . . . . . . . . . . . . . . . . . 4 74 3.1. Passive Operations . . . . . . . . . . . . . . . . . . . 4 75 3.2. Active Operations . . . . . . . . . . . . . . . . . . . . 7 76 3.3. PCE Initiation Operation . . . . . . . . . . . . . . . . 8 77 3.3.1. Per Domain Stitched LSP . . . . . . . . . . . . . . . 8 78 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 10 79 4.1. Applicability to Inter-Layer . . . . . . . . . . . . . . 10 80 4.2. Applicability to ACTN . . . . . . . . . . . . . . . . . . 11 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 6. Manageability Considerations . . . . . . . . . . . . . . . . 12 83 6.1. Control of Function and Policy . . . . . . . . . . . . . 12 84 6.2. Information and Data Models . . . . . . . . . . . . . . . 12 85 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 86 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 87 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 88 6.6. Impact On Network Operations . . . . . . . . . . . . . . 12 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 93 9.2. Informative References . . . . . . . . . . . . . . . . . 13 94 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 The Path Computation Element communication Protocol (PCEP) provides 100 mechanisms for Path Computation Elements (PCEs) to perform path 101 computations in response to Path Computation Clients' (PCCs) 102 requests. 104 A stateful PCE is capable of considering, for the purposes of 105 path computation, not only the network state in terms of links and 106 nodes (referred to as the Traffic Engineering Database or TED) but 107 also the status of active services (previously computed paths, 108 and currently reserved resources, stored in the Label Switched 109 Paths Database (LSP-DB). 111 [RFC8051] describes general considerations for a stateful PCE 112 deployment and examines its applicability and benefits, as well as 113 its challenges and limitations through a number of use cases. 115 [RFC8231] describes a set of extensions to PCEP to provide stateful 116 control. A stateful PCE has access to not only the information 117 carried by the network's Interior Gateway Protocol (IGP), but also 118 the set of active paths and their reserved resources for its 119 computations. The additional state allows the PCE to compute 120 constrained paths while considering individual LSPs and their 121 interactions. [RFC8281] describes the setup, maintenance and 122 teardown of PCE-initiated LSPs under the stateful PCE model. 124 [RFC8231] also describes the active stateful PCE. The active PCE 125 functionality allows a PCE to reroute an existing LSP or make changes 126 to the attributes of an existing LSP, or delegate control of specific 127 LSPs to a new PCE. 129 The ability to compute shortest constrained TE LSPs in Multiprotocol 130 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 131 multiple domains has been identified as a key motivation for PCE 132 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 133 architecture which can be used for computing end-to-end paths for 134 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 135 Paths (LSPs). Within the Hierarchical PCE (H-PCE) architecture 136 [RFC6805], the Parent PCE (P-PCE) is used to compute a multi-domain 137 path based on the domain connectivity information. A Child PCE 138 (C-PCE) may be responsible for a single domain or multiple domains, 139 it is used to compute the intra-domain path based on its domain 140 topology information. 142 This document presents general considerations for stateful PCE(s) in 143 hierarchical PCE architecture. In particular, the behavior changes 144 and additions to the existing stateful PCE mechanisms (including PCE- 145 initiated LSP setup and active PCE usage) in the context of networks 146 using the H-PCE architecture. 148 The initial section of the document focuses on end to end (E2E) 149 inter-domain TE LSP. Section 3.3.1 describe the operations for the 150 Per Domain LSP that could be stitched. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 2. Terminology 162 The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231], 163 and [RFC8281]. 165 3. Hierarchical Stateful PCE 167 As described in [RFC6805], in the hierarchical PCE architecture, a 168 P-PCE maintains a domain topology map that contains the child domains 169 (seen as vertices in the topology) and their interconnections (links 170 in the topology). The P-PCE has no information about the content of 171 the child domains. Each child domain has at least one PCE capable of 172 computing paths across the domain. These PCEs are known as C-PCEs 173 and have a direct relationship with the P-PCE. The P-PCE builds the 174 domain topology map either via direct configuration (allowing network 175 policy to also be applied) or from learned information received from 176 each C-PCE. 178 [RFC8231] specifies new functions to support a stateful PCE. It also 179 specifies that a function can be initiated either from a PCC towards 180 a PCE (C-E) or from a PCE towards a PCC (E-C). 182 This document extends these functions to support H-PCE Architecture 183 from a C-PCE towards a P-PCE (CE-PE) or from a P-PCE towards a C-PCE 184 (PE-CE). All PCE types herein (i.e., PE or CE) are assumed to be 185 'stateful PCE'. 187 A number of interactions are expected in the Hierarchical Stateful 188 PCE architecture, these include: 190 LSP State Report (CE-PE): a child stateful PCE sends an LSP state 191 report to a Parent Stateful PCE whenever the state of a LSP 192 changes. 194 LSP State Synchronization (CE-PE): after the session between the 195 Child and Parent stateful PCEs is initialized, the P-PCE must 196 learn the state of C-PCE's TE LSPs. 198 LSP Control Delegation (CE-PE,PE-CE): a C-PCE grants to the P-PCE 199 the right to update LSP attributes on one or more LSPs; the C-PCE 200 may withdraw the delegation or the P-PCE may give up the 201 delegation at any time. 203 LSP Update Request (PE-CE): a stateful P-PCE requests modification 204 of attributes on a C-PCE's TE LSP. 206 PCE LSP Initiation Request (PE-CE): a stateful P-PCE requests C-PCE 207 to initiate a TE LSP. 209 Note that this hierarchy is recursive and thus a Label Switching 210 Router (LSR), as a PCC could delegate the control to a PCE, which may 211 delegate to its parent, which may further delegate it to its parent 212 (if it exist or needed). Similarly update operations could also be 213 applied recursively. 215 [I-D.ietf-pce-hierarchy-extensions] defines the H-PCE capability TLV 216 that should be used in the OPEN message to advertise the H-PCE 217 capability. [RFC8231] defines the stateful PCE capability TLV. The 218 presence of both TLVs represent the support for stateful H-PCE 219 operations as described in this document. 221 [I-D.litkowski-pce-state-sync] describes the procedures to allow a 222 stateful communication between PCEs for various use-cases. The 223 procedures and extensions as described in Section 3 of 224 [I-D.litkowski-pce-state-sync] are also applicable to Child and 225 Parent PCE communication. 227 3.1. Passive Operations 229 Procedures as described in [RFC6805] are applied, where the ingress 230 C-PCE sends a request to the P-PCE. The P-PCE selects a set of 231 candidate domain paths based on the domain topology and the state of 232 the inter-domain links. It then sends computation requests to the C- 233 PCEs responsible for each of the domains on the candidate domain 234 paths. Each C-PCE computes a set of candidate path segments across 235 its domain and sends the results to the P-PCE. The P-PCE uses this 236 information to select path segments and concatenate them to derive 237 the optimal end-to-end inter-domain path. The end-to-end path is 238 then sent to the C-PCE that received the initial path request, and 239 this C-PCE passes the path on to the PCC that issued the original 240 request. 242 As per [RFC8231], PCC sends an LSP State Report carried on a PCRpt 243 message to the C-PCE, indicating the LSP's status. The C-PCE MAY 244 further propagate the State Report to the P-PCE. A local policy at 245 C-PCE MAY dictate which LSPs to be reported to the P-PCE. The PCRpt 246 message is sent from C-PCE to P-PCE. 248 State synchronization mechanism as described in [RFC8231] and 249 [RFC8233] are applicable to PCEP session between C-PCE and P-PCE as 250 well. 252 Taking the sample hierarchical domain topology example from [RFC6805] 253 as the reference topology for the entirety of this document. 255 ----------------------------------------------------------------- 256 | Domain 5 | 257 | ----- | 258 | |PCE 5| | 259 | ----- | 260 | | 261 | ---------------- ---------------- ---------------- | 262 | | Domain 1 | | Domain 2 | | Domain 3 | | 263 | | | | | | | | 264 | | ----- | | ----- | | ----- | | 265 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 266 | | ----- | | ----- | | ----- | | 267 | | | | | | | | 268 | | ----| |---- ----| |---- | | 269 | | |BN11+---+BN21| |BN23+---+BN31| | | 270 | | - ----| |---- ----| |---- - | | 271 | | |S| | | | | |D| | | 272 | | - ----| |---- ----| |---- - | | 273 | | |BN12+---+BN22| |BN24+---+BN32| | | 274 | | ----| |---- ----| |---- | | 275 | | | | | | | | 276 | | ---- | | | | ---- | | 277 | | |BN13| | | | | |BN33| | | 278 | -----------+---- ---------------- ----+----------- | 279 | \ / | 280 | \ ---------------- / | 281 | \ | | / | 282 | \ |---- ----| / | 283 | ----+BN41| |BN42+---- | 284 | |---- ----| | 285 | | | | 286 | | ----- | | 287 | | |PCE 4| | | 288 | | ----- | | 289 | | | | 290 | | Domain 4 | | 291 | ---------------- | 292 | | 293 ----------------------------------------------------------------- 295 Figure 1: Sample Hierarchical Domain Topology 297 Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical 298 PCE End-to-End Path Computation Procedure) of [RFC6805], the 299 following additional steps are added for stateful PCE: 301 (1) The Ingress LSR initiates the setup of the LSP as per the path 302 and reports to the PCE1 the LSP status ("GOING-UP"). 304 (2) The PCE1 further reports the status of the LSP to the P-PCE 305 (PCE5). 307 (3) The Ingress LSR notifies the LSP state to PCE1 when the state is 308 "UP". 310 (4) The PCE1 further reports the status of the LSP to the P-PCE 311 (PCE5). 313 3.2. Active Operations 315 [RFC8231] describes the case of active stateful PCE. The active PCE 316 functionality uses two specific PCEP messages: 318 o Update Request (PCUpd) 319 o State Report (PCRpt) 321 The first is sent by the PCE to a Path Computation Client (PCC) for 322 modifying LSP attributes. The PCC sends back a PCRpt to acknowledge 323 the requested operation or report any change in LSP's state. 325 As per [RFC8051], Delegation is an operation to grant a PCE, 326 temporary rights to modify a subset of LSP parameters on one or more 327 PCC's LSPs. The C-PCE may further choose to delegate to P-PCE based 328 on a local policy. The PCRpt message with "D" (delegate) flag is 329 sent from C-PCE to P-PCE. 331 To update an LSP, a PCE send to the PCC, an LSP Update Request using 332 a PCUpd message. For LSP delegated to the P-PCE via the child PCE, 333 the P-PCE can use the same PCUpd message to request change to the C- 334 PCE (the Ingress domain PCE), the PCE further propagates the update 335 request to the PCC. 337 The P-PCE uses the same mechanism described in Section 3.1 to compute 338 the end to end path using PCReq and PCRep messages. 340 The following additional steps are also initially performed, for 341 active operations, again using the reference architecture described 342 in Figure 1 (Sample Hierarchical Domain Topology). 344 (1) The Ingress LSR delegates the LSP to the PCE1 via PCRpt message 345 with D flag set. 347 (2) The PCE1 further delegates the LSP to the P-PCE (PCE5). 349 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 350 the end to end path. 352 (3) The P-PCE (PCE5) sends the update request to the C-PCE 353 (PCE1) via PCUpd message. 355 (4) The PCE1 further updates the LSP to the Ingress LSR (PCC). 357 (5) The Ingress LSR initiates the setup of the LSP as per the path 358 and reports to the PCE1 the LSP status ("GOING-UP"). 360 (6) The PCE1 further reports the status of the LSP to the P-PCE 361 (PCE5). 363 (7) The Ingress LSR notifies the LSP state to PCE1 when the state is 364 "UP". 366 (8) The PCE1 further reports the status of the LSP to the P-PCE 367 (PCE5). 369 3.3. PCE Initiation Operation 371 [RFC8281] describes the setup, maintenance and teardown of PCE- 372 initiated LSPs under the stateful PCE model, without the need for 373 local configuration on the PCC, thus allowing for a dynamic network 374 that is centrally controlled and deployed. To instantiate or delete 375 an LSP, the PCE sends the Path Computation LSP Initiate Request 376 (PCInitiate) message to the PCC. In case of inter-domain LSP in 377 Hierarchical PCE architecture, the initiation operations can be 378 carried out at the P-PCE. In which case after P-PCE finishes the E2E 379 path computation, it can send the PCInitiate message to the C-PCE 380 (the Ingress domain PCE), the PCE further propagates the initiate 381 request to the PCC. 383 The following additional steps are also initially performed, for PCE 384 initiated operations, again using the reference architecture 385 described in Figure 1 (Sample Hierarchical Domain Topology): 387 (1) The P-PCE (PCE5) is requested to initiate a LSP. 389 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 390 the end to end path. 392 (2) The P-PCE (PCE5) sends the initiate request to the child 393 PCE (PCE1) via PCInitiate message. 395 (3) The PCE1 further propagates the initiate message to the Ingress 396 LSR (PCC). 398 (4) The Ingress LSR initiates the setup of the LSP as per the path 399 and reports to the PCE1 the LSP status ("GOING-UP"). 401 (5) The PCE1 further reports the status of the LSP to the P-PCE 402 (PCE5). 404 (6) The Ingress LSR notifies the LSP state to PCE1 when the state is 405 "UP". 407 (7) The PCE1 further reports the status of the LSP to the P-PCE 408 (PCE5). 410 3.3.1. Per Domain Stitched LSP 412 The Hierarchical PCE architecture as per [RFC6805] is primarily used 413 for E2E LSP. With PCE-Initiated capability, another mode of 414 operation is possible, where multiple intra-domain LSPs are initiated 415 in each domain which are further stitched to form an E2E LSP. The 416 P-PCE sends PCInitiate message to each C-PCE separately to initiate 417 individual LSP segments along the domain path. These individual per 418 domain LSP are stitched together by some mechanism, which is out of 419 scope of this document (Refer [I-D.dugeon-pce-stateful- 420 interdomain]). 422 The following additional steps are also initially performed, for the 423 Per Domain stiched LSP operation, again using the reference 424 architecture described in Figure 1 (Sample Hierarchical Domain 425 Topology): 427 (1) The P-PCE (PCE5) is requested to initiate a LSP. 429 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 430 the end to end path, which are broken into per-domain LSPs say - 432 o S-BN41 434 o BN41-BN33 436 o BN33-D 438 It should be noted that the P-PCE MAY use other mechanisms to 439 determine the suitable per-domain LSPs (apart from [RFC6805]). 441 For LSP (BN33-D) 443 (2) The P-PCE (PCE5) sends the initiate request to the child 444 PCE (PCE3) via PCInitiate message for LSP (BN33-D). 446 (3) The PCE3 further propagates the initiate message to BN33. 448 (4) BN33 initiates the setup of the LSP as per the path and reports 449 to the PCE3 the LSP status ("GOING-UP"). 451 (5) The PCE3 further reports the status of the LSP to the P-PCE 452 (PCE5). 454 (6) The node BN33 notifies the LSP state to PCE3 when the state is 455 "UP". 457 (7) The PCE3 further reports the status of the LSP to the P-PCE 458 (PCE5). 460 For LSP (BN41-BN33) 462 (8) The P-PCE (PCE5) sends the initiate request to the child PCE 463 (PCE4) via PCInitiate message for LSP (BN41-BN33). 465 (9) The PCE4 further propagates the initiate message to BN41. 467 (10) BN41 initiates the setup of the LSP as per the path and reports 468 to the PCE4 the LSP status ("GOING-UP"). 470 (11) The PCE4 further reports the status of the LSP to the P-PCE 471 (PCE5). 473 (l2) The node BN41 notifies the LSP state to PCE4 when the state is 474 "UP". 476 (13) The PCE4 further reports the status of the LSP to the P-PCE 477 (PCE5). 479 For LSP (S-BN41) 481 (14) The P-PCE (PCE5) sends the initiate request to the child 482 PCE (PCE1) via PCInitiate message for LSP (S-BN41). 484 (15) The PCE1 further propagates the initiate message to node S. 486 (16) S initiates the setup of the LSP as per the path and reports to 487 the PCE1 the LSP status ("GOING-UP"). 489 (17) The PCE1 further reports the status of the LSP to the P-PCE 490 (PCE5). 492 (18) The node S notifies the LSP state to PCE1 when the state is 493 "UP". 495 (19) The PCE1 further reports the status of the LSP to the P-PCE 496 (PCE5). 498 Additionally: 500 (20) Once P-PCE receives report of each per-domain LSP, it 501 should use suitable stitching mechanism, which is out of scope 502 of this document. In this step, P-PCE (PCE5) could also 503 initiate an E2E LSP (S-D) by sending the PCInitiate message to 504 Ingress C-PCE (PCE1). It is also possible to stitch the per- 505 domain LSP at the same time as the per-domain LSPs are 506 initiated as defined in [I-D.dugeon-pce-stateful-interdomain]. 508 4. Other Considerations 510 4.1. Applicability to Inter-Layer 512 [RFC5623] describes a framework for applying the PCE-based 513 architecture to inter-layer (G)MPLS traffic engineering. The H-PCE 514 Stateful architecture with stateful P-PCE coordinating with the 515 stateful C-PCEs of higher and lower layer is shown in the figure 516 below. 518 +----------+ 519 /| Parent | 520 / | PCE | 521 / +----------+ 522 / / Stateful 523 / / 524 / / 525 / / 526 Stateful +---+/ / 527 Child + PCE + / 528 PCE Hi + Hi + / 529 +---+ / 530 +---+ +---+ / +---+ +---+ 531 + LSR +--+ LSR +........................+ LSR +--+ LSR + 532 + H1 + + H2 + / + H3 + + H4 + 533 +---+ +---+\ +---+/ /+---+ +---+ 534 \ + PCE + / 535 \ + Lo + / 536 Stateful \ +---+ / 537 C-PCE \ / 538 Lo \+---+ +---+/ 539 + LSR +--+ LSR + 540 + L1 + + L2 + 541 +---+ +---+ 543 Figure 2: Sample Inter-Layer Topology 545 All procedures described in Section 3 are applicable to inter-layer 546 path setup as well. 548 4.2. Applicability to ACTN 550 [I-D.ietf-teas-actn-framework] describes framework for Abstraction 551 and Control of TE Networks (ACTN), where each Provisioning Network 552 Controller (PNC) is equivalent to C-PCE and P-PCE is the Multi-Domain 553 Service Coordinator (MDSC). The Per domain stitched LSP as per the 554 Hierarchical PCE architecture described in Section 3.3.1 and Section 555 4.1 is well suited for ACTN. 557 [I-D.ietf-pce-applicability-actn] examines the applicability of PCE 558 to the ACTN framework. To support the function of multi domain 559 coordination via hierarchy, the stateful hierarchy of PCEs plays a 560 crucial role. 562 In ACTN framework, Customer Network Controller (CNC) can request the 563 MDSC to check if there is a possibility to meet Virtual Network (VN) 564 requirements (before requesting for VN provision). The H-PCE 565 architecture as described in [RFC6805] can supports via the use of 566 PCReq and PCRep messages between the P-PCE and C-PCEs. 568 5. Other Considerations 570 5.1. Scalability Considerations 572 It should be noted that if all the C-PCEs would report all the LSPs 573 in their domain, it could lead to scalability issues for the P-PCE. 574 Thus it is recommended to only report the LSPs which are involved in 575 H-PCE, i.e. the LSPs which are either delegated to the P-PCE or 576 initiated by the P-PCE. Scalability considerations for PCEP as per 577 [RFC8231] continue to apply for the PCEP session between child and 578 parent PCE. 580 5.2. Confidentiality 582 As described in section 4.2 of [RFC6805], information about the 583 content of child domains is not shared for both scaling and 584 confidentiality reasons. Along with the confidentiality during path 585 computation, the child PCE could also conceal the path information, a 586 C-PCE may replace a path segment with a path-key [RFC5520], 587 effectively hiding the content of a segment of a path. 589 6. Security Considerations 591 The security considerations listed in [RFC8231],[RFC6805] and 592 [RFC5440] apply to this document as well. As per [RFC6805], it is 593 expected that the parent PCE will require all child PCEs to use full 594 security when communicating with the parent. 596 Any multi-domain operation necessarily involves the exchange of 597 information across domain boundaries. This is bound to represent a 598 significant security and confidentiality risk especially when the 599 child domains are controlled by different commercial concerns. PCEP 600 allows individual PCEs to maintain confidentiality of their domain 601 path information using path-keys [RFC5520], and the hierarchical PCE 602 architecture is specifically designed to enable as much isolation of 603 domain topology and capabilities information as is possible. The LSP 604 state in the PCRpt message SHOULD continue to use this. 606 The security consideration for PCE-Initiated LSP as per [RFC8281] is 607 also applicable from P-PCE to C-PCE. 609 Thus securing the PCEP session (between the P-PCE and the C-PCE) 610 using mechanism like TCP Authentication Option (TCP-AO) [RFC5925] or 611 Transport Layer Security (TLS) [RFC8253] is RECOMMENDED. 613 7. Manageability Considerations 615 All manageability requirements and considerations listed in 616 [RFC5440], [RFC6805], [RFC8231], and [RFC8281] apply to Stateful H- 617 PCE defined in this document. In addition, requirements and 618 considerations listed in this section apply. 620 7.1. Control of Function and Policy 622 Support of the hierarchical procedure will be controlled by the 623 management organization responsible for each child PCE. The parent 624 PCE must only accept path computation requests from authorized child 625 PCEs. If a parent PCE receives report from an unauthorized child 626 PCE, the report should be dropped. All mechanism as described in 627 [RFC8231] and [RFC8281] continue to apply. 629 7.2. Information and Data Models 631 An implementation SHOULD allow the operator to view the stateful and 632 H-PCE capabilities advertised by each peer. The PCEP YANG module [I- 633 D.ietf-pce-pcep-yang] can be extended to include details stateful H- 634 PCE. 636 7.3. Liveness Detection and Monitoring 638 Mechanisms defined in this document do not imply any new liveness 639 detection and monitoring requirements in addition to those already 640 listed in [RFC5440]. 642 7.4. Verify Correct Operations 644 Mechanisms defined in this document do not imply any new operation 645 verification requirements in addition to those already listed in 646 [RFC5440] and [RFC8231]. 648 7.5. Requirements On Other Protocols 650 Mechanisms defined in this document do not imply any new requirements 651 on other protocols. 653 7.6. Impact On Network Operations 655 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 656 extensions defined in this document. 658 The stateful H-PCE technique brings the applicability of stateful PCE 659 as described in [RFC8051], for the LSP traversing multiple domains. 661 8. IANA Considerations 663 There are no IANA considerations. 665 9. Acknowledgments 667 Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano 668 Parodi, Giacomo Agostini, Jeff Tantsura and Rajan Rao for 669 suggestions. 671 10. References 673 10.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, 677 DOI 10.17487/RFC2119, March 1997, 678 . 680 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 681 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 682 DOI 10.17487/RFC5440, March 2009, 683 . 685 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 686 Path Computation Element Architecture to the Determination 687 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 688 10.17487/RFC6805, November 2012, 689 . 691 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 692 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 693 May 2017, . 695 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 696 Computation Element Communication Protocol (PCEP) 697 Extensions for Stateful PCE", RFC 8231, 698 DOI 10.17487/RFC8231, September 2017, 699 . 701 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 702 Computation Element Communication Protocol (PCEP) 703 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 704 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 705 . 707 10.2. Informative References 709 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 710 Element (PCE)-Based Architecture", RFC 4655, 711 DOI 10.17487/RFC4655, August 2006, 712 . 714 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 715 "Preserving Topology Confidentiality in Inter-Domain Path 716 Computation Using a Path-Key-Based Mechanism", RFC 5520, 717 DOI 10.17487/RFC5520, April 2009, 718 . 720 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 721 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 722 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 723 September 2009, . 725 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 726 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 727 June 2010, . 729 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 730 Stateful Path Computation Element (PCE)", RFC 8051, 731 DOI 10.17487/RFC8051, January 2017, 732 . 734 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 735 "Extensions to the Path Computation Element Communication 736 Protocol (PCEP) to Compute Service-Aware Label Switched 737 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 738 2017, . 740 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 741 "PCEPS: Usage of TLS to Provide a Secure Transport for the 742 Path Computation Element Communication Protocol (PCEP)", 743 RFC 8253, DOI 10.17487/RFC8253, October 2017, 744 . 746 [I-D.ietf-teas-actn-framework] 747 Ceccarelli D. and Y. Lee, "Framework for Abstraction and 748 Control of Transport Networks", draft-ietf-teas- 749 actn-framework-11 (work in progress), October 2017. 751 [I-D.ietf-pce-applicability-actn] 752 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 753 Path Computation Element (PCE) for Abstraction and 754 Control of TE Networks (ACTN)", draft-ietf-pce- 755 applicability-actn-03 (work in progress), March 2018. 757 [I-D.litkowski-pce-state-sync] 758 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 759 Stateful Path Computation Element communication 760 procedures", draft-litkowski-pce-state-sync-02 (work in 761 progress), August 2017. 763 [I-D.ietf-pce-hierarchy-extensions] 764 Zhang, F., Zhao, Q., Dios, O., Casellas, R., and D. King, 765 "Extensions to Path Computation Element Communication 766 Protocol (PCEP) for Hierarchical Path Computation Elements 767 (PCE)", draft-ietf-pce-hierarchy-extensions-03 (work in 768 progress), July 2016. 770 [I-D.ietf-pce-pcep-yang] 771 Dhody, D., Hardwick, J., Beeram, V., and j. 772 jefftant@gmail.com, "A YANG Data Model for Path 773 Computation Element Communications Protocol (PCEP)", 774 draft-ietf-pce-pcep-yang-06 (work in progress), 775 January 2018. 777 [I-D.dugeon-pce-stateful-interdomain] 778 Dugeon, O. and J. Meuric, "PCEP Extension for Stateful 779 Inter-Domain Tunnels", draft-dugeon-pce-stateful- 780 interdomain-00 (work in progress), October 2017. 782 Appendix A. Contributor Addresses 784 Avantika 785 Huawei Technologies 786 Divyashree Techno Park, Whitefield 787 Bangalore, Karnataka 560066 788 India 790 EMail: s.avantika.avantika@gmail.com 792 Xian Zhang 793 Huawei Technologies 794 Bantian, Longgang District 795 Shenzhen, Guangdong 518129 796 P.R.China 798 EMail: zhang.xian@huawei.com 800 Udayasree Palle 801 Huawei Technologies 802 Divyashree Techno Park, Whitefield 803 Bangalore, Karnataka 560066 804 India 806 EMail: udayasreereddy@gmail.com 808 Authors' Addresses 810 Dhruv Dhody 811 Huawei Technologies 812 Divyashree Techno Park, Whitefield 813 Bangalore, Karnataka 560066 814 India 816 EMail: dhruv.ietf@gmail.com 818 Young Lee 819 Huawei Technologies 820 5340 Legacy Drive, Building 3 821 Plano, TX 75023 822 USA 824 EMail: leeyoung@huawei.com 826 Daniele Ceccarelli 827 Ericsson 828 Torshamnsgatan,48 829 Stockholm 830 Sweden 832 EMail: daniele.ceccarelli@ericsson.com 834 Jongyoon Shin 835 SK Telecom 836 6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seongnam-si, 837 Gyeonggi-do 463-784 838 Republic of Korea 840 EMail: jongyoon.shin@sk.com 842 Daniel King 843 Lancaster University 844 UK 846 EMail: d.king@lancaster.ac.uk 848 Oscar Gonzalez de Dios 849 Telefonica I+D 850 Don Ramon de la Cruz 82-84 851 Madrid, 28045 852 Spain 854 Phone: +34913128832 855 Email: ogondio@tid.es