idnits 2.17.1 draft-dhody-pce-applicability-actn-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 (March 13, 2017) is 2601 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 (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-05) exists of draft-ietf-teas-pce-central-control-01 == Outdated reference: A later version (-09) exists of draft-ietf-teas-actn-requirements-04 == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-04 == Outdated reference: A later version (-10) exists of draft-ietf-teas-actn-info-model-00 == 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-07 == Outdated reference: A later version (-08) exists of draft-leedhody-pce-vn-association-02 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-01 == Outdated reference: A later version (-16) exists of draft-ietf-pce-association-policy-00 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-11 == Outdated reference: A later version (-02) exists of draft-lee-teas-actn-abstraction-00 Summary: 0 errors (**), 0 flaws (~~), 14 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 14, 2017 D. Ceccarelli 6 Ericsson 7 March 13, 2017 9 Applicability of Path Computation Element (PCE) for Abstraction and 10 Control of TE Networks (ACTN) 11 draft-dhody-pce-applicability-actn-02 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 http://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 14, 2017. 46 Copyright Notice 48 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . 5 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) . . . . . . . . . . . . 9 76 5. Relationship to PCE based central control . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 9.2. Informative References . . . . . . . . . . . . . . . . . 13 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 is capable of considering, for the purposes of path 100 computation, not only the network state in terms of links and nodes 101 (referred to as the Traffic Engineering Database or TED) but also the 102 status of active services (previously computed paths, and currently 103 reserved resources, stored in the Label Switched Paths Database 104 (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 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 111 provide stateful control. A stateful PCE has access to not only the 112 information carried by the network's Interior Gateway Protocol (IGP), 113 but also 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. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, 117 maintenance and teardown of PCE-initiated LSPs under the stateful PCE 118 model. 120 [I-D.ietf-pce-stateful-pce] also describes the active stateful PCE. 121 The active PCE functionality allows a PCE to reroute an existing LSP 122 or make changes to the attributes of an existing LSP, or a PCC to 123 delegate control of specific LSPs to a new PCE. 125 1.1.1. Role of PCE in SDN 127 Software-Defined Networking (SDN) refers to a separation between the 128 control elements and the forwarding components so that software 129 running in a centralized system called a controller, can act to 130 program the devices in the network to behave in specific ways. A 131 required element in an SDN architecture is a component that plans how 132 the network resources will be used and how the devices will be 133 programmed. It is possible to view this component as performing 134 specific computations to place flows within the network given 135 knowledge of the availability of network resources, how other 136 forwarding devices are programmed, and the way that other flows are 137 routed. It is concluded in [RFC7399], that this is the same function 138 that a PCE might offer in a network operated using a dynamic control 139 plane. This is the function and purpose of a PCE, and the way that a 140 PCE integrates into a wider network control system including SDN is 141 presented in Application-Based Network Operation (ABNO) [RFC7491]. 143 1.1.2. PCE in multi-domain and multi-layer deployments 145 Computing paths across large multi-domain environments require 146 special computational components and cooperation between entities in 147 different domains capable of complex path computation. The PCE 148 provides an architecture and a set of functional components to 149 address this problem space. A PCE may be used to compute end-to-end 150 paths across multi-domain environments using a per-domain path 151 computation technique [RFC5152]. The Backward recursive PCE based 152 path computation (BRPC) mechanism [RFC5441] defines a PCE-based path 153 computation procedure to compute inter-domain constrained MPLS and 154 GMPLS TE networks. However, both per-domain and BRPC techniques 155 assume that the sequence of domains to be crossed from source to 156 destination is known, either fixed by the network operator or 157 obtained by other means. 159 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can 160 be used for computing end-to-end paths for inter-domain MPLS Traffic 161 Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the 162 domain sequence is not known. Within the Hierarchical PCE (H-PCE) 163 architecture, the Parent PCE (P-PCE) is used to compute a multi- 164 domain path based on the domain connectivity information. A Child 165 PCE (C-PCE) may be responsible for a single domain or multiple 166 domains, it is used to compute the intra-domain path based on its 167 domain topology information. 169 [I-D.dhodylee-pce-stateful-hpce] state the considerations for 170 stateful PCE(s) in hierarchical PCE architecture. In particular, the 171 behavior changes and additions to the existing stateful PCE 172 mechanisms (including PCE- initiated LSP setup and active PCE usage) 173 in the context of networks using the H-PCE architecture. 175 [RFC5623] describes a framework for applying the PCE-based 176 architecture to inter-layer to (G)MPLS TE. It provides suggestions 177 for the deployment of PCE in support of multi-layer networks. It 178 also describes the relationship between PCE and a functional 179 component in charge of the control and management of the VNT, called 180 the Virtual Network Topology Manager (VNTM). 182 1.2. Abstraction and Control of TE Networks (ACTN) 184 [I-D.ietf-teas-actn-requirements] describes the high-level ACTN 185 requirements. [I-D.ietf-teas-actn-framework] describes the 186 architecture model for ACTN including the entities (Customer Network 187 Controller(CNC), Mult-domain Service Coordinator(MDSC), and Physical 188 Network Controller(PNC)) and their interfaces. 190 The ACTN reference architecture identified a three-tier control 191 hierarchy as depicted in Figure 1: 193 +-------+ +-------+ +-------+ 194 | CNC-A | | CNC-B | | CNC-C | 195 +-------+ +-------+ +-------+ 196 \ | / 197 ---------- |-CMI I/F ----------- 198 \ | / 199 +-----------------------+ 200 | MDSC | 201 +-----------------------+ 202 / | \ 203 ---------- |-MMI I/F ----------- 204 / | \ 205 +----------+ +----------+ +--------+ 206 | MDSC | | MDSC | | MDSC | 207 +----------+ +----------+ +--------+ 208 | / |-MPI I/F / \ 209 | / | / \ 210 +-----+ +-----+ +-----+ +-----+ +-----+ 211 | PNC | | PNC | | PNC | | PNC | | PNC | 212 +-----+ +-----+ +-----+ +-----+ +-----+ 214 CMI - (CNC-MDSC Interface) 215 MMI - (MDSC-MDSC Interface) 216 MPI - (MDSC-PNC Interface) 218 Figure 1: ACTN Hierarchy 220 The two interfaces with respect to the MDSC, one north of the MDSC 221 Interface) and MPI (MDSC-PNC Interface), respectively. MMI (MDSC- 222 MDSC interface) is used to support recursion. 224 [I-D.ietf-teas-actn-info-model] provides an information model for 225 ACTN interfaces. 227 1.3. PCE and ACTN 229 This document examines the PCE and ACTN architecture and describes 230 how the PCE architecture is applicable to ACTN. It also lists the 231 PCEP extensions that are needed to use PCEP as an ACTN interface. 232 This document also identifies any gaps in PCEP, that exist at the 233 time of publication of this document. 235 2. Architectural Considerations 237 ACTN [I-D.ietf-teas-actn-framework] architecture is based on 238 hierarchy and recursiveness of controllers. It defines three types 239 of controllers (depending on the functionalities they implement). 240 The main functionalities are - 242 o Multi domain coordination function 244 o Virtualization/Abstraction function 246 o Customer mapping/translation function 248 o Virtual service coordination function 250 Section 3 of [I-D.ietf-teas-actn-framework] describes these 251 functions. 253 It should be noted that, in this document we list all possible ways 254 in which PCEP could be used for each of the above functions, but all 255 functions are not required to be implemented via PCEP. Operator may 256 choose to use the PCEP for multi domain coordination via stateful 257 H-PCE but use RestConf or BGP-LS to get the topology and support 258 virtualization/abstraction function. 260 2.1. Multi domain coordination via Hierarchy 262 With the definition of domain being "everything that is under the 263 control of the single logical controller", as per 264 [I-D.ietf-teas-actn-framework], it is needed to have a control entity 265 that oversees the specific aspects of the different domains and to 266 build a single abstracted end-to-end network topology in order to 267 coordinate end-to-end path computation and path/service provisioning. 269 The MDSC in ACTN framework realizes this function by coordinating the 270 per-domain PNCs in a hierarchy of controllers. It also needs to 271 detach from the underlying network technology and express customer 272 concerns by business needs. 274 [RFC6805] and [I-D.dhodylee-pce-stateful-hpce] describes a hierarchy 275 of PCE with Parent PCE coordinating multi-domain path computation 276 function between Child PCE(s). It is easy to see how these 277 principles align, and thus how stateful H-PCE architecture can be 278 used to realize ACTN. 280 The Per domain stitched LSP in the Hierarchical stateful PCE 281 architecture, described in Section 3.3.1 of 282 [I-D.dhodylee-pce-stateful-hpce] is well suited for multi-domain 283 coordination function. This includes domain sequence selection; E2E 284 path computation; Controller (PCE) initiated path setup and 285 reporting. This is also applicable to multi-layer coordination in 286 case of IP+optical networks. 288 [I-D.litkowski-pce-state-sync]" describes the procedures to allow a 289 stateful communication between PCEs for various use-cases. The 290 procedures and extensions are also applicable to Child and Parent PCE 291 communication and thus useful for ACTN as well. 293 2.2. Virtualization/Abstraction function 295 To realize ACTN, an abstracted view of the underlying network 296 resources needs to be built. This includes global network-wide 297 abstracted topology based on the underlying network resources of each 298 domain. This also include abstract topology created as per the 299 customer service connectivity requests and represented as a network 300 slice allocated to each customer. 302 In order to compute and provide optimal paths, PCEs require an 303 accurate and timely Traffic Engineering Database (TED). 304 Traditionally this TED has been obtained from a link state (LS) 305 routing protocol supporting traffic engineering extensions. PCE may 306 construct its TED by participating in the IGP ([RFC3630] and 307 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 308 alternative is offered by BGP-LS [RFC7752]. 310 In case of H-PCE [RFC6805], the parent PCE needs to build the domain 311 topology map of the child domains and their interconnectivity. 312 [RFC6805] and [I-D.ietf-pce-inter-area-as-applicability] suggest that 313 BGP-LS could be used as a "northbound" TE advertisement from the 314 child PCE to the parent PCE. 316 [I-D.dhodylee-pce-pcep-ls] proposes another approaches for learning 317 and maintaining the Link-State and TE information as an alternative 318 to IGPs and BGP flooding, using PCEP itself. The child PCE can use 319 this mechanism to transport Link-State and TE information from child 320 PCE to a Parent PCE using PCEP. 322 In ACTN, there is a need to control the level of abstraction based on 323 the deployment scenario and business relationship between the 324 controllers. The mechanism used to disseminate information from PNC 325 (child PCE) to MDSC (parent PCE) should support abstraction. 326 [I-D.lee-teas-actn-abstraction] describes a few alternative 327 approaches of abstraction. The resulting abstracted topology can be 328 encoded using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls]. 329 PCEP-LS is an attractive option when the operator would wish to have 330 a single control plane protocol (PCEP) to achieve ACTN functions. 332 2.3. Customer mapping function 334 In ACTN, there is a need to map customer virtual network (VN) 335 requirements into network provisioning request to the PNC. That is, 336 the customer requests/commands are mapped into network provisioning 337 requests that can be sent to the PNC. Specifically, it provides 338 mapping and translation of a customer's service request into a set of 339 parameters that are specific to a network type and technology such 340 that network configuration process is made possible. 342 [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and 343 teardown of PCE-initiated LSPs under the stateful PCE model, without 344 the need for local configuration on the PCC, thus allowing for a 345 dynamic network that is centrally controlled and deployed. To 346 instantiate or delete an LSP, the PCE sends the Path Computation LSP 347 Initiate Request (PCInitiate) message to the PCC. As described in 348 [I-D.dhodylee-pce-stateful-hpce], for inter-domain LSP in 349 Hierarchical PCE architecture, the initiation operations can be 350 carried out at the parent PCE. In which case after parent PCE 351 finishes the E2E path computation, it can send the PCInitiate message 352 to the child PCE, the child PCE further propagates the initiate 353 request to the LSR. The customer request is received by the MDSC 354 (parent PCE) and based on the business logic, global abstracted 355 topology, network conditions and local policy, the MDSC (parent PCE) 356 translates this into per domain LSP initiation request that a PNC 357 (child PCE) can understand and act on. This can be done via the 358 PCInitiate message. 360 PCEP extensions for associating opaque policy between PCEP peer 361 [I-D.ietf-pce-association-policy] can be used. 363 2.4. Virtual Network Operations 365 Virtual service coordination function in ACTN incorporates customer 366 service-related information into the virtual network service 367 operations in order to seamlessly operate virtual networks while 368 meeting customer's service requirements. 370 [I-D.leedhody-pce-vn-association] describes the need for associating 371 a set of LSPs with a VN "construct" to facilitate VN operations in 372 PCE architecture. This association allows the PCEs to identify which 373 LSPs belong to a certain VN. 375 This association based on VN is useful for various optimizations at 376 the VN level which can be applied to all the LSPs that are part of 377 the VN slice. During path computation, the impact of a path for an 378 LSP is compared against the paths of other LSPs in the VN. This is 379 to make sure that the overall optimization and SLA of the VN rather 380 than of a single LSP. Similarly, during re-optimization, advanced 381 path computation algorithm and optimization technique can be 382 considered for all the LSPs belonging to a VN/customer and optimize 383 them all together. 385 3. Interface Considerations 387 As per [I-D.ietf-teas-actn-framework], to allow virtualization and 388 multi domain coordination, the network has to provide open, 389 programmable interfaces, in which customer applications can create, 390 replace and modify virtual network resources and services in an 391 interactive, flexible and dynamic fashion while having no impact on 392 other customers. The 3 ACTN interfaces are - 394 o The CNC-MDSC Interface (CMI) is an interface between a Customer 395 Network Controller and a Multi Domain Service Coordinator. It 396 requests the creation of the network resources, topology or 397 services for the applications. The MDSC may also report potential 398 network topology availability if queried for current capability 399 from the Customer Network Controller. 401 o The MDSC-PNC Interface (MPI) is an interface between a Multi 402 Domain Service Coordinator and a Physical Network Controller. It 403 communicates the creation request, if required, of new 404 connectivity of bandwidth changes in the physical network, via the 405 PNC. In multi-domain environments, the MDSC needs to establish 406 multiple MPIs, one for each PNC, as there are multiple PNCs 407 responsible for its domain control. 409 o The MDSC-MDSC Interface (MMI) is a special case of the MPI and 410 behaves similarly to an MPI to support general functions performed 411 by the MDSCs such as abstraction function and provisioning 412 function. From an abstraction point of view, the top level MDSC 413 which interfaces the CNC operates on a higher level of abstraction 414 (i.e., less granular level) than the lower level MSDCs. As such, 415 the MMI carries more abstract TE information than the MPI. 417 PCEP is especially suitable on the MPI and MMI as it meets the 418 requirement and the functions as set out in the ACTN framework 419 [I-D.ietf-teas-actn-framework]. Its recursive nature is well suited 420 via the multi-level hierarchy of PCE. The Section 4 describe how PCE 421 and PCEP could help realize ACTN. 423 4. Realizining ACTN with PCE (and PCEP) 425 As per the example in the Figure 2, there are 4 domains, each with 426 its own PNC and a MDSC at top. The PNC and MDSC need PCE as a 427 important function. The PNC (or child PCE) already uses PCEP to 428 communicate to the network device. It can utilize the PCEP as the 429 MPI to communicate between controllers too. 431 ****** 432 ..........*MDSC*.............................. 433 . ****** .. MPI . 434 . . . . 435 . . . . 436 . . . . 437 . . . . 438 . . . . 439 . . . . 440 v v v . 441 ****** ****** ****** . 442 *PNC1* *PNC2* *PNC4* . 443 ****** ****** ****** . 444 +---------------+ +---------------+ +---------------+ . 445 |A |----| |----| C| . 446 | | | | | | . 447 |DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | . 448 +------------B13+ +---------------+ +B43------------+ . 449 \ / . 450 \ ****** / . 451 \ *PNC3*<............/..................... 452 \ ****** / 453 \+---------------+/ 454 B31 B34 455 | | 456 |DOMAIN 3 B| 457 +---------------+ 459 MDSC -> Parent PCE 460 PNC -> Child PCE 461 MPI -> PCEP 463 Figure 2: ACTN with PCE 465 o Building Domain Topology at MDSC: PNC (or child PCE) needs to have 466 the TED to compute path in its domain. As described in 467 Section 2.2, it can learn the topology via IGP or BGP-LS. PCEP-LS 468 is also a proposed mechanism to carry link state and traffic 469 engineering information within PCEP. A mechanism to carry 470 abstracted topology while hiding technology specific information 471 between PNC and MDSC is described in [I-D.dhodylee-pce-pcep-ls]. 472 At the end of this step the MDSC (or parent PCE) has the 473 abstracted topology from each of its PNC (or child PCE). This 474 could be as simple as a domain topology map as described in 476 [RFC6805] or it can have full topology information of all domains. 477 The latter is not scalable and thus an abstracted topology of each 478 domain interconnected by inter-domain links is the most common 479 case. 481 * Topology Change: When the PNC learns of any topology change, 482 the PNC needs to decide if the change needs to be notified to 483 the MDSC. This is dependent on the level of abstraction 484 between the MDSC and the PNC. 486 o VN Instantiate: MDSC is requested to instantiate a VN, the minimal 487 information that is required would be a VN identifier and a set of 488 end points. Various path computation, setup constraints and 489 objective functions may also be provided. In PCE terms, a VN 490 Instantiate can be considered as a set of paths belonging to the 491 same VN. As described in Section 2.4 and 492 [I-D.leedhody-pce-vn-association] the VN association can help in 493 identifying the set of paths that belong to a VN. The rest of the 494 information like the endpoints, constraints and objective function 495 is already defined in PCEP in terms of a single path. 497 * Path Computation: As per the example in the Figure 2, the VN 498 instantiate requires two end to end paths between (A in Domain 499 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The 500 MDSC (or parent PCE) triggers the end to end path computation 501 for these two paths. MDSC can do path computation based on the 502 abstracted domain topology that it already has or it may use 503 the H-PCE procedures (Section 2.1) using the PCReq and PCRep 504 messages to get the end to end path with the help of PNC. 505 Either way, the resulted E2E paths may be broken into per- 506 domain paths. 508 * A-B: (A-B13,B13-B31,B31-B) 510 * A-C: (A-B13,B13-B31,B34-B43,B43-C) 512 * Per Domain Path Instantiation: Based on the above path 513 computation, MDSC can issue the path instantiation request to 514 each PNC via PCInitiate message (see 515 [I-D.dhodylee-pce-stateful-hpce] and 516 [I-D.leedhody-pce-vn-association]). A suitable stitching 517 mechanism would be use to stitch these per domain LSPs. 519 * Per Domain Path Report: Each PNC should report the status of 520 the per-domain LSP to the MDSC via PCRpt message, as per the 521 Hierarchy of stateful PCE ([I-D.dhodylee-pce-stateful-hpce]). 522 The status of the end to end LSP (A-B and A-C) is made up when 523 all the per domain LSP are reported up by the PNCs. 525 * Delegation: It is suggested that the per domain LSPs are 526 delegated to respective PNC, so that they can control the path 527 and attributes based on each domain network conditions. 529 * State Synchronization: The state needs to be synchronized 530 between the parent PCE and child PCE. The mechanism described 531 in [I-D.litkowski-pce-state-sync] can be used. 533 o VN Modify: MDSC is requested to modify a VN, for example the 534 bandwidth for VN is increased. This may trigger path computation 535 at MDSC as described in the previous step and can trigger an 536 update to existing per-intra-domain path (via PCUpd message) or 537 creation (or deletion) of a per-domain path (via PCInitiate 538 message). This should be done in make-before-break fashion. 540 o VN Delete: MDSC is requested to delete a VN, in this case, based 541 on the E2E paths and the resulting per-domain paths need to be 542 removed (via PCInitiate message). 544 o VN Update (based on network changes): Any change in the per-domain 545 LSP are reported to the MDSC (via PCRpt message) as per 546 [I-D.dhodylee-pce-stateful-hpce]. This may result in changes in 547 the E2E path or VN status. This may also trigger a re- 548 optimization leading to a new per-domain path, update to existing 549 path, or deletion of the path. 551 o VN Protection: The VN protection/restoration requirements, need to 552 applied to each E2E path as well as each per domain path. The 553 MDSC needs to play a crucial role in coordinating the right 554 protection/restoration policy across each PNC. The existing 555 protection/restoration mechanism of PCEP can be applied on each 556 path. 558 o In case PNC generates an abstract topology to the MDSC, the 559 PCInitiate/PCUpd messages from the MDSC to a PNC will contain a 560 path with abstract nodes and links. PNC would need to take that 561 as an input for path computation to get a path with physical nodes 562 and links. Similarly PNC would convert the path received from the 563 device (with physical nodes and links) into abstract path (based 564 on the abstract topology generated before with abstract nodes and 565 links) and reported to the MDSC. 567 5. Relationship to PCE based central control 569 [I-D.ietf-teas-pce-central-control] introduces the architecture for 570 PCE as a central controller (PCECC), it further examines the 571 motivations and applicability for PCEP as a southbound interface, and 572 introduces the implications for the protocol. The section 2.1.3 of 574 [I-D.ietf-teas-pce-central-control] describe an hierarchy of PCE- 575 based controller as per the Hierarchy of PCE framework defined in 576 [RFC6805]. Both ACTN and PCECC is based on the same basic framework 577 and thus compatible with each other. 579 6. IANA Considerations 581 This is an informational document and thus does not have any IANA 582 allocations to be made. 584 7. Security Considerations 586 The ACTN framework described in [I-D.ietf-teas-actn-framework] 587 defines key components and interfaces for managed traffic engineered 588 networks. It also list various security considerations such as 589 request and control of resources, confidentially of the information, 590 and availability of function which should be taken into 591 consideration. 593 When PCEP is used on the MPI/MMI, this interface needs to be secured, 594 use of [I-D.ietf-pce-pceps] is RECOMENDED. Each PCEP extension 595 listed in this document, presents its individual security 596 considerations, which continue to apply. 598 8. Acknowledgments 600 The authors would like to thank Jonathan Hardwick for the inspiration 601 behind this document. Further thanks to Avantika for her comments 602 with suggested text. 604 9. References 606 9.1. Normative References 608 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 609 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 610 DOI 10.17487/RFC5440, March 2009, 611 . 613 9.2. Informative References 615 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 616 (TE) Extensions to OSPF Version 2", RFC 3630, 617 DOI 10.17487/RFC3630, September 2003, 618 . 620 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 621 Support of Generalized Multi-Protocol Label Switching 622 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 623 . 625 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 626 Element (PCE)-Based Architecture", RFC 4655, 627 DOI 10.17487/RFC4655, August 2006, 628 . 630 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 631 Per-Domain Path Computation Method for Establishing Inter- 632 Domain Traffic Engineering (TE) Label Switched Paths 633 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 634 . 636 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 637 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 638 2008, . 640 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 641 in Support of Generalized Multi-Protocol Label Switching 642 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 643 . 645 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 646 "A Backward-Recursive PCE-Based Computation (BRPC) 647 Procedure to Compute Shortest Constrained Inter-Domain 648 Traffic Engineering Label Switched Paths", RFC 5441, 649 DOI 10.17487/RFC5441, April 2009, 650 . 652 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 653 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 654 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 655 September 2009, . 657 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 658 Path Computation Element Architecture to the Determination 659 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 660 DOI 10.17487/RFC6805, November 2012, 661 . 663 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 664 Computation Element Architecture", RFC 7399, 665 DOI 10.17487/RFC7399, October 2014, 666 . 668 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 669 Application-Based Network Operations", RFC 7491, 670 DOI 10.17487/RFC7491, March 2015, 671 . 673 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 674 S. Ray, "North-Bound Distribution of Link-State and 675 Traffic Engineering (TE) Information Using BGP", RFC 7752, 676 DOI 10.17487/RFC7752, March 2016, 677 . 679 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 680 Stateful Path Computation Element (PCE)", RFC 8051, 681 DOI 10.17487/RFC8051, January 2017, 682 . 684 [I-D.ietf-pce-stateful-pce] 685 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 686 Extensions for Stateful PCE", draft-ietf-pce-stateful- 687 pce-18 (work in progress), December 2016. 689 [I-D.ietf-pce-pce-initiated-lsp] 690 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 691 Extensions for PCE-initiated LSP Setup in a Stateful PCE 692 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 693 progress), March 2017. 695 [I-D.dhodylee-pce-stateful-hpce] 696 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 697 and O. Dios, "Hierarchical Stateful Path Computation 698 Element (PCE).", draft-dhodylee-pce-stateful-hpce-03 (work 699 in progress), March 2017. 701 [I-D.ietf-teas-pce-central-control] 702 Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An 703 Architecture for Use of PCE and PCEP in a Network with 704 Central Control", draft-ietf-teas-pce-central-control-01 705 (work in progress), December 2016. 707 [I-D.ietf-teas-actn-requirements] 708 Lee, Y., Dhody, D., Belotti, S., Pithewan, K., and D. 709 Ceccarelli, "Requirements for Abstraction and Control of 710 TE Networks", draft-ietf-teas-actn-requirements-04 (work 711 in progress), January 2017. 713 [I-D.ietf-teas-actn-framework] 714 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 715 Control of Traffic Engineered Networks", draft-ietf-teas- 716 actn-framework-04 (work in progress), February 2017. 718 [I-D.ietf-teas-actn-info-model] 719 Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 720 Yoon, "Information Model for Abstraction and Control of TE 721 Networks (ACTN)", draft-ietf-teas-actn-info-model-00 (work 722 in progress), February 2017. 724 [I-D.ietf-pce-inter-area-as-applicability] 725 King, D., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and 726 O. Dios, "Applicability of the Path Computation Element to 727 Inter-Area and Inter-AS MPLS and GMPLS Traffic 728 Engineering", draft-ietf-pce-inter-area-as- 729 applicability-06 (work in progress), July 2016. 731 [I-D.dhodylee-pce-pcep-ls] 732 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 733 Distribution of Link-State and TE Information.", draft- 734 dhodylee-pce-pcep-ls-07 (work in progress), March 2017. 736 [I-D.leedhody-pce-vn-association] 737 Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP 738 Extensions for Establishing Relationships Between Sets of 739 LSPs and Virtual Networks", draft-leedhody-pce-vn- 740 association-02 (work in progress), March 2017. 742 [I-D.litkowski-pce-state-sync] 743 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 744 Stateful Path Computation Element communication 745 procedures", draft-litkowski-pce-state-sync-01 (work in 746 progress), February 2017. 748 [I-D.ietf-pce-association-policy] 749 Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and 750 J. Hardwick, "Path Computation Element communication 751 Protocol extension for associating Policies and LSPs", 752 draft-ietf-pce-association-policy-00 (work in progress), 753 December 2016. 755 [I-D.ietf-pce-pceps] 756 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 757 Transport for PCEP", draft-ietf-pce-pceps-11 (work in 758 progress), January 2017. 760 [I-D.lee-teas-actn-abstraction] 761 Lee, Y., Dhody, D., Ceccarelli, D., and O. Dios, 762 "Abstraction and Control of TE Networks (ACTN) Abstraction 763 Methods", draft-lee-teas-actn-abstraction-00 (work in 764 progress), October 2016. 766 Authors' Addresses 768 Dhruv Dhody 769 Huawei Technologies 770 Divyashree Techno Park, Whitefield 771 Bangalore, Karnataka 560066 772 India 774 EMail: dhruv.ietf@gmail.com 776 Young Lee 777 Huawei Technologies 778 5340 Legacy Drive, Building 3 779 Plano, TX 75023 780 USA 782 EMail: leeyoung@huawei.com 784 Daniele Ceccarelli 785 Ericsson 786 Torshamnsgatan,48 787 Stockholm 788 Sweden 790 EMail: daniele.ceccarelli@ericsson.com