idnits 2.17.1 draft-ietf-pce-applicability-actn-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 1, 2018) is 2246 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-02 == Outdated reference: A later version (-09) exists of draft-ietf-teas-actn-requirements-08 == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-11 == Outdated reference: A later version (-10) exists of draft-ietf-teas-actn-info-model-07 == Outdated reference: A later version (-08) exists of draft-ietf-pce-inter-area-as-applicability-06 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-09 == Outdated reference: A later version (-08) exists of draft-leedhody-pce-vn-association-04 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-02 == Outdated reference: A later version (-16) exists of draft-ietf-pce-association-policy-02 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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 2, 2018 D. Ceccarelli 6 Ericsson 7 March 1, 2018 9 Applicability of Path Computation Element (PCE) for Abstraction and 10 Control of TE Networks (ACTN) 11 draft-ietf-pce-applicability-actn-03 13 Abstract 15 Abstraction and Control of TE Networks (ACTN) refers to the set of 16 virtual network operations needed to orchestrate, control and manage 17 large-scale multi-domain TE networks so as to facilitate network 18 programmability, automation, efficient resource sharing, and end-to- 19 end virtual service aware connectivity and network function 20 virtualization services. 22 The Path Computation Element Communication Protocol (PCEP) provides 23 mechanisms for Path Computation Elements (PCEs) to perform path 24 computations in response to Path Computation Clients (PCCs) requests. 26 This document examines the applicability of PCE to the ACTN 27 framework. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 2, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Path Computation Element (PCE) . . . . . . . . . . . . . 2 65 1.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 3 66 1.1.2. PCE in multi-domain and multi-layer deployments . . . 4 67 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 4 68 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 6 69 2. Architectural Considerations . . . . . . . . . . . . . . . . 6 70 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 6 71 2.2. Virtualization/Abstraction function . . . . . . . . . . . 7 72 2.3. Customer mapping function . . . . . . . . . . . . . . . . 8 73 2.4. Virtual Network Operations . . . . . . . . . . . . . . . 8 74 3. Interface Considerations . . . . . . . . . . . . . . . . . . 9 75 4. Realizining ACTN with PCE (and PCEP) . . . . . . . . . . . . 10 76 5. Relationship to PCE based central control . . . . . . . . . . 13 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 9.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 1.1. Path Computation Element (PCE) 89 The Path Computation Element communication Protocol (PCEP) [RFC5440] 90 provides mechanisms for Path Computation Elements (PCEs) [RFC4655] to 91 perform path computations in response to Path Computation Clients 92 (PCCs) requests. 94 The ability to compute shortest constrained TE LSPs in Multiprotocol 95 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 96 multiple domains has been identified as a key motivation for PCE 97 development. 99 A stateful PCE [RFC8231] is capable of considering, for the purposes 100 of path computation, not only the network state in terms of links and 101 nodes (referred to as the Traffic Engineering Database or TED) but 102 also the status of active services (previously computed paths, and 103 currently reserved resources, stored in the Label Switched Paths 104 Database (LSPDB). 106 [RFC8051] describes general considerations for a stateful PCE 107 deployment and examines its applicability and benefits, as well as 108 its challenges and limitations through a number of use cases. 110 [RFC8231] describes a set of extensions to PCEP to provide stateful 111 control. A stateful PCE has access to not only the information 112 carried by the network's Interior Gateway Protocol (IGP), but also 113 the set of active paths and their reserved resources for its 114 computations. The additional state allows the PCE to compute 115 constrained paths while considering individual LSPs and their 116 interactions. [RFC8281] describes the setup, maintenance and 117 teardown of PCE-initiated LSPs under the stateful PCE model. 119 [RFC8231] also describes the active stateful PCE. The active PCE 120 functionality allows a PCE to reroute an existing LSP or make changes 121 to the attributes of an existing LSP, or a PCC to delegate control of 122 specific LSPs to a new PCE. 124 1.1.1. Role of PCE in SDN 126 Software-Defined Networking (SDN) refers to a separation between the 127 control elements and the forwarding components so that software 128 running in a centralized system called a controller, can act to 129 program the devices in the network to behave in specific ways. A 130 required element in an SDN architecture is a component that plans how 131 the network resources will be used and how the devices will be 132 programmed. It is possible to view this component as performing 133 specific computations to place flows within the network given 134 knowledge of the availability of network resources, how other 135 forwarding devices are programmed, and the way that other flows are 136 routed. It is concluded in [RFC7399], that this is the same function 137 that a PCE might offer in a network operated using a dynamic control 138 plane. This is the function and purpose of a PCE, and the way that a 139 PCE integrates into a wider network control system including SDN is 140 presented in Application-Based Network Operation (ABNO) [RFC7491]. 142 1.1.2. PCE in multi-domain and multi-layer deployments 144 Computing paths across large multi-domain environments require 145 special computational components and cooperation between entities in 146 different domains capable of complex path computation. The PCE 147 provides an architecture and a set of functional components to 148 address this problem space. A PCE may be used to compute end-to-end 149 paths across multi-domain environments using a per-domain path 150 computation technique [RFC5152]. The Backward recursive PCE based 151 path computation (BRPC) mechanism [RFC5441] defines a PCE-based path 152 computation procedure to compute inter-domain constrained MPLS and 153 GMPLS TE networks. However, both per-domain and BRPC techniques 154 assume that the sequence of domains to be crossed from source to 155 destination is known, either fixed by the network operator or 156 obtained by other means. 158 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can 159 be used for computing end-to-end paths for inter-domain MPLS Traffic 160 Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the 161 domain sequence is not known. Within the Hierarchical PCE (H-PCE) 162 architecture, the Parent PCE (P-PCE) is used to compute a multi- 163 domain path based on the domain connectivity information. A Child 164 PCE (C-PCE) may be responsible for a single domain or multiple 165 domains, it is used to compute the intra-domain path based on its 166 domain topology information. 168 [I-D.ietf-pce-stateful-hpce] state the considerations for stateful 169 PCE(s) in hierarchical PCE architecture. In particular, the behavior 170 changes and additions to the existing stateful PCE mechanisms 171 (including PCE- initiated LSP setup and active PCE usage) in the 172 context of networks using the H-PCE architecture. 174 [RFC5623] describes a framework for applying the PCE-based 175 architecture to inter-layer to (G)MPLS TE. It provides suggestions 176 for the deployment of PCE in support of multi-layer networks. It 177 also describes the relationship between PCE and a functional 178 component in charge of the control and management of the VNT, called 179 the Virtual Network Topology Manager (VNTM). 181 1.2. Abstraction and Control of TE Networks (ACTN) 183 [I-D.ietf-teas-actn-requirements] describes the high-level ACTN 184 requirements. [I-D.ietf-teas-actn-framework] describes the 185 architecture model for ACTN including the entities (Customer Network 186 Controller(CNC), Mult-domain Service Coordinator(MDSC), and 187 Provisioning Network Controller (PNC) and their interfaces. 189 The ACTN reference architecture identified a three-tier control 190 hierarchy as depicted in Figure 1: 192 +---------+ +---------+ +---------+ 193 | CNC | | CNC | | CNC | 194 +---------+ +---------+ +---------+ 195 \ | / 196 Business \ | / 197 Boundary =============\==============|==============/============ 198 Between \ | / 199 Customer & ------- | CMI ------- 200 Network Provider \ | / 201 +---------------+ 202 | MDSC | 203 +---------------+ 204 / | \ 205 ------------ | MPI ------------- 206 / | \ 207 +-------+ +-------+ +-------+ 208 | PNC | | PNC | | PNC | 209 +-------+ +-------+ +-------+ 210 | SBI / | / \ 211 | / | SBI / \ 212 --------- ----- | / \ 213 ( ) ( ) | / \ 214 - Control - ( Phys. ) | / ----- 215 ( Plane ) ( Net ) | / ( ) 216 ( Physical ) ----- | / ( Phys. ) 217 ( Network ) ----- ----- ( Net ) 218 - - ( ) ( ) ----- 219 ( ) ( Phys. ) ( Phys. ) 220 --------- ( Net ) ( Net ) 221 ----- ----- 223 CMI - (CNC-MDSC Interface) 224 MPI - (MDSC-PNC Interface) 226 Figure 1: ACTN Hierarchy 228 The two interfaces with respect to the MDSC, one north of the MDSC 229 Interface) and MPI (MDSC-PNC Interface), respectively. A hierarchy 230 of MDSC is possible with a recursive MPI interface. 232 [I-D.ietf-teas-actn-info-model] provides an information model for 233 ACTN interfaces. 235 1.3. PCE and ACTN 237 This document examines the PCE and ACTN architecture and describes 238 how the PCE architecture is applicable to ACTN. It also lists the 239 PCEP extensions that are needed to use PCEP as an ACTN interface. 240 This document also identifies any gaps in PCEP, that exist at the 241 time of publication of this document. 243 2. Architectural Considerations 245 ACTN [I-D.ietf-teas-actn-framework] architecture is based on 246 hierarchy and recursiveness of controllers. It defines three types 247 of controllers (depending on the functionalities they implement). 248 The main functionalities are - 250 o Multi domain coordination function 252 o Virtualization/Abstraction function 254 o Customer mapping/translation function 256 o Virtual service coordination function 258 Section 3 of [I-D.ietf-teas-actn-framework] describes these 259 functions. 261 It should be noted that, in this document we list all possible ways 262 in which PCEP could be used for each of the above functions, but all 263 functions are not required to be implemented via PCEP. Operator may 264 choose to use the PCEP for multi domain coordination via stateful 265 H-PCE but use RestConf or BGP-LS to get the topology and support 266 virtualization/abstraction function. 268 2.1. Multi domain coordination via Hierarchy 270 With the definition of domain being "everything that is under the 271 control of the single logical controller", as per 272 [I-D.ietf-teas-actn-framework], it is needed to have a control entity 273 that oversees the specific aspects of the different domains and to 274 build a single abstracted end-to-end network topology in order to 275 coordinate end-to-end path computation and path/service provisioning. 277 The MDSC in ACTN framework realizes this function by coordinating the 278 per-domain PNCs in a hierarchy of controllers. It also needs to 279 detach from the underlying network technology and express customer 280 concerns by business needs. 282 [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy of 283 PCE with Parent PCE coordinating multi-domain path computation 284 function between Child PCE(s). It is easy to see how these 285 principles align, and thus how stateful H-PCE architecture can be 286 used to realize ACTN. 288 The Per domain stitched LSP in the Hierarchical stateful PCE 289 architecture, described in Section 3.3.1 of 290 [I-D.ietf-pce-stateful-hpce] is well suited for multi-domain 291 coordination function. This includes domain sequence selection; E2E 292 path computation; Controller (PCE) initiated path setup and 293 reporting. This is also applicable to multi-layer coordination in 294 case of IP+optical networks. 296 [I-D.litkowski-pce-state-sync]" describes the procedures to allow a 297 stateful communication between PCEs for various use-cases. The 298 procedures and extensions are also applicable to Child and Parent PCE 299 communication and thus useful for ACTN as well. 301 2.2. Virtualization/Abstraction function 303 To realize ACTN, an abstracted view of the underlying network 304 resources needs to be built. This includes global network-wide 305 abstracted topology based on the underlying network resources of each 306 domain. This also include abstract topology created as per the 307 customer service connectivity requests and represented as a network 308 slice allocated to each customer. 310 In order to compute and provide optimal paths, PCEs require an 311 accurate and timely Traffic Engineering Database (TED). 312 Traditionally this TED has been obtained from a link state (LS) 313 routing protocol supporting traffic engineering extensions. PCE may 314 construct its TED by participating in the IGP ([RFC3630] and 315 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 316 alternative is offered by BGP-LS [RFC7752]. 318 In case of H-PCE [RFC6805], the parent PCE needs to build the domain 319 topology map of the child domains and their interconnectivity. 320 [RFC6805] and [I-D.ietf-pce-inter-area-as-applicability] suggest that 321 BGP-LS could be used as a "northbound" TE advertisement from the 322 child PCE to the parent PCE. 324 [I-D.dhodylee-pce-pcep-ls] proposes another approaches for learning 325 and maintaining the Link-State and TE information as an alternative 326 to IGPs and BGP flooding, using PCEP itself. The child PCE can use 327 this mechanism to transport Link-State and TE information from child 328 PCE to a Parent PCE using PCEP. 330 In ACTN, there is a need to control the level of abstraction based on 331 the deployment scenario and business relationship between the 332 controllers. The mechanism used to disseminate information from PNC 333 (child PCE) to MDSC (parent PCE) should support abstraction. 334 [I-D.lee-teas-actn-abstraction] describes a few alternative 335 approaches of abstraction. The resulting abstracted topology can be 336 encoded using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls]. 337 PCEP-LS is an attractive option when the operator would wish to have 338 a single control plane protocol (PCEP) to achieve ACTN functions. 340 2.3. Customer mapping function 342 In ACTN, there is a need to map customer virtual network (VN) 343 requirements into network provisioning request to the PNC. That is, 344 the customer requests/commands are mapped into network provisioning 345 requests that can be sent to the PNC. Specifically, it provides 346 mapping and translation of a customer's service request into a set of 347 parameters that are specific to a network type and technology such 348 that network configuration process is made possible. 350 [RFC8281] describes the setup, maintenance and teardown of PCE- 351 initiated LSPs under the stateful PCE model, without the need for 352 local configuration on the PCC, thus allowing for a dynamic network 353 that is centrally controlled and deployed. To instantiate or delete 354 an LSP, the PCE sends the Path Computation LSP Initiate Request 355 (PCInitiate) message to the PCC. As described in 356 [I-D.ietf-pce-stateful-hpce], for inter-domain LSP in Hierarchical 357 PCE architecture, the initiation operations can be carried out at the 358 parent PCE. In which case after parent PCE finishes the E2E path 359 computation, it can send the PCInitiate message to the child PCE, the 360 child PCE further propagates the initiate request to the LSR. The 361 customer request is received by the MDSC (parent PCE) and based on 362 the business logic, global abstracted topology, network conditions 363 and local policy, the MDSC (parent PCE) translates this into per 364 domain LSP initiation request that a PNC (child PCE) can understand 365 and act on. This can be done via the PCInitiate message. 367 PCEP extensions for associating opaque policy between PCEP peer 368 [I-D.ietf-pce-association-policy] can be used. 370 2.4. Virtual Network Operations 372 Virtual service coordination function in ACTN incorporates customer 373 service-related information into the virtual network service 374 operations in order to seamlessly operate virtual networks while 375 meeting customer's service requirements. 377 [I-D.leedhody-pce-vn-association] describes the need for associating 378 a set of LSPs with a VN "construct" to facilitate VN operations in 379 PCE architecture. This association allows the PCEs to identify which 380 LSPs belong to a certain VN. 382 This association based on VN is useful for various optimizations at 383 the VN level which can be applied to all the LSPs that are part of 384 the VN slice. During path computation, the impact of a path for an 385 LSP is compared against the paths of other LSPs in the VN. This is 386 to make sure that the overall optimization and SLA of the VN rather 387 than of a single LSP. Similarly, during re-optimization, advanced 388 path computation algorithm and optimization technique can be 389 considered for all the LSPs belonging to a VN/customer and optimize 390 them all together. 392 3. Interface Considerations 394 As per [I-D.ietf-teas-actn-framework], to allow virtualization and 395 multi domain coordination, the network has to provide open, 396 programmable interfaces, in which customer applications can create, 397 replace and modify virtual network resources and services in an 398 interactive, flexible and dynamic fashion while having no impact on 399 other customers. The 3 ACTN interfaces are - 401 o The CNC-MDSC Interface (CMI) is an interface between a Customer 402 Network Controller and a Multi Domain Service Coordinator. It 403 requests the creation of the network resources, topology or 404 services for the applications. The MDSC may also report potential 405 network topology availability if queried for current capability 406 from the Customer Network Controller. 408 o The MDSC-PNC Interface (MPI) is an interface between a Multi 409 Domain Service Coordinator and a Physical Network Controller. It 410 communicates the creation request, if required, of new 411 connectivity of bandwidth changes in the physical network, via the 412 PNC. In multi-domain environments, the MDSC needs to establish 413 multiple MPIs, one for each PNC, as there are multiple PNCs 414 responsible for its domain control. 416 o Incase of hierarchy of MDSC, the MPI is applied recursively. From 417 an abstraction point of view, the top level MDSC which interfaces 418 the CNC operates on a higher level of abstraction (i.e., less 419 granular level) than the lower level MSDCs. 421 PCEP is especially suitable on the MPI as it meets the requirement 422 and the functions as set out in the ACTN framework 423 [I-D.ietf-teas-actn-framework]. Its recursive nature is well suited 424 via the multi-level hierarchy of PCE. The Section 4 describe how PCE 425 and PCEP could help realize ACTN. 427 4. Realizining ACTN with PCE (and PCEP) 429 As per the example in the Figure 2, there are 4 domains, each with 430 its own PNC and a MDSC at top. The PNC and MDSC need PCE as a 431 important function. The PNC (or child PCE) already uses PCEP to 432 communicate to the network device. It can utilize the PCEP as the 433 MPI to communicate between controllers too. 435 ****** 436 ..........*MDSC*.............................. 437 . ****** .. MPI . 438 . . . . 439 . . . . 440 . . . . 441 . . . . 442 . . . . 443 . . . . 444 v v v . 445 ****** ****** ****** . 446 *PNC1* *PNC2* *PNC4* . 447 ****** ****** ****** . 448 +---------------+ +---------------+ +---------------+ . 449 |A |----| |----| C| . 450 | | | | | | . 451 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 452 +------------B13+ +---------------+ +B43------------+ . 453 \ / . 454 \ ****** / . 455 \ *PNC3*<............/..................... 456 \ ****** / 457 \+---------------+/ 458 B31 B34 459 | | 460 |DOMAIN 3 B| 461 +---------------+ 463 MDSC -> Parent PCE 464 PNC -> Child PCE 465 MPI -> PCEP 467 Figure 2: ACTN with PCE 469 o Building Domain Topology at MDSC: PNC (or child PCE) needs to have 470 the TED to compute path in its domain. As described in 471 Section 2.2, it can learn the topology via IGP or BGP-LS. PCEP-LS 472 is also a proposed mechanism to carry link state and traffic 473 engineering information within PCEP. A mechanism to carry 474 abstracted topology while hiding technology specific information 475 between PNC and MDSC is described in [I-D.dhodylee-pce-pcep-ls]. 476 At the end of this step the MDSC (or parent PCE) has the 477 abstracted topology from each of its PNC (or child PCE). This 478 could be as simple as a domain topology map as described in 479 [RFC6805] or it can have full topology information of all domains. 480 The latter is not scalable and thus an abstracted topology of each 481 domain interconnected by inter-domain links is the most common 482 case. 484 * Topology Change: When the PNC learns of any topology change, 485 the PNC needs to decide if the change needs to be notified to 486 the MDSC. This is dependent on the level of abstraction 487 between the MDSC and the PNC. 489 o VN Instantiate: MDSC is requested to instantiate a VN, the minimal 490 information that is required would be a VN identifier and a set of 491 end points. Various path computation, setup constraints and 492 objective functions may also be provided. In PCE terms, a VN 493 Instantiate can be considered as a set of paths belonging to the 494 same VN. As described in Section 2.4 and 495 [I-D.leedhody-pce-vn-association] the VN association can help in 496 identifying the set of paths that belong to a VN. The rest of the 497 information like the endpoints, constraints and objective function 498 is already defined in PCEP in terms of a single path. 500 * Path Computation: As per the example in the Figure 2, the VN 501 instantiate requires two end to end paths between (A in Domain 502 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The 503 MDSC (or parent PCE) triggers the end to end path computation 504 for these two paths. MDSC can do path computation based on the 505 abstracted domain topology that it already has or it may use 506 the H-PCE procedures (Section 2.1) using the PCReq and PCRep 507 messages to get the end to end path with the help of PNC. 508 Either way, the resulted E2E paths may be broken into per- 509 domain paths. 511 * A-B: (A-B13,B13-B31,B31-B) 513 * A-C: (A-B13,B13-B31,B34-B43,B43-C) 515 * Per Domain Path Instantiation: Based on the above path 516 computation, MDSC can issue the path instantiation request to 517 each PNC via PCInitiate message (see 518 [I-D.ietf-pce-stateful-hpce] and 520 [I-D.leedhody-pce-vn-association]). A suitable stitching 521 mechanism would be used to stitch these per domain LSPs. One 522 such mechanism is described in 523 [I-D.lee-pce-lsp-stitching-hpce], where PCEP is extended to 524 support stitching in stateful H-PCE context. 526 * Per Domain Path Report: Each PNC should report the status of 527 the per-domain LSP to the MDSC via PCRpt message, as per the 528 Hierarchy of stateful PCE ([I-D.ietf-pce-stateful-hpce]). The 529 status of the end to end LSP (A-B and A-C) is made up when all 530 the per domain LSP are reported up by the PNCs. 532 * Delegation: It is suggested that the per domain LSPs are 533 delegated to respective PNC, so that they can control the path 534 and attributes based on each domain network conditions. 536 * State Synchronization: The state needs to be synchronized 537 between the parent PCE and child PCE. The mechanism described 538 in [I-D.litkowski-pce-state-sync] can be used. 540 o VN Modify: MDSC is requested to modify a VN, for example the 541 bandwidth for VN is increased. This may trigger path computation 542 at MDSC as described in the previous step and can trigger an 543 update to existing per-intra-domain path (via PCUpd message) or 544 creation (or deletion) of a per-domain path (via PCInitiate 545 message). This should be done in make-before-break fashion. 547 o VN Delete: MDSC is requested to delete a VN, in this case, based 548 on the E2E paths and the resulting per-domain paths need to be 549 removed (via PCInitiate message). 551 o VN Update (based on network changes): Any change in the per-domain 552 LSP are reported to the MDSC (via PCRpt message) as per 553 [I-D.ietf-pce-stateful-hpce]. This may result in changes in the 554 E2E path or VN status. This may also trigger a re-optimization 555 leading to a new per-domain path, update to existing path, or 556 deletion of the path. 558 o VN Protection: The VN protection/restoration requirements, need to 559 applied to each E2E path as well as each per domain path. The 560 MDSC needs to play a crucial role in coordinating the right 561 protection/restoration policy across each PNC. The existing 562 protection/restoration mechanism of PCEP can be applied on each 563 path. 565 o In case PNC generates an abstract topology to the MDSC, the 566 PCInitiate/PCUpd messages from the MDSC to a PNC will contain a 567 path with abstract nodes and links. PNC would need to take that 568 as an input for path computation to get a path with physical nodes 569 and links. Similarly PNC would convert the path received from the 570 device (with physical nodes and links) into abstract path (based 571 on the abstract topology generated before with abstract nodes and 572 links) and reported to the MDSC. 574 5. Relationship to PCE based central control 576 [I-D.ietf-teas-pce-central-control] introduces the architecture for 577 PCE as a central controller (PCECC), it further examines the 578 motivations and applicability for PCEP as a southbound interface, and 579 introduces the implications for the protocol. The section 2.1.3 of 580 [I-D.ietf-teas-pce-central-control] describe an hierarchy of PCE- 581 based controller as per the Hierarchy of PCE framework defined in 582 [RFC6805]. Both ACTN and PCECC is based on the same basic framework 583 and thus compatible with each other. 585 6. IANA Considerations 587 This is an informational document and thus does not have any IANA 588 allocations to be made. 590 7. Security Considerations 592 The ACTN framework described in [I-D.ietf-teas-actn-framework] 593 defines key components and interfaces for managed traffic engineered 594 networks. It also list various security considerations such as 595 request and control of resources, confidentially of the information, 596 and availability of function which should be taken into 597 consideration. 599 When PCEP is used on the MPI, this interface needs to be secured, use 600 of [RFC8253] is RECOMENDED. Each PCEP extension listed in this 601 document, presents its individual security considerations, which 602 continue to apply. 604 8. Acknowledgments 606 The authors would like to thank Jonathan Hardwick for the inspiration 607 behind this document. Further thanks to Avantika for her comments 608 with suggested text. 610 9. References 611 9.1. Normative References 613 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 614 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 615 DOI 10.17487/RFC5440, March 2009, 616 . 618 9.2. Informative References 620 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 621 (TE) Extensions to OSPF Version 2", RFC 3630, 622 DOI 10.17487/RFC3630, September 2003, 623 . 625 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 626 Support of Generalized Multi-Protocol Label Switching 627 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 628 . 630 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 631 Element (PCE)-Based Architecture", RFC 4655, 632 DOI 10.17487/RFC4655, August 2006, 633 . 635 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 636 Per-Domain Path Computation Method for Establishing Inter- 637 Domain Traffic Engineering (TE) Label Switched Paths 638 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 639 . 641 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 642 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 643 2008, . 645 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 646 in Support of Generalized Multi-Protocol Label Switching 647 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 648 . 650 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 651 "A Backward-Recursive PCE-Based Computation (BRPC) 652 Procedure to Compute Shortest Constrained Inter-Domain 653 Traffic Engineering Label Switched Paths", RFC 5441, 654 DOI 10.17487/RFC5441, April 2009, 655 . 657 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 658 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 659 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 660 September 2009, . 662 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 663 Path Computation Element Architecture to the Determination 664 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 665 DOI 10.17487/RFC6805, November 2012, 666 . 668 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 669 Computation Element Architecture", RFC 7399, 670 DOI 10.17487/RFC7399, October 2014, 671 . 673 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 674 Application-Based Network Operations", RFC 7491, 675 DOI 10.17487/RFC7491, March 2015, 676 . 678 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 679 S. Ray, "North-Bound Distribution of Link-State and 680 Traffic Engineering (TE) Information Using BGP", RFC 7752, 681 DOI 10.17487/RFC7752, March 2016, 682 . 684 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 685 Stateful Path Computation Element (PCE)", RFC 8051, 686 DOI 10.17487/RFC8051, January 2017, 687 . 689 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 690 Computation Element Communication Protocol (PCEP) 691 Extensions for Stateful PCE", RFC 8231, 692 DOI 10.17487/RFC8231, September 2017, 693 . 695 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 696 "PCEPS: Usage of TLS to Provide a Secure Transport for the 697 Path Computation Element Communication Protocol (PCEP)", 698 RFC 8253, DOI 10.17487/RFC8253, October 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 [I-D.ietf-pce-stateful-hpce] 708 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 709 and O. Dios, "Hierarchical Stateful Path Computation 710 Element (PCE).", draft-ietf-pce-stateful-hpce-02 (work in 711 progress), October 2017. 713 [I-D.ietf-teas-pce-central-control] 714 Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An 715 Architecture for Use of PCE and PCEP in a Network with 716 Central Control", draft-ietf-teas-pce-central-control-05 717 (work in progress), September 2017. 719 [I-D.ietf-teas-actn-requirements] 720 Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. 721 Lee, "Requirements for Abstraction and Control of TE 722 Networks", draft-ietf-teas-actn-requirements-08 (work in 723 progress), January 2018. 725 [I-D.ietf-teas-actn-framework] 726 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 727 Control of Traffic Engineered Networks", draft-ietf-teas- 728 actn-framework-11 (work in progress), October 2017. 730 [I-D.ietf-teas-actn-info-model] 731 Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 732 Yoon, "Information Model for Abstraction and Control of TE 733 Networks (ACTN)", draft-ietf-teas-actn-info-model-07 (work 734 in progress), February 2018. 736 [I-D.ietf-pce-inter-area-as-applicability] 737 King, D., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and 738 O. Dios, "Applicability of the Path Computation Element to 739 Inter-Area and Inter-AS MPLS and GMPLS Traffic 740 Engineering", draft-ietf-pce-inter-area-as- 741 applicability-06 (work in progress), July 2016. 743 [I-D.dhodylee-pce-pcep-ls] 744 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 745 Distribution of Link-State and TE Information.", draft- 746 dhodylee-pce-pcep-ls-09 (work in progress), January 2018. 748 [I-D.leedhody-pce-vn-association] 749 Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP 750 Extensions for Establishing Relationships Between Sets of 751 LSPs and Virtual Networks", draft-leedhody-pce-vn- 752 association-04 (work in progress), February 2018. 754 [I-D.litkowski-pce-state-sync] 755 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 756 Stateful Path Computation Element communication 757 procedures", draft-litkowski-pce-state-sync-02 (work in 758 progress), August 2017. 760 [I-D.ietf-pce-association-policy] 761 Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and 762 J. Hardwick, "Path Computation Element communication 763 Protocol extension for associating Policies and LSPs", 764 draft-ietf-pce-association-policy-02 (work in progress), 765 February 2018. 767 [I-D.lee-teas-actn-abstraction] 768 Lee, Y., Dhody, D., Ceccarelli, D., and O. Dios, 769 "Abstraction and Control of TE Networks (ACTN) Abstraction 770 Methods", draft-lee-teas-actn-abstraction-02 (work in 771 progress), June 2017. 773 [I-D.lee-pce-lsp-stitching-hpce] 774 Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions 775 for Stitching LSPs in Hierarchical Stateful PCE Model", 776 draft-lee-pce-lsp-stitching-hpce-01 (work in progress), 777 December 2017. 779 Authors' Addresses 781 Dhruv Dhody 782 Huawei Technologies 783 Divyashree Techno Park, Whitefield 784 Bangalore, Karnataka 560066 785 India 787 EMail: dhruv.ietf@gmail.com 788 Young Lee 789 Huawei Technologies 790 5340 Legacy Drive, Building 3 791 Plano, TX 75023 792 USA 794 EMail: leeyoung@huawei.com 796 Daniele Ceccarelli 797 Ericsson 798 Torshamnsgatan,48 799 Stockholm 800 Sweden 802 EMail: daniele.ceccarelli@ericsson.com