idnits 2.17.1 draft-ietf-pce-applicability-actn-06.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 17, 2018) is 2140 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-04 == Outdated reference: A later version (-10) exists of draft-ietf-teas-actn-info-model-09 == 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-10 == Outdated reference: A later version (-13) exists of draft-lee-pce-pcep-ls-optical-04 == 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-03 == Outdated reference: A later version (-16) exists of draft-ietf-pce-association-policy-02 Summary: 0 errors (**), 0 flaws (~~), 9 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: December 19, 2018 D. Ceccarelli 6 Ericsson 7 June 17, 2018 9 Applicability of Path Computation Element (PCE) for Abstraction and 10 Control of TE Networks (ACTN) 11 draft-ietf-pce-applicability-actn-06 13 Abstract 15 Abstraction and Control of TE Networks (ACTN) refers to the set of 16 virtual network (VN) operations needed to orchestrate, control and 17 manage large-scale multi-domain TE networks so as to facilitate 18 network programmability, automation, efficient resource sharing, and 19 end-to-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 December 19, 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.1.3. Relationship to PCE based central control . . . . . . 4 68 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5 69 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 7 70 2. Architectural Considerations . . . . . . . . . . . . . . . . 7 71 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 7 72 2.2. Abstraction function . . . . . . . . . . . . . . . . . . 8 73 2.3. Customer mapping function . . . . . . . . . . . . . . . . 9 74 2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 75 3. Interface Considerations . . . . . . . . . . . . . . . . . . 10 76 4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 8.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 (LSP-DB). 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) [RFC7149] refers to a separation 127 between the control elements and the forwarding components so that 128 software running in a centralized system called a controller, can act 129 to 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 Virtual 179 Network Topology (VNT) [RFC5212], called the VNT Manager (VNTM). 181 1.1.3. Relationship to PCE based central control 183 [RFC8283] introduces the architecture for PCE as a central controller 184 (PCECC), it further examines the motivations and applicability for 185 PCEP as a southbound interface, and introduces the implications for 186 the protocol. The section 2.1.3 of [RFC8283] describe an hierarchy 187 of PCE-based controller as per the Hierarchy of PCE framework defined 188 in [RFC6805]. 190 1.2. Abstraction and Control of TE Networks (ACTN) 192 [I-D.ietf-teas-actn-requirements] describes the high-level ACTN 193 requirements. [I-D.ietf-teas-actn-framework] describes the 194 architecture model for ACTN including the entities (Customer Network 195 Controller(CNC), Multi-domain Service Coordinator(MDSC), and 196 Provisioning Network Controller (PNC) and their interfaces. 198 The ACTN reference architecture identified a three-tier control 199 hierarchy as depicted in Figure 1: 201 +---------+ +---------+ +---------+ 202 | CNC | | CNC | | CNC | 203 +---------+ +---------+ +---------+ 204 \ | / 205 \ | / 206 Boundary =============\==============|==============/============ 207 Between \ | / 208 Customer & ------- | CMI ------- 209 Network Operator \ | / 210 +---------------+ 211 | MDSC | 212 +---------------+ 213 / | \ 214 ------------ | MPI ------------- 215 / | \ 216 +-------+ +-------+ +-------+ 217 | PNC | | PNC | | PNC | 218 +-------+ +-------+ +-------+ 219 | SBI / | / \ 220 | / | SBI / \ 221 --------- ----- | / \ 222 ( ) ( ) | / \ 223 - Control - ( Phys. ) | / ----- 224 ( Plane ) ( Net ) | / ( ) 225 ( Physical ) ----- | / ( Phys. ) 226 ( Network ) ----- ----- ( Net ) 227 - - ( ) ( ) ----- 228 ( ) ( Phys. ) ( Phys. ) 229 --------- ( Net ) ( Net ) 230 ----- ----- 232 CMI - (CNC-MDSC Interface) 233 MPI - (MDSC-PNC Interface) 235 Figure 1: ACTN Hierarchy 237 The two interfaces with respect to the MDSC, one north of the MDSC 238 (CMI CNC-MDSC Interface) and one south (MPI MDSC-PNC Interface). A 239 hierarchy of MDSC is possible with a recursive MPI interface. 241 [I-D.ietf-teas-actn-info-model] provides an information model for 242 ACTN interfaces. 244 1.3. PCE and ACTN 246 This document examines the PCE and ACTN architecture and describes 247 how the PCE architecture is applicable to ACTN. It also lists the 248 PCEP extensions that are needed to use PCEP as an ACTN interface. 249 This document also identifies any gaps in PCEP, that exist at the 250 time of publication of this document. 252 Further, ACTN, Stateful H-PCE, and PCECC are based on the same basic 253 hierarchy framework and thus compatible with each other. 255 2. Architectural Considerations 257 ACTN [I-D.ietf-teas-actn-framework] architecture is based on 258 hierarchy and recursiveness of controllers. It defines three types 259 of controllers (depending on the functionalities they implement). 260 The main functionalities are - 262 o Multi domain coordination function 264 o Abstraction function 266 o Customer mapping/translation function 268 o Virtual service coordination function 270 Section 3 of [I-D.ietf-teas-actn-framework] describes these 271 functions. 273 It should be noted that, this document lists all possible ways in 274 which PCEP could be used for each of the above functions, but all 275 functions are not required to be implemented via PCEP. Operator may 276 choose to use the PCEP for multi domain coordination via stateful 277 H-PCE but use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get the 278 topology and support abstraction function. 280 2.1. Multi domain coordination via Hierarchy 282 With the definition of domain being "everything that is under the 283 control of the single logical controller", as per 284 [I-D.ietf-teas-actn-framework], it is needed to have a control entity 285 that oversees the specific aspects of the different domains and to 286 build a single abstracted end-to-end network topology in order to 287 coordinate end-to-end path computation and path/service provisioning. 289 The MDSC in ACTN framework realizes this function by coordinating the 290 per-domain PNCs in a hierarchy of controllers. It also needs to 291 detach from the underlying network technology and express customer 292 concerns by business needs. 294 [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy of 295 PCE with Parent PCE coordinating multi-domain path computation 296 function between Child PCE(s). It is easy to see how these 297 principles align, and thus how stateful H-PCE architecture can be 298 used to realize ACTN. 300 The Per domain stitched LSP in the Hierarchical stateful PCE 301 architecture, described in Section 3.3.1 of 302 [I-D.ietf-pce-stateful-hpce] is well suited for multi-domain 303 coordination function. This includes domain sequence selection; E2E 304 path computation; Controller (PCE) initiated path setup and 305 reporting. This is also applicable to multi-layer coordination in 306 case of IP+optical networks. 308 [I-D.litkowski-pce-state-sync]" describes the procedures to allow a 309 stateful communication between PCEs for various use-cases. The 310 procedures and extensions are also applicable to Child and Parent PCE 311 communication and thus useful for ACTN as well. 313 2.2. Abstraction function 315 To realize ACTN, an abstracted view of the underlying network 316 resources needs to be built. This includes global network-wide 317 abstracted topology based on the underlying network resources of each 318 domain. This also include abstract topology created as per the 319 customer service connectivity requests and represented as a network 320 slice allocated to each customer. 322 In order to compute and provide optimal paths, PCEs require an 323 accurate and timely Traffic Engineering Database (TED). 324 Traditionally this TED has been obtained from a link state (LS) 325 routing protocol supporting traffic engineering extensions. PCE may 326 construct its TED by participating in the IGP ([RFC3630] and 327 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 328 alternative is offered by BGP-LS [RFC7752]. 330 In case of H-PCE [RFC6805], the parent PCE needs to build the domain 331 topology map of the child domains and their interconnectivity. 332 [RFC6805] and [I-D.ietf-pce-inter-area-as-applicability] suggest that 333 BGP-LS could be used as a "northbound" TE advertisement from the 334 child PCE to the parent PCE. 336 [I-D.dhodylee-pce-pcep-ls] proposes another approaches for learning 337 and maintaining the Link-State and TE information as an alternative 338 to IGPs and BGP flooding, using PCEP itself. The child PCE can use 339 this mechanism to transport Link-State and TE information from child 340 PCE to a Parent PCE using PCEP. 342 In ACTN, there is a need to control the level of abstraction based on 343 the deployment scenario and business relationship between the 344 controllers. The mechanism used to disseminate information from PNC 345 (child PCE) to MDSC (parent PCE) should support abstraction. 346 [I-D.ietf-teas-actn-framework] describes a few alternative approaches 347 of abstraction. The resulting abstracted topology can be encoded 348 using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls] and its 349 optical network extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is 350 an attractive option when the operator would wish to have a single 351 control plane protocol (PCEP) to achieve ACTN functions. 353 [I-D.ietf-teas-actn-framework] discusses two ways to build abstract 354 topology from an MDSC standpoint with interaction with PNCs. The 355 primary method is called automatic generation of abstract topology by 356 configuration. With this method, automatic generation is based on 357 the abstraction/summarization of the whole domain by the PNC and its 358 advertisement on the MPI. The secondary method is called on-demand 359 generation of supplementary topology via Path Compute Request/Reply. 360 This method may be needed to obtain further complementary information 361 such as potential connectivity from child PCEs in order to facilitate 362 an end-to-end path provisioning. PCEP is well suited to support both 363 methods. 365 2.3. Customer mapping function 367 In ACTN, there is a need to map customer virtual network (VN) 368 requirements into network provisioning request to the PNC. That is, 369 the customer requests/commands are mapped into network provisioning 370 requests that can be sent to the PNC. Specifically, it provides 371 mapping and translation of a customer's service request into a set of 372 parameters that are specific to a network type and technology such 373 that network configuration process is made possible. 375 [RFC8281] describes the setup, maintenance and teardown of PCE- 376 initiated LSPs under the stateful PCE model, without the need for 377 local configuration on the PCC, thus allowing for a dynamic network 378 that is centrally controlled and deployed. To instantiate or delete 379 an LSP, the PCE sends the Path Computation LSP Initiate Request 380 (PCInitiate) message to the PCC. As described in 381 [I-D.ietf-pce-stateful-hpce], for inter-domain LSP in Hierarchical 382 PCE architecture, the initiation operations can be carried out at the 383 parent PCE. In which case after parent PCE finishes the E2E path 384 computation, it can send the PCInitiate message to the child PCE, the 385 child PCE further propagates the initiate request to the LSR. The 386 customer request is received by the MDSC (parent PCE) and based on 387 the business logic, global abstracted topology, network conditions 388 and local policy, the MDSC (parent PCE) translates this into per 389 domain LSP initiation request that a PNC (child PCE) can understand 390 and act on. This can be done via the PCInitiate message. 392 PCEP extensions for associating opaque policy between PCEP peer 393 [I-D.ietf-pce-association-policy] can be used. 395 2.4. Virtual Service Coordination 397 Virtual service coordination function in ACTN incorporates customer 398 service-related information into the virtual network service 399 operations in order to seamlessly operate virtual networks while 400 meeting customer's service requirements. 402 [I-D.leedhody-pce-vn-association] describes the need for associating 403 a set of LSPs with a VN "construct" to facilitate VN operations in 404 PCE architecture. This association allows the PCEs to identify which 405 LSPs belong to a certain VN. 407 This association based on VN is useful for various optimizations at 408 the VN level which can be applied to all the LSPs that are part of 409 the VN slice. During path computation, the impact of a path for an 410 LSP is compared against the paths of other LSPs in the VN. This is 411 to make sure that the overall optimization and SLA of the VN rather 412 than of a single LSP. Similarly, during re-optimization, advanced 413 path computation algorithm and optimization technique can be 414 considered for all the LSPs belonging to a VN/customer and optimize 415 them all together. 417 3. Interface Considerations 419 As per [I-D.ietf-teas-actn-framework], to allow virtualization and 420 multi domain coordination, the network has to provide open, 421 programmable interfaces, in which customer applications can create, 422 replace and modify virtual network resources and services in an 423 interactive, flexible and dynamic fashion while having no impact on 424 other customers. The two ACTN interfaces are - 426 o The CNC-MDSC Interface (CMI) is an interface between a Customer 427 Network Controller and a Multi Domain Service Coordinator. It 428 requests the creation of the network resources, topology or 429 services for the applications. The MDSC may also report potential 430 network topology availability if queried for current capability 431 from the Customer Network Controller. 433 o The MDSC-PNC Interface (MPI) is an interface between a Multi 434 Domain Service Coordinator and a Provisioning Network Controller. 436 It communicates the creation request, if required, of new 437 connectivity of bandwidth changes in the physical network, via the 438 PNC. In multi-domain environments, the MDSC needs to establish 439 multiple MPIs, one for each PNC, as there are multiple PNCs 440 responsible for its domain control. 442 o In case of hierarchy of MDSC, the MPI is applied recursively. 443 From an abstraction point of view, the top level MDSC which 444 interfaces the CNC operates on a higher level of abstraction 445 (i.e., less granular level) than the lower level MSDCs. 447 PCEP is especially suitable on the MPI as it meets the requirement 448 and the functions as set out in the ACTN framework 449 [I-D.ietf-teas-actn-framework]. Its recursive nature is well suited 450 via the multi-level hierarchy of PCE. PCEP can also be applied to 451 the CMI as the CNC can be a path computation client while the MDSC 452 can be a path computation server. The Section 4 describe how PCE and 453 PCEP could help realize ACTN on the MPI. 455 4. Realizing ACTN with PCE (and PCEP) 457 As per the example in the Figure 2, there are 4 domains, each with 458 its own PNC and a MDSC at top. The PNC and MDSC need PCE as a 459 important function. The PNC (or child PCE) already uses PCEP to 460 communicate to the network device. It can utilize the PCEP as the 461 MPI to communicate between controllers too. 463 ****** 464 ..........*MDSC*.............................. 465 . ****** .. MPI . 466 . . . . 467 . . . . 468 . . . . 469 . . . . 470 . . . . 471 . . . . 472 v v v . 473 ****** ****** ****** . 474 *PNC1* *PNC2* *PNC4* . 475 ****** ****** ****** . 476 +---------------+ +---------------+ +---------------+ . 477 |A |----| |----| C| . 478 | | | | | | . 479 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 480 +------------B13+ +---------------+ +B43------------+ . 481 \ / . 482 \ ****** / . 483 \ *PNC3*<............/..................... 484 \ ****** / 485 \+---------------+/ 486 B31 B34 487 | | 488 |DOMAIN 3 B| 489 +---------------+ 491 MDSC -> Parent PCE 492 PNC -> Child PCE 493 MPI -> PCEP 495 Figure 2: ACTN with PCE 497 o Building Domain Topology at MDSC: PNC (or child PCE) needs to have 498 the TED to compute path in its domain. As described in 499 Section 2.2, it can learn the topology via IGP or BGP-LS. PCEP-LS 500 is also a proposed mechanism to carry link state and traffic 501 engineering information within PCEP. A mechanism to carry 502 abstracted topology while hiding technology specific information 503 between PNC and MDSC is described in [I-D.dhodylee-pce-pcep-ls]. 504 At the end of this step the MDSC (or parent PCE) has the 505 abstracted topology from each of its PNC (or child PCE). This 506 could be as simple as a domain topology map as described in 507 [RFC6805] or it can have full topology information of all domains. 508 The latter is not scalable and thus an abstracted topology of each 509 domain interconnected by inter-domain links is the most common 510 case. 512 * Topology Change: When the PNC learns of any topology change, 513 the PNC needs to decide if the change needs to be notified to 514 the MDSC. This is dependent on the level of abstraction 515 between the MDSC and the PNC. 517 o VN Instantiate: MDSC is requested to instantiate a VN, the minimal 518 information that is required would be a VN identifier and a set of 519 end points. Various path computation, setup constraints and 520 objective functions may also be provided. In PCE terms, a VN 521 Instantiate can be considered as a set of paths belonging to the 522 same VN. As described in Section 2.4 and 523 [I-D.leedhody-pce-vn-association] the VN association can help in 524 identifying the set of paths that belong to a VN. The rest of the 525 information like the endpoints, constraints and objective function 526 (OF) is already defined in PCEP in terms of a single path. 528 * Path Computation: As per the example in the Figure 2, the VN 529 instantiate requires two end to end paths between (A in Domain 530 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The 531 MDSC (or parent PCE) triggers the end to end path computation 532 for these two paths. MDSC can do path computation based on the 533 abstracted domain topology that it already has or it may use 534 the H-PCE procedures (Section 2.1) using the PCReq and PCRep 535 messages to get the end to end path with the help of the child 536 PCEs (PNC). Either way, the resulted E2E paths may be broken 537 into per-domain paths. 539 * A-B: (A-B13,B13-B31,B31-B) 541 * A-C: (A-B13,B13-B31,B34-B43,B43-C) 543 * Per Domain Path Instantiation: Based on the above path 544 computation, MDSC can issue the path instantiation request to 545 each PNC via PCInitiate message (see 546 [I-D.ietf-pce-stateful-hpce] and 547 [I-D.leedhody-pce-vn-association]). A suitable stitching 548 mechanism would be used to stitch these per domain LSPs. One 549 such mechanism is described in 550 [I-D.lee-pce-lsp-stitching-hpce], where PCEP is extended to 551 support stitching in stateful H-PCE context. 553 * Per Domain Path Report: Each PNC should report the status of 554 the per-domain LSP to the MDSC via PCRpt message, as per the 555 Hierarchy of stateful PCE ([I-D.ietf-pce-stateful-hpce]). The 556 status of the end to end LSP (A-B and A-C) is made up when all 557 the per domain LSP are reported up by the PNCs. 559 * Delegation: It is suggested that the per domain LSPs are 560 delegated to respective PNC, so that they can control the path 561 and attributes based on each domain network conditions. 563 * State Synchronization: The state needs to be synchronized 564 between the parent PCE and child PCE. The mechanism described 565 in [I-D.litkowski-pce-state-sync] can be used. 567 o VN Modify: MDSC is requested to modify a VN, for example the 568 bandwidth for VN is increased. This may trigger path computation 569 at MDSC as described in the previous step and can trigger an 570 update to existing per-intra-domain path (via PCUpd message) or 571 creation (or deletion) of a per-domain path (via PCInitiate 572 message). As described in [I-D.ietf-pce-stateful-hpce], this 573 should be done in make-before-break fashion. 575 o VN Delete: MDSC is requested to delete a VN, in this case, based 576 on the E2E paths and the resulting per-domain paths need to be 577 removed (via PCInitiate message). 579 o VN Update (based on network changes): Any change in the per-domain 580 LSP are reported to the MDSC (via PCRpt message) as per 581 [I-D.ietf-pce-stateful-hpce]. This may result in changes in the 582 E2E path or VN status. This may also trigger a re-optimization 583 leading to a new per-domain path, update to existing path, or 584 deletion of the path. 586 o VN Protection: The VN protection/restoration requirements, need to 587 applied to each E2E path as well as each per domain path. The 588 MDSC needs to play a crucial role in coordinating the right 589 protection/restoration policy across each PNC. The existing 590 protection/restoration mechanism of PCEP can be applied on each 591 path. 593 o In case PNC generates an abstract topology to the MDSC, the 594 PCInitiate/PCUpd messages from the MDSC to a PNC will contain a 595 path with abstract nodes and links. PNC would need to take that 596 as an input for path computation to get a path with physical nodes 597 and links. Similarly PNC would convert the path received from the 598 device (with physical nodes and links) into abstract path (based 599 on the abstract topology generated before with abstract nodes and 600 links) and reported to the MDSC. 602 5. IANA Considerations 604 This is an informational document and thus does not have any IANA 605 allocations to be made. 607 6. Security Considerations 609 The ACTN framework described in [I-D.ietf-teas-actn-framework] 610 defines key components and interfaces for managed traffic engineered 611 networks. It also list various security considerations such as 612 request and control of resources, confidentially of the information, 613 and availability of function which should be taken into 614 consideration. 616 When PCEP is used on the MPI, this interface needs to be secured, use 617 of [RFC8253] is RECOMENDED. Each PCEP extension listed in this 618 document, presents its individual security considerations, which 619 continue to apply. 621 7. Acknowledgments 623 The authors would like to thank Jonathan Hardwick for the inspiration 624 behind this document. Further thanks to Avantika for her comments 625 with suggested text. 627 8. References 629 8.1. Normative References 631 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 632 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 633 DOI 10.17487/RFC5440, March 2009, 634 . 636 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 637 Path Computation Element Architecture to the Determination 638 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 639 DOI 10.17487/RFC6805, November 2012, 640 . 642 [I-D.ietf-teas-actn-framework] 643 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 644 Control of Traffic Engineered Networks", draft-ietf-teas- 645 actn-framework-15 (work in progress), May 2018. 647 8.2. Informative References 649 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 650 (TE) Extensions to OSPF Version 2", RFC 3630, 651 DOI 10.17487/RFC3630, September 2003, 652 . 654 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 655 Support of Generalized Multi-Protocol Label Switching 656 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 657 . 659 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 660 Element (PCE)-Based Architecture", RFC 4655, 661 DOI 10.17487/RFC4655, August 2006, 662 . 664 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 665 Per-Domain Path Computation Method for Establishing Inter- 666 Domain Traffic Engineering (TE) Label Switched Paths 667 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 668 . 670 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 671 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 672 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 673 DOI 10.17487/RFC5212, July 2008, 674 . 676 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 677 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 678 2008, . 680 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 681 in Support of Generalized Multi-Protocol Label Switching 682 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 683 . 685 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 686 "A Backward-Recursive PCE-Based Computation (BRPC) 687 Procedure to Compute Shortest Constrained Inter-Domain 688 Traffic Engineering Label Switched Paths", RFC 5441, 689 DOI 10.17487/RFC5441, April 2009, 690 . 692 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 693 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 694 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 695 September 2009, . 697 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 698 Networking: A Perspective from within a Service Provider 699 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 700 . 702 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 703 Computation Element Architecture", RFC 7399, 704 DOI 10.17487/RFC7399, October 2014, 705 . 707 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 708 Application-Based Network Operations", RFC 7491, 709 DOI 10.17487/RFC7491, March 2015, 710 . 712 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 713 S. Ray, "North-Bound Distribution of Link-State and 714 Traffic Engineering (TE) Information Using BGP", RFC 7752, 715 DOI 10.17487/RFC7752, March 2016, 716 . 718 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 719 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 720 . 722 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 723 Stateful Path Computation Element (PCE)", RFC 8051, 724 DOI 10.17487/RFC8051, January 2017, 725 . 727 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 728 Computation Element Communication Protocol (PCEP) 729 Extensions for Stateful PCE", RFC 8231, 730 DOI 10.17487/RFC8231, September 2017, 731 . 733 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 734 "PCEPS: Usage of TLS to Provide a Secure Transport for the 735 Path Computation Element Communication Protocol (PCEP)", 736 RFC 8253, DOI 10.17487/RFC8253, October 2017, 737 . 739 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 740 Computation Element Communication Protocol (PCEP) 741 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 742 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 743 . 745 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 746 Architecture for Use of PCE and the PCE Communication 747 Protocol (PCEP) in a Network with Central Control", 748 RFC 8283, DOI 10.17487/RFC8283, December 2017, 749 . 751 [I-D.ietf-pce-stateful-hpce] 752 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 753 and O. Dios, "Hierarchical Stateful Path Computation 754 Element (PCE).", draft-ietf-pce-stateful-hpce-04 (work in 755 progress), March 2018. 757 [I-D.ietf-teas-actn-requirements] 758 Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. 759 Lee, "Requirements for Abstraction and Control of TE 760 Networks", draft-ietf-teas-actn-requirements-09 (work in 761 progress), March 2018. 763 [I-D.ietf-teas-actn-info-model] 764 Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 765 Yoon, "Information Model for Abstraction and Control of TE 766 Networks (ACTN)", draft-ietf-teas-actn-info-model-09 (work 767 in progress), June 2018. 769 [I-D.ietf-pce-inter-area-as-applicability] 770 King, D., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and 771 O. Dios, "Applicability of the Path Computation Element to 772 Inter-Area and Inter-AS MPLS and GMPLS Traffic 773 Engineering", draft-ietf-pce-inter-area-as- 774 applicability-06 (work in progress), July 2016. 776 [I-D.dhodylee-pce-pcep-ls] 777 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 778 Distribution of Link-State and TE Information.", draft- 779 dhodylee-pce-pcep-ls-10 (work in progress), March 2018. 781 [I-D.lee-pce-pcep-ls-optical] 782 Lee, Y., zhenghaomian@huawei.com, z., Ceccarelli, D., 783 weiw@bupt.edu.cn, w., Park, P., and B. Yoon, "PCEP 784 Extension for Distribution of Link-State and TE 785 information for Optical Networks", draft-lee-pce-pcep-ls- 786 optical-04 (work in progress), February 2018. 788 [I-D.leedhody-pce-vn-association] 789 Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP 790 Extensions for Establishing Relationships Between Sets of 791 LSPs and Virtual Networks", draft-leedhody-pce-vn- 792 association-04 (work in progress), February 2018. 794 [I-D.litkowski-pce-state-sync] 795 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 796 Stateful Path Computation Element communication 797 procedures", draft-litkowski-pce-state-sync-03 (work in 798 progress), April 2018. 800 [I-D.ietf-pce-association-policy] 801 Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and 802 J. Hardwick, "Path Computation Element communication 803 Protocol extension for associating Policies and LSPs", 804 draft-ietf-pce-association-policy-02 (work in progress), 805 February 2018. 807 [I-D.lee-pce-lsp-stitching-hpce] 808 Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions 809 for Stitching LSPs in Hierarchical Stateful PCE Model", 810 draft-lee-pce-lsp-stitching-hpce-01 (work in progress), 811 December 2017. 813 Authors' Addresses 815 Dhruv Dhody 816 Huawei Technologies 817 Divyashree Techno Park, Whitefield 818 Bangalore, Karnataka 560066 819 India 821 EMail: dhruv.ietf@gmail.com 823 Young Lee 824 Huawei Technologies 825 5340 Legacy Drive, Building 3 826 Plano, TX 75023 827 USA 829 EMail: leeyoung@huawei.com 830 Daniele Ceccarelli 831 Ericsson 832 Torshamnsgatan,48 833 Stockholm 834 Sweden 836 EMail: daniele.ceccarelli@ericsson.com