idnits 2.17.1 draft-dhodylee-pce-stateful-hpce-02.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 29, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-16 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-08) exists of draft-ietf-pce-stateful-pce-app-07 == Outdated reference: A later version (-10) exists of draft-ietf-pce-stateful-sync-optimizations-06 == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-01 == Outdated reference: A later version (-02) exists of draft-dhody-pce-applicability-actn-01 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: May 02, 2017 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 October 29, 2016 15 Hierarchical Stateful Path Computation Element (PCE). 16 draft-dhodylee-pce-stateful-hpce-02 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 http://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) 2016 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 (http://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 (LSPDB). 111 [I-D.ietf-pce-stateful-pce-app] describes general considerations for 112 a stateful PCE deployment and examines its applicability and 113 benefits, as well as its challenges and limitations through a number 114 of use cases. 116 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 117 provide stateful control. A stateful PCE has access to not only the 118 information carried by the network's Interior Gateway Protocol (IGP), 119 but also the set of active paths and their reserved resources for its 120 computations. The additional state allows the PCE to compute 121 constrained paths while considering individual LSPs and their 122 interactions. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, 123 maintenance and teardown of PCE-initiated LSPs under the stateful PCE 124 model. 126 [I-D.ietf-pce-stateful-pce] also describes the active stateful PCE. 127 The active PCE functionality allows a PCE to reroute an existing 128 LSP or make changes to the attributes of an existing LSP, or delegate 129 control of specific LSPs to a new PCE. 131 The ability to compute shortest constrained TE LSPs in Multiprotocol 132 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 133 multiple domains has been identified as a key motivation for PCE 134 development. [RFC6805] describes a Hierarchical PCE (H-PCE) 135 architecture which can be used for computing end-to-end paths for 136 inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched 137 Paths (LSPs). Within the Hierarchical PCE (H-PCE) architecture 138 [RFC6805], the Parent PCE (P-PCE) is used to compute a multi-domain 139 path based on the domain connectivity information. A Child PCE 140 (C-PCE) may be responsible for a single domain or multiple domains, 141 it is used to compute the intra-domain path based on its domain 142 topology information. 144 This document presents general considerations for stateful PCE(s) in 145 hierarchical PCE architecture. In particular, the behavior changes 146 and additions to the existing stateful PCE mechanisms (including PCE- 147 initiated LSP setup and active PCE usage) in the context of networks 148 using the H-PCE architecture. 150 1.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 2. Terminology 158 The terminology is as per [RFC4655], [RFC5440], [RFC6805], and 159 [I-D.ietf-pce-stateful-pce]. 161 3. Hierarchical Stateful PCE 163 As described in [RFC6805], in the hierarchical PCE architecture, a 164 P-PCE maintains a domain topology map that contains the child domains 165 (seen as vertices in the topology) and their interconnections (links 166 in the topology). The P-PCE has no information about the content of 167 the child domains. Each child domain has at least one PCE capable of 168 computing paths across the domain. These PCEs are known as C-PCEs 169 and have a direct relationship with the P-PCE. The P-PCE builds the 170 domain topology map either via direct configuration (allowing network 171 policy to also be applied) or from learned information received from 172 each C-PCE. 174 [I-D.ietf-pce-stateful-pce] specifies new functions to support a 175 stateful PCE. It also specifies that a function can be initiated 176 either from a PCC towards a PCE (C-E) or from a PCE towards a PCC 177 (E-C). 179 This document extends these functions to support H-PCE Architecture 180 from a C-PCE towards a P-PCE (CE-PE) or from a P-PCE 181 towards a C-PCE (PE-CE). All PCE types herein (i.e., PE or CE) 182 are assumed to be 'stateful PCE'. 184 A number of interactions are expected in the Hierarchical Stateful 185 PCE architecture, these include: 187 LSP State Report (CE-PE): a child stateful PCE sends an LSP state 188 report to a Parent Stateful PCE whenever the state of a LSP 189 changes. 191 LSP State Synchronization (CE-PE): after the session between the 192 Child and Parent stateful PCEs is initialized, the P-PCE must 193 learn the state of C-PCE's TE LSPs. 195 LSP Control Delegation (CE-PE,PE-CE): a C-PCE grants to the 196 P-PCE the right to update LSP attributes on one or more LSPs; 197 the C-PCE may withdraw the delegation or the P-PCE may 198 give up the delegation at any time. 200 LSP Update Request (PE-CE): a stateful P-PCE requests 201 modification of attributes on a C-PCE's TE LSP. 203 PCE LSP Initiation Request (PE-CE): a stateful P-PCE requests 204 C-PCE to initiate a TE LSP. 206 Note that this hierarchy is recursive and thus a LSR could delegate 207 the control to a PCE, which may delegate to its parent, which may 208 further delegate it to its parent (if it exist or needed). Similarly 209 update operations could also be applied recursively. 211 3.1. Passive Operations 213 Procedures as described in [RFC6805] are applied, where the ingress 214 C-PCE sends a request to the P-PCE. The P-PCE selects a set of 215 candidate domain paths based on the domain topology and the state of 216 the inter-domain links. It then sends computation requests to the C- 217 PCEs responsible for each of the domains on the candidate domain 218 paths. Each C-PCE computes a set of candidate path segments across 219 its domain and sends the results to the P-PCE. The P-PCE uses this 220 information to select path segments and concatenate them to derive 221 the optimal end-to-end inter-domain path. The end-to-end path is 222 then sent to the C-PCE that received the initial path request, and 223 this C-PCE passes the path on to the PCC that issued the original 224 request. 226 As per [I-D.ietf-pce-stateful-pce], PCC sends an LSP State Report 227 carried on a PCRpt message to the C-PCE, indicating the LSP's status. 228 The C-PCE MAY further propagate the State Report to the P-PCE. A 229 local policy at C-PCE MAY dictate which LSPs to be reported to the P- 230 PCE. The PCRpt message is sent from C-PCE to P-PCE. 232 State synchronization mechanism as described in 233 [I-D.ietf-pce-stateful-pce] and 234 [I-D.ietf-pce-stateful-sync-optimizations] are applicable to PCEP 235 session between C-PCE and P-PCE as well. 237 Taking the sample hierarchical domain topology example from [RFC6805] 238 as the reference topology for the entirety of this document. 240 ----------------------------------------------------------------- 241 | Domain 5 | 242 | ----- | 243 | |PCE 5| | 244 | ----- | 245 | | 246 | ---------------- ---------------- ---------------- | 247 | | Domain 1 | | Domain 2 | | Domain 3 | | 248 | | | | | | | | 249 | | ----- | | ----- | | ----- | | 250 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 251 | | ----- | | ----- | | ----- | | 252 | | | | | | | | 253 | | ----| |---- ----| |---- | | 254 | | |BN11+---+BN21| |BN23+---+BN31| | | 255 | | - ----| |---- ----| |---- - | | 256 | | |S| | | | | |D| | | 257 | | - ----| |---- ----| |---- - | | 258 | | |BN12+---+BN22| |BN24+---+BN32| | | 259 | | ----| |---- ----| |---- | | 260 | | | | | | | | 261 | | ---- | | | | ---- | | 262 | | |BN13| | | | | |BN33| | | 263 | -----------+---- ---------------- ----+----------- | 264 | \ / | 265 | \ ---------------- / | 266 | \ | | / | 267 | \ |---- ----| / | 268 | ----+BN41| |BN42+---- | 269 | |---- ----| | 270 | | | | 271 | | ----- | | 272 | | |PCE 4| | | 273 | | ----- | | 274 | | | | 275 | | Domain 4 | | 276 | ---------------- | 277 | | 278 ----------------------------------------------------------------- 280 Figure 1: Sample Hierarchical Domain Topology 282 Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical 283 PCE End-to-End Path Computation Procedure) of [RFC6805], the 284 following additional steps are added for stateful PCE: 286 (1) The Ingress LSR initiates the setup of the LSP as per the path 287 and reports to the PCE1 the LSP status ("GOING-UP"). 289 (2) The PCE1 further reports the status of the LSP to the P-PCE 290 (PCE5). 292 (3) The Ingress LSR notifies the LSP state to PCE1 when the state is 293 "UP". 295 (4) The PCE1 further reports the status of the LSP to the P-PCE 296 (PCE5). 298 3.2. Active Operations 300 [I-D.ietf-pce-stateful-pce] describes the case of active stateful 301 PCE. The active PCE functionality uses two specific PCEP messages: 303 o Update Request (PCUpd) 304 o State Report (PCRpt) 306 The first is sent by the PCE to a Path Computation Client (PCC) for 307 modifying LSP attributes. The PCC sends back a PCRpt to acknowledge 308 the requested operation. PCRpt has the same structure of PCNtf 309 message. 311 As per [I-D.ietf-pce-stateful-pce], Delegation is an operation to 312 grant a PCE, temporary rights to modify a subset of LSP parameters on 313 one or more PCC's LSPs. The C-PCE may further choose to delegate 314 to P-PCE based on a local policy. The PCRpt message with "D" 315 (delegate) flag is sent from C-PCE to P-PCE. 317 To update an LSP, a PCE send to the PCC, an LSP Update Request using 318 a PCUpd message. For LSP delegated to the P-PCE via the child 319 PCE, the P-PCE can use the same PCUpd message to request change 320 to the C-PCE (the Ingress domain PCE), the PCE further propagates 321 the update request to the PCC. 323 The P-PCE uses the same mechanism described in Section 3.1 to compute 324 the end to end path using PCReq and PCRep messages. 326 The following additional steps are also initially performed, 327 for active operations, again using the reference architecture 328 described in Figure 1 (Sample Hierarchical Domain Topology). 330 (1) The Ingress LSR delegates the LSP to the PCE1 via PCRpt message 331 with D flag set. 333 (2) The PCE1 further delegates the LSP to the P-PCE (PCE5). 335 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 336 the end to end path. 338 (3) The P-PCE (PCE5) sends the update request to the C-PCE 339 (PCE1) via PCUpd message. 341 (4) The PCE1 further updates the LSP to the Ingress LSR (PCC). 343 (5) The Ingress LSR initiates the setup of the LSP as per the path 344 and reports to the PCE1 the LSP status ("GOING-UP"). 346 (6) The PCE1 further reports the status of the LSP to the P-PCE 347 (PCE5). 349 (7) The Ingress LSR notifies the LSP state to PCE1 when the state is 350 "UP". 352 (8) The PCE1 further reports the status of the LSP to the P-PCE 353 (PCE5). 355 3.3. PCE Initiation Operation 357 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 358 teardown of PCE-initiated LSPs under the stateful PCE model, without 359 the need for local configuration on the PCC, thus allowing for a 360 dynamic network that is centrally controlled and deployed. To 361 instantiate or delete an LSP, the PCE sends the Path Computation LSP 362 Initiate Request (PCInitiate) message to the PCC. In case of inter- 363 domain LSP in Hierarchical PCE architecture, the initiation 364 operations can be carried out at the P-PCE. In which case after 365 P-PCE finishes the E2E path computation, it can send the 366 PCInitiate message to the C-PCE (the Ingress domain PCE), the PCE 367 further propagates the initiate request to the PCC. 369 The following additional steps are also initially performed, 370 for PCE initiated operations, again using the reference 371 architecture described in Figure 1 (Sample Hierarchical Domain 372 Topology): 374 (1) The P-PCE (PCE5) is requested to initiate a LSP. 376 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 377 the end to end path. 379 (2) The P-PCE (PCE5) sends the initiate request to the child 380 PCE (PCE1) via PCInitiate message. 382 (3) The PCE1 further propagates the initiate message to the Ingress 383 LSR (PCC). 385 (4) The Ingress LSR initiates the setup of the LSP as per the path 386 and reports to the PCE1 the LSP status ("GOING-UP"). 388 (5) The PCE1 further reports the status of the LSP to the P-PCE 389 (PCE5). 391 (6) The Ingress LSR notifies the LSP state to PCE1 when the state is 392 "UP". 394 (7) The PCE1 further reports the status of the LSP to the P-PCE 395 (PCE5). 397 3.3.1. Per Domain Stitched LSP 399 The hierarchical PCE architecture as per [RFC6805] is primarily used 400 for E2E LSP. With PCE-Initiated capability, another mode of 401 operation is possible, where multiple intra-domain LSPs are initiated 402 in each domain which are further stitched to form an E2E LSP. The 403 P-PCE sends PCInitiate message to each C-PCE separately to 404 initiate individual LSP segments along the domain path. These 405 individual per domain LSP are stitched together by some mechanism, 406 which is out of scope of this document. The P-PCE may also send 407 the PCInitiate message to the ingress C-PCE to initiate the E2E 408 LSP separately. 410 The following additional steps are also initially performed, 411 for the Per Domain stiched LSP operation, again using the reference 412 architecture described in Figure 1 (Sample Hierarchical Domain 413 Topology): 415 (1) The P-PCE (PCE5) is requested to initiate a LSP. 417 Steps 4 to 10 of section 4.6.2 of [RFC6805] are executed to determine 418 the end to end path, which are broken into per-domain LSPs say - 420 o S-BN41 422 o BN41-BN33 424 o BN33-D 426 It should be noted that the P-PCE MAY use other mechanisms to 427 determine the suitable per-domain LSPs (apart from [RFC6805]). 429 For LSP (BN33-D) 431 (2) The P-PCE (PCE5) sends the initiate request to the child 432 PCE (PCE3) via PCInitiate message for LSP (BN33-D). 434 (3) The PCE3 further propagates the initiate message to BN33. 436 (4) BN33 initiates the setup of the LSP as per the path and reports 437 to the PCE3 the LSP status ("GOING-UP"). 439 (5) The PCE3 further reports the status of the LSP to the P-PCE 440 (PCE5). 442 (6) The node BN33 notifies the LSP state to PCE3 when the state is 443 "UP". 445 (7) The PCE3 further reports the status of the LSP to the P-PCE 446 (PCE5). 448 For LSP (BN41-BN33) 450 (8) The P-PCE (PCE5) sends the initiate request to the child PCE 451 (PCE4) via PCInitiate message for LSP (BN41-BN33). 453 (9) The PCE4 further propagates the initiate message to BN41. 455 (10) BN41 initiates the setup of the LSP as per the path and reports 456 to the PCE4 the LSP status ("GOING-UP"). 458 (11) The PCE4 further reports the status of the LSP to the P-PCE 459 (PCE5). 461 (l2) The node BN41 notifies the LSP state to PCE4 when the state is 462 "UP". 464 (13) The PCE4 further reports the status of the LSP to the P-PCE 465 (PCE5). 467 For LSP (S-BN41) 469 (14) The P-PCE (PCE5) sends the initiate request to the child 470 PCE (PCE1) via PCInitiate message for LSP (S-BN41). 472 (15) The PCE1 further propagates the initiate message to node S. 474 (16) S initiates the setup of the LSP as per the path and reports to 475 the PCE1 the LSP status ("GOING-UP"). 477 (17) The PCE1 further reports the status of the LSP to the P-PCE 478 (PCE5). 480 (18) The node S notifies the LSP state to PCE1 when the state is 481 "UP". 483 (19) The PCE1 further reports the status of the LSP to the P-PCE 484 (PCE5). 486 Additionally: 488 (20) Once P-PCE receives report of each per-domain LSP, it 489 should use some stitching mechanism, which is out of scope of 490 this document. In this step, P-PCE (PCE5) could also initiate 491 an E2E LSP (S-D) by sending the PCInitiate message to Ingress 492 C-PCE (PCE1). 494 4. Other Considerations 496 4.1. Applicability to Inter-Layer 498 [RFC5623] describes a framework for applying the PCE-based 499 architecture to inter-layer (G)MPLS traffic engineering. The H-PCE 500 Stateful architecture with stateful P-PCE coordinating with the 501 stateful C-PCEs of higher and lower layer is shown in the figure 502 below. 504 +----------+ 505 /| Parent | 506 / | PCE | 507 / +----------+ 508 / / Stateful 509 / / 510 / / 511 / / 512 Stateful +---+/ / 513 Child + PCE + / 514 PCE Hi + Hi + / 515 +---+ / 516 +---+ +---+ / +---+ +---+ 517 + LSR +--+ LSR +........................+ LSR +--+ LSR + 518 + H1 + + H2 + / + H3 + + H4 + 519 +---+ +---+\ +---+/ /+---+ +---+ 520 \ + PCE + / 521 \ + Lo + / 522 Stateful \ +---+ / 523 C-PCE \ / 524 Lo \+---+ +---+/ 525 + LSR +--+ LSR + 526 + L1 + + L2 + 527 +---+ +---+ 529 Figure 2: Sample Inter-Layer Topology 531 All procedures described in Section 3 are applicable to inter-layer 532 path setup as well. 534 4.2. Applicability to ACTN 536 [I-D.ietf-teas-actn-framework] describes framework for 537 Abstraction and Control of TE Networks (ACTN), where each Physical 538 Network Controller (PNC) is equivalent to C-PCE and P-PCE is 539 the Multi-Domain Service Coordinator (MDSC). The Per domain stitched 540 LSP as per the Hierarchical PCE architecture described in 541 Section 3.3.1 and Section 4.1 is well suited for ACTN. 543 [I-D.dhody-pce-applicability-actn] examines the applicability of PCE 544 to the ACTN framework. To support the function of multi domain 545 coordination via hierarchy, the stateful hierarchy of PCEs plays a 546 crucial role. 548 In ACTN framework, Customer Network Controller (CNC) can request the 549 MDSC to check if there is a possibility to meet Virtual Network (VN) 550 requirements (before requesting for VN provision). The H-PCE 551 architecture as described in [RFC6805] can supports via the use of 552 PCReq and PCRep messages between the P-PCE and C-PCEs. 554 5. Scalability Considerations 556 It should be noted that if all the C-PCEs would report all the LSPs 557 in their domain, it could lead to scalability issues for the P-PCE. 558 Thus it is recommended to only report the LSPs which are involved in 559 H-PCE, i.e. the LSPs which are either delegated to the P-PCE or 560 initiated by the P-PCE. 562 6. Security Considerations 564 TBD. 566 7. Manageability Considerations 568 7.1. Control of Function and Policy 570 TBD. 572 7.2. Information and Data Models 574 TBD. 576 7.3. Liveness Detection and Monitoring 578 TBD. 580 7.4. Verify Correct Operations 582 TBD. 584 7.5. Requirements On Other Protocols 586 TBD. 588 7.6. Impact On Network Operations 590 TBD. 592 8. IANA Considerations 594 There are no IANA considerations. 596 9. Acknowledgments 598 Thanks to Manuela Scarella, Haomian Zheng, Sergio Marmo, Stefano 599 Parodi, Giacomo Agostini, Jeff Tantsura and Rajan Rao for 600 suggestions. 602 10. References 604 10.1. Normative References 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 612 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 613 DOI 10.17487/RFC5440, March 2009, 614 . 616 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 617 Path Computation Element Architecture to the Determination 618 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 619 10.17487/RFC6805, November 2012, 620 . 622 [I-D.ietf-pce-stateful-pce] 623 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 624 Extensions for Stateful PCE", draft-ietf-pce-stateful- 625 pce-16 (work in progress), September 2016. 627 [I-D.ietf-pce-pce-initiated-lsp] 628 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 629 Extensions for PCE-initiated LSP Setup in a Stateful PCE 630 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 631 progress), July 2016. 633 10.2. Informative References 635 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 636 Element (PCE)-Based Architecture", RFC 4655, 637 DOI 10.17487/RFC4655, August 2006, 638 . 640 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 641 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 642 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 643 September 2009, . 645 [I-D.ietf-pce-stateful-pce-app] 646 Zhang, X. and I. Minei, "Applicability of a Stateful Path 647 Computation Element (PCE)", draft-ietf-pce-stateful-pce- 648 app-07 (work in progress), September 2016. 650 [I-D.ietf-pce-stateful-sync-optimizations] 651 Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 652 and D. Dhody, "Optimizations of Label Switched Path State 653 Synchronization Procedures for a Stateful PCE", draft- 654 ietf-pce-stateful-sync-optimizations-06 (work in 655 progress), October 2016. 657 [I-D.ietf-teas-actn-framework] 658 Ceccarelli D. and Y. Lee, "Framework for Abstraction and 659 Control of Transport Networks", draft-ietf-teas- 660 actn-framework-01 (work in progress), October 2016. 662 [I-D.dhody-pce-applicability-actn] 663 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 664 Path Computation Element (PCE) for Abstraction and 665 Control of TE Networks (ACTN)", draft-dhody-pce- 666 applicability-actn-01 (work in progress), October 2016. 668 Appendix A. Contributor Addresses 670 Avantika 671 Huawei Technologies 672 Divyashree Techno Park, Whitefield 673 Bangalore, Karnataka 560066 674 India 676 EMail: avantika.sushilkumar@huawei.com 678 Xian Zhang 679 Huawei Technologies 680 Bantian, Longgang District 681 Shenzhen, Guangdong 518129 682 P.R.China 684 EMail: zhang.xian@huawei.com 686 Udayasree Palle 687 Huawei Technologies 688 Divyashree Techno Park, Whitefield 689 Bangalore, Karnataka 560066 690 India 692 EMail: udayasree.palle@huawei.com 694 Authors' Addresses 696 Dhruv Dhody 697 Huawei Technologies 698 Divyashree Techno Park, Whitefield 699 Bangalore, Karnataka 560066 700 India 702 EMail: dhruv.ietf@gmail.com 704 Young Lee 705 Huawei Technologies 706 5340 Legacy Drive, Building 3 707 Plano, TX 75023 708 USA 710 EMail: leeyoung@huawei.com 712 Daniele Ceccarelli 713 Ericsson 714 Torshamnsgatan,48 715 Stockholm 716 Sweden 718 EMail: daniele.ceccarelli@ericsson.com 720 Jongyoon Shin 721 SK Telecom 722 6 Hwangsaeul-ro, 258 beon-gil, Bundang-gu, Seongnam-si, 723 Gyeonggi-do 463-784 724 Republic of Korea 726 EMail: jongyoon.shin@sk.com 728 Dan King 729 Lancaster University 730 UK 732 EMail: d.king@lancaster.ac.uk 734 Oscar Gonzalez de Dios 735 Telefonica I+D 736 Don Ramon de la Cruz 82-84 737 Madrid, 28045 738 Spain 740 Phone: +34913128832 741 Email: ogondio@tid.es