idnits 2.17.1 draft-ietf-pce-stateful-hpce-05.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 (June 18, 2018) is 2131 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 782, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-pce-applicability-actn-06 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-03 == Outdated reference: A later version (-11) exists of draft-ietf-pce-hierarchy-extensions-05 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-08 == Outdated reference: A later version (-04) exists of draft-dugeon-pce-stateful-interdomain-00 Summary: 0 errors (**), 0 flaws (~~), 7 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: December 20, 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 June 18, 2018 15 Hierarchical Stateful Path Computation Element (PCE). 16 draft-ietf-pce-stateful-hpce-05 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. The SPEAKER-IDENTITY-TLV (defined in 226 [RFC8232]) is included in the LSP object to identify the Ingress 227 (PCC). The PLSP-ID used in the forwarded PCRpt by the C-PCE to P-PCE 228 is same as the original one used by the PCC. 230 3.1. Passive Operations 232 Procedures as described in [RFC6805] are applied, where the ingress 233 C-PCE sends a request to the P-PCE. The P-PCE selects a set of 234 candidate domain paths based on the domain topology and the state of 235 the inter-domain links. It then sends computation requests to the C- 236 PCEs responsible for each of the domains on the candidate domain 237 paths. Each C-PCE computes a set of candidate path segments across 238 its domain and sends the results to the P-PCE. The P-PCE uses this 239 information to select path segments and concatenate them to derive 240 the optimal end-to-end inter-domain path. The end-to-end path is 241 then sent to the C-PCE that received the initial path request, and 242 this C-PCE passes the path on to the PCC that issued the original 243 request. 245 As per [RFC8231], PCC sends an LSP State Report carried on a PCRpt 246 message to the C-PCE, indicating the LSP's status. The C-PCE MAY 247 further propagate the State Report to the P-PCE. A local policy at 248 C-PCE MAY dictate which LSPs to be reported to the P-PCE. The PCRpt 249 message is sent from C-PCE to P-PCE. 251 State synchronization mechanism as described in [RFC8231] and 252 [RFC8232] are applicable to PCEP session between C-PCE and P-PCE as 253 well. 255 Taking the sample hierarchical domain topology example from [RFC6805] 256 as the reference topology for the entirety of this document. 258 ----------------------------------------------------------------- 259 | Domain 5 | 260 | ----- | 261 | |PCE 5| | 262 | ----- | 263 | | 264 | ---------------- ---------------- ---------------- | 265 | | Domain 1 | | Domain 2 | | Domain 3 | | 266 | | | | | | | | 267 | | ----- | | ----- | | ----- | | 268 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 269 | | ----- | | ----- | | ----- | | 270 | | | | | | | | 271 | | ----| |---- ----| |---- | | 272 | | |BN11+---+BN21| |BN23+---+BN31| | | 273 | | - ----| |---- ----| |---- - | | 274 | | |S| | | | | |D| | | 275 | | - ----| |---- ----| |---- - | | 276 | | |BN12+---+BN22| |BN24+---+BN32| | | 277 | | ----| |---- ----| |---- | | 278 | | | | | | | | 279 | | ---- | | | | ---- | | 280 | | |BN13| | | | | |BN33| | | 281 | -----------+---- ---------------- ----+----------- | 282 | \ / | 283 | \ ---------------- / | 284 | \ | | / | 285 | \ |---- ----| / | 286 | ----+BN41| |BN42+---- | 287 | |---- ----| | 288 | | | | 289 | | ----- | | 290 | | |PCE 4| | | 291 | | ----- | | 292 | | | | 293 | | Domain 4 | | 294 | ---------------- | 295 | | 296 ----------------------------------------------------------------- 298 Figure 1: Sample Hierarchical Domain Topology 300 Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical 301 PCE End-to-End Path Computation Procedure) of [RFC6805], the 302 following additional steps are added for stateful PCE: 304 (1) The Ingress LSR initiates the setup of the LSP as per the path 305 and reports to the PCE1 the LSP status ("GOING-UP"). 307 (2) The PCE1 further reports the status of the LSP to the P-PCE 308 (PCE5). 310 (3) The Ingress LSR notifies the LSP state to PCE1 when the state is 311 "UP". 313 (4) The PCE1 further reports the status of the LSP to the P-PCE 314 (PCE5). 316 The Ingress LSR could trigger path re-optimization by sending the 317 path computation request as described in [RFC6805], at this time it 318 can include the LSP object in the PCReq message as described in 319 [RFC8231]. 321 3.2. Active Operations 323 [RFC8231] describes the case of active stateful PCE. The active PCE 324 functionality uses two specific PCEP messages: 326 o Update Request (PCUpd) 327 o State Report (PCRpt) 329 The first is sent by the PCE to a Path Computation Client (PCC) for 330 modifying LSP attributes. The PCC sends back a PCRpt to acknowledge 331 the requested operation or report any change in LSP's state. 333 As per [RFC8051], Delegation is an operation to grant a PCE, 334 temporary rights to modify a subset of LSP parameters on one or more 335 PCC's LSPs. The C-PCE may further choose to delegate to P-PCE based 336 on a local policy. The PCRpt message with "D" (delegate) flag is 337 sent from C-PCE to P-PCE. 339 To update an LSP, a PCE send to the PCC, an LSP Update Request using 340 a PCUpd message. For LSP delegated to the P-PCE via the child PCE, 341 the P-PCE can use the same PCUpd message to request change to the C- 342 PCE (the Ingress domain PCE), the PCE further propagates the update 343 request to the PCC. 345 The P-PCE uses the same mechanism described in Section 3.1 to compute 346 the end to end path using PCReq and PCRep messages. 348 The following additional steps are also initially performed, for 349 active operations, again using the reference architecture described 350 in Figure 1 (Sample Hierarchical Domain Topology). 352 (1) The Ingress LSR delegates the LSP to the PCE1 via PCRpt message 353 with D flag set. 355 (2) The PCE1 further delegates the LSP to the P-PCE (PCE5). 357 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 358 the end to end path. 360 (3) The P-PCE (PCE5) sends the update request to the C-PCE 361 (PCE1) via PCUpd message. 363 (4) The PCE1 further updates the LSP to the Ingress LSR (PCC). 365 (5) The Ingress LSR initiates the setup of the LSP as per the path 366 and reports to the PCE1 the LSP status ("GOING-UP"). 368 (6) The PCE1 further reports the status of the LSP to the P-PCE 369 (PCE5). 371 (7) The Ingress LSR notifies the LSP state to PCE1 when the state is 372 "UP". 374 (8) The PCE1 further reports the status of the LSP to the P-PCE 375 (PCE5). 377 3.3. PCE Initiation Operation 379 [RFC8281] describes the setup, maintenance and teardown of PCE- 380 initiated LSPs under the stateful PCE model, without the need for 381 local configuration on the PCC, thus allowing for a dynamic network 382 that is centrally controlled and deployed. To instantiate or delete 383 an LSP, the PCE sends the Path Computation LSP Initiate Request 384 (PCInitiate) message to the PCC. In case of inter-domain LSP in 385 Hierarchical PCE architecture, the initiation operations can be 386 carried out at the P-PCE. In which case after P-PCE finishes the E2E 387 path computation, it can send the PCInitiate message to the C-PCE 388 (the Ingress domain PCE), the PCE further propagates the initiate 389 request to the PCC. 391 The following additional steps are also initially performed, for PCE 392 initiated operations, again using the reference architecture 393 described in Figure 1 (Sample Hierarchical Domain Topology): 395 (1) The P-PCE (PCE5) is requested to initiate a LSP. 397 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 398 the end to end path. 400 (2) The P-PCE (PCE5) sends the initiate request to the child 401 PCE (PCE1) via PCInitiate message. 403 (3) The PCE1 further propagates the initiate message to the Ingress 404 LSR (PCC). 406 (4) The Ingress LSR initiates the setup of the LSP as per the path 407 and reports to the PCE1 the LSP status ("GOING-UP"). 409 (5) The PCE1 further reports the status of the LSP to the P-PCE 410 (PCE5). 412 (6) The Ingress LSR notifies the LSP state to PCE1 when the state is 413 "UP". 415 (7) The PCE1 further reports the status of the LSP to the P-PCE 416 (PCE5). 418 The Ingress LSR (PCC) generates the PLSP-ID for the LSP and inform 419 the C-PCE, which is propagated to the P-PCE as described in 420 [I-D.litkowski-pce-state-sync] 422 3.3.1. Per Domain Stitched LSP 424 The Hierarchical PCE architecture as per [RFC6805] is primarily used 425 for E2E LSP. With PCE-Initiated capability, another mode of 426 operation is possible, where multiple intra-domain LSPs are initiated 427 in each domain which are further stitched to form an E2E LSP. The 428 P-PCE sends PCInitiate message to each C-PCE separately to initiate 429 individual LSP segments along the domain path. These individual per 430 domain LSP are stitched together by some mechanism, which is out of 431 scope of this document (Refer [I-D.dugeon-pce-stateful- 432 interdomain]). 434 The following additional steps are also initially performed, for the 435 Per Domain stitched LSP operation, again using the reference 436 architecture described in Figure 1 (Sample Hierarchical Domain 437 Topology): 439 (1) The P-PCE (PCE5) is requested to initiate a LSP. 441 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 442 the end to end path, which are broken into per-domain LSPs say - 444 o S-BN41 446 o BN41-BN33 448 o BN33-D 450 It should be noted that the P-PCE MAY use other mechanisms to 451 determine the suitable per-domain LSPs (apart from [RFC6805]). 453 For LSP (BN33-D) 455 (2) The P-PCE (PCE5) sends the initiate request to the child 456 PCE (PCE3) via PCInitiate message for LSP (BN33-D). 458 (3) The PCE3 further propagates the initiate message to BN33. 460 (4) BN33 initiates the setup of the LSP as per the path and reports 461 to the PCE3 the LSP status ("GOING-UP"). 463 (5) The PCE3 further reports the status of the LSP to the P-PCE 464 (PCE5). 466 (6) The node BN33 notifies the LSP state to PCE3 when the state is 467 "UP". 469 (7) The PCE3 further reports the status of the LSP to the P-PCE 470 (PCE5). 472 For LSP (BN41-BN33) 474 (8) The P-PCE (PCE5) sends the initiate request to the child PCE 475 (PCE4) via PCInitiate message for LSP (BN41-BN33). 477 (9) The PCE4 further propagates the initiate message to BN41. 479 (10) BN41 initiates the setup of the LSP as per the path and reports 480 to the PCE4 the LSP status ("GOING-UP"). 482 (11) The PCE4 further reports the status of the LSP to the P-PCE 483 (PCE5). 485 (l2) The node BN41 notifies the LSP state to PCE4 when the state is 486 "UP". 488 (13) The PCE4 further reports the status of the LSP to the P-PCE 489 (PCE5). 491 For LSP (S-BN41) 493 (14) The P-PCE (PCE5) sends the initiate request to the child 494 PCE (PCE1) via PCInitiate message for LSP (S-BN41). 496 (15) The PCE1 further propagates the initiate message to node S. 498 (16) S initiates the setup of the LSP as per the path and reports to 499 the PCE1 the LSP status ("GOING-UP"). 501 (17) The PCE1 further reports the status of the LSP to the P-PCE 502 (PCE5). 504 (18) The node S notifies the LSP state to PCE1 when the state is 505 "UP". 507 (19) The PCE1 further reports the status of the LSP to the P-PCE 508 (PCE5). 510 Additionally: 512 (20) Once P-PCE receives report of each per-domain LSP, it 513 should use suitable stitching mechanism, which is out of scope 514 of this document. In this step, P-PCE (PCE5) could also 515 initiate an E2E LSP (S-D) by sending the PCInitiate message to 516 Ingress C-PCE (PCE1). It is also possible to stitch the per- 517 domain LSP at the same time as the per-domain LSPs are 518 initiated as defined in [I-D.dugeon-pce-stateful-interdomain]. 520 4. Other Considerations 522 4.1. Applicability to Inter-Layer 524 [RFC5623] describes a framework for applying the PCE-based 525 architecture to inter-layer (G)MPLS traffic engineering. The H-PCE 526 Stateful architecture with stateful P-PCE coordinating with the 527 stateful C-PCEs of higher and lower layer is shown in the figure 528 below. 530 +----------+ 531 /| Parent | 532 / | PCE | 533 / +----------+ 534 / / Stateful 535 / / 536 / / 537 / / 538 Stateful +---+/ / 539 Child + PCE + / 540 PCE Hi + Hi + / 541 +---+ / 542 +---+ +---+ / +---+ +---+ 543 + LSR +--+ LSR +........................+ LSR +--+ LSR + 544 + H1 + + H2 + / + H3 + + H4 + 545 +---+ +---+\ +---+/ /+---+ +---+ 546 \ + PCE + / 547 \ + Lo + / 548 Stateful \ +---+ / 549 C-PCE \ / 550 Lo \+---+ +---+/ 551 + LSR +--+ LSR + 552 + L1 + + L2 + 553 +---+ +---+ 555 Figure 2: Sample Inter-Layer Topology 557 All procedures described in Section 3 are applicable to inter-layer 558 path setup as well. 560 4.2. Applicability to ACTN 562 [I-D.ietf-teas-actn-framework] describes framework for Abstraction 563 and Control of TE Networks (ACTN), where each Provisioning Network 564 Controller (PNC) is equivalent to C-PCE and P-PCE is the Multi-Domain 565 Service Coordinator (MDSC). The Per domain stitched LSP as per the 566 Hierarchical PCE architecture described in Section 3.3.1 and Section 567 4.1 is well suited for ACTN. 569 [I-D.ietf-pce-applicability-actn] examines the applicability of PCE 570 to the ACTN framework. To support the function of multi domain 571 coordination via hierarchy, the stateful hierarchy of PCEs plays a 572 crucial role. 574 In ACTN framework, Customer Network Controller (CNC) can request the 575 MDSC to check if there is a possibility to meet Virtual Network (VN) 576 requirements (before requesting for VN provision). The H-PCE 577 architecture as described in [RFC6805] can supports via the use of 578 PCReq and PCRep messages between the P-PCE and C-PCEs. 580 5. Other Considerations 582 5.1. Scalability Considerations 584 It should be noted that if all the C-PCEs would report all the LSPs 585 in their domain, it could lead to scalability issues for the P-PCE. 586 Thus it is recommended to only report the LSPs which are involved in 587 H-PCE, i.e. the LSPs which are either delegated to the P-PCE or 588 initiated by the P-PCE. Scalability considerations for PCEP as per 589 [RFC8231] continue to apply for the PCEP session between child and 590 parent PCE. 592 5.2. Confidentiality 594 As described in section 4.2 of [RFC6805], information about the 595 content of child domains is not shared for both scaling and 596 confidentiality reasons. Along with the confidentiality during path 597 computation, the child PCE could also conceal the path information, a 598 C-PCE may replace a path segment with a path-key [RFC5520], 599 effectively hiding the content of a segment of a path. 601 6. Security Considerations 603 The security considerations listed in [RFC8231],[RFC6805] and 604 [RFC5440] apply to this document as well. As per [RFC6805], it is 605 expected that the parent PCE will require all child PCEs to use full 606 security when communicating with the parent. 608 Any multi-domain operation necessarily involves the exchange of 609 information across domain boundaries. This is bound to represent a 610 significant security and confidentiality risk especially when the 611 child domains are controlled by different commercial concerns. PCEP 612 allows individual PCEs to maintain confidentiality of their domain 613 path information using path-keys [RFC5520], and the hierarchical PCE 614 architecture is specifically designed to enable as much isolation of 615 domain topology and capabilities information as is possible. The LSP 616 state in the PCRpt message SHOULD continue to use this. 618 The security consideration for PCE-Initiated LSP as per [RFC8281] is 619 also applicable from P-PCE to C-PCE. 621 Thus securing the PCEP session (between the P-PCE and the C-PCE) 622 using mechanism like TCP Authentication Option (TCP-AO) [RFC5925] or 623 Transport Layer Security (TLS) [RFC8253] is RECOMMENDED. 625 7. Manageability Considerations 627 All manageability requirements and considerations listed in 628 [RFC5440], [RFC6805], [RFC8231], and [RFC8281] apply to Stateful H- 629 PCE defined in this document. In addition, requirements and 630 considerations listed in this section apply. 632 7.1. Control of Function and Policy 634 Support of the hierarchical procedure will be controlled by the 635 management organization responsible for each child PCE. The parent 636 PCE must only accept path computation requests from authorized child 637 PCEs. If a parent PCE receives report from an unauthorized child 638 PCE, the report should be dropped. All mechanism as described in 639 [RFC8231] and [RFC8281] continue to apply. 641 7.2. Information and Data Models 643 An implementation SHOULD allow the operator to view the stateful and 644 H-PCE capabilities advertised by each peer. The PCEP YANG module [I- 645 D.ietf-pce-pcep-yang] can be extended to include details stateful H- 646 PCE. 648 7.3. Liveness Detection and Monitoring 650 Mechanisms defined in this document do not imply any new liveness 651 detection and monitoring requirements in addition to those already 652 listed in [RFC5440]. 654 7.4. Verify Correct Operations 656 Mechanisms defined in this document do not imply any new operation 657 verification requirements in addition to those already listed in 658 [RFC5440] and [RFC8231]. 660 7.5. Requirements On Other Protocols 662 Mechanisms defined in this document do not imply any new requirements 663 on other protocols. 665 7.6. Impact On Network Operations 667 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 668 extensions defined in this document. 670 The stateful H-PCE technique brings the applicability of stateful PCE 671 as described in [RFC8051], for the LSP traversing multiple domains. 673 8. IANA Considerations 675 There are no IANA considerations. 677 9. Acknowledgments 679 Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano 680 Parodi, Giacomo Agostini, Jeff Tantsura and Rajan Rao for 681 suggestions. 683 10. References 685 10.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, 689 DOI 10.17487/RFC2119, March 1997, 690 . 692 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 693 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 694 DOI 10.17487/RFC5440, March 2009, 695 . 697 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 698 Path Computation Element Architecture to the Determination 699 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 700 10.17487/RFC6805, November 2012, 701 . 703 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 704 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 705 May 2017, . 707 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 708 Computation Element Communication Protocol (PCEP) 709 Extensions for Stateful PCE", RFC 8231, 710 DOI 10.17487/RFC8231, September 2017, 711 . 713 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 714 Computation Element Communication Protocol (PCEP) 715 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 716 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 717 . 719 10.2. Informative References 721 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 722 Element (PCE)-Based Architecture", RFC 4655, 723 DOI 10.17487/RFC4655, August 2006, 724 . 726 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 727 "Preserving Topology Confidentiality in Inter-Domain Path 728 Computation Using a Path-Key-Based Mechanism", RFC 5520, 729 DOI 10.17487/RFC5520, April 2009, 730 . 732 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 733 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 734 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 735 September 2009, . 737 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 738 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 739 June 2010, . 741 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 742 Stateful Path Computation Element (PCE)", RFC 8051, 743 DOI 10.17487/RFC8051, January 2017, 744 . 746 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 747 and D. Dhody, "Optimizations of Label Switched Path State 748 Synchronization Procedures for a Stateful PCE", RFC 8232, 749 DOI 10.17487/RFC8232, September 2017, 750 . 752 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 753 "PCEPS: Usage of TLS to Provide a Secure Transport for the 754 Path Computation Element Communication Protocol (PCEP)", 755 RFC 8253, DOI 10.17487/RFC8253, October 2017, 756 . 758 [I-D.ietf-teas-actn-framework] 759 Ceccarelli D. and Y. Lee, "Framework for Abstraction and 760 Control of Transport Networks", draft-ietf-teas- 761 actn-framework-15 (work in progress), May 2018. 763 [I-D.ietf-pce-applicability-actn] 764 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 765 Path Computation Element (PCE) for Abstraction and 766 Control of TE Networks (ACTN)", draft-ietf-pce- 767 applicability-actn-06 (work in progress), June 2018. 769 [I-D.litkowski-pce-state-sync] 770 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 771 Stateful Path Computation Element communication 772 procedures", draft-litkowski-pce-state-sync-03 (work in 773 progress), April 2018. 775 [I-D.ietf-pce-hierarchy-extensions] 776 Zhang, F., Zhao, Q., Dios, O., Casellas, R., and D. King, 777 "Extensions to Path Computation Element Communication 778 Protocol (PCEP) for Hierarchical Path Computation Elements 779 (PCE)", draft-ietf-pce-hierarchy-extensions-05 (work in 780 progress), June 2018. 782 [I-D.ietf-pce-pcep-yang] 783 Dhody, D., Hardwick, J., Beeram, V., and j. 784 jefftant@gmail.com, "A YANG Data Model for Path 785 Computation Element Communications Protocol (PCEP)", 786 draft-ietf-pce-pcep-yang-08 (work in progress), 787 June 2018. 789 [I-D.dugeon-pce-stateful-interdomain] 790 Dugeon, O. and J. Meuric, "PCEP Extension for Stateful 791 Inter-Domain Tunnels", draft-dugeon-pce-stateful- 792 interdomain-00 (work in progress), October 2017. 794 Appendix A. Contributor Addresses 796 Avantika 797 Huawei Technologies 798 Divyashree Techno Park, Whitefield 799 Bangalore, Karnataka 560066 800 India 802 EMail: s.avantika.avantika@gmail.com 804 Xian Zhang 805 Huawei Technologies 806 Bantian, Longgang District 807 Shenzhen, Guangdong 518129 808 P.R.China 810 EMail: zhang.xian@huawei.com 812 Udayasree Palle 813 Huawei Technologies 814 Divyashree Techno Park, Whitefield 815 Bangalore, Karnataka 560066 816 India 818 EMail: udayasreereddy@gmail.com 820 Authors' Addresses 822 Dhruv Dhody 823 Huawei Technologies 824 Divyashree Techno Park, Whitefield 825 Bangalore, Karnataka 560066 826 India 828 EMail: dhruv.ietf@gmail.com 830 Young Lee 831 Huawei Technologies 832 5340 Legacy Drive, Building 3 833 Plano, TX 75023 834 USA 836 EMail: leeyoung@huawei.com 838 Daniele Ceccarelli 839 Ericsson 840 Torshamnsgatan,48 841 Stockholm 842 Sweden 844 EMail: daniele.ceccarelli@ericsson.com 846 Jongyoon Shin 847 SK Telecom 848 6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seongnam-si, 849 Gyeonggi-do 463-784 850 Republic of Korea 852 EMail: jongyoon.shin@sk.com 854 Daniel King 855 Lancaster University 856 UK 858 EMail: d.king@lancaster.ac.uk 860 Oscar Gonzalez de Dios 861 Telefonica I+D 862 Don Ramon de la Cruz 82-84 863 Madrid, 28045 864 Spain 866 Phone: +34913128832 867 Email: ogondio@tid.es