--- 1/draft-ietf-pce-applicability-actn-06.txt 2018-10-22 04:13:57.828408231 -0700 +++ 2/draft-ietf-pce-applicability-actn-07.txt 2018-10-22 04:13:57.872409283 -0700 @@ -1,21 +1,21 @@ PCE Working Group D. Dhody Internet-Draft Y. Lee Intended status: Informational Huawei Technologies -Expires: December 19, 2018 D. Ceccarelli +Expires: April 25, 2019 D. Ceccarelli Ericsson - June 17, 2018 + October 22, 2018 Applicability of Path Computation Element (PCE) for Abstraction and Control of TE Networks (ACTN) - draft-ietf-pce-applicability-actn-06 + draft-ietf-pce-applicability-actn-07 Abstract Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control and manage large-scale multi-domain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service aware connectivity and network function virtualization services. @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 19, 2018. + This Internet-Draft will expire on April 25, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,25 +59,25 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Path Computation Element (PCE) . . . . . . . . . . . . . 2 1.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 3 1.1.2. PCE in multi-domain and multi-layer deployments . . . 4 1.1.3. Relationship to PCE based central control . . . . . . 4 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5 - 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 7 + 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 6 2. Architectural Considerations . . . . . . . . . . . . . . . . 7 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 7 - 2.2. Abstraction function . . . . . . . . . . . . . . . . . . 8 - 2.3. Customer mapping function . . . . . . . . . . . . . . . . 9 + 2.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.3. Customer mapping . . . . . . . . . . . . . . . . . . . . 9 2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 3. Interface Considerations . . . . . . . . . . . . . . . . . . 10 4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 @@ -183,24 +183,24 @@ [RFC8283] introduces the architecture for PCE as a central controller (PCECC), it further examines the motivations and applicability for PCEP as a southbound interface, and introduces the implications for the protocol. The section 2.1.3 of [RFC8283] describe an hierarchy of PCE-based controller as per the Hierarchy of PCE framework defined in [RFC6805]. 1.2. Abstraction and Control of TE Networks (ACTN) [I-D.ietf-teas-actn-requirements] describes the high-level ACTN - requirements. [I-D.ietf-teas-actn-framework] describes the - architecture model for ACTN including the entities (Customer Network - Controller(CNC), Multi-domain Service Coordinator(MDSC), and - Provisioning Network Controller (PNC) and their interfaces. + requirements. [RFC8453] describes the architecture model for ACTN + including the entities (Customer Network Controller(CNC), Multi- + domain Service Coordinator(MDSC), and Provisioning Network Controller + (PNC) and their interfaces. The ACTN reference architecture identified a three-tier control hierarchy as depicted in Figure 1: +---------+ +---------+ +---------+ | CNC | | CNC | | CNC | +---------+ +---------+ +---------+ \ | / \ | / Boundary =============\==============|==============/============ @@ -231,67 +231,65 @@ CMI - (CNC-MDSC Interface) MPI - (MDSC-PNC Interface) Figure 1: ACTN Hierarchy The two interfaces with respect to the MDSC, one north of the MDSC (CMI CNC-MDSC Interface) and one south (MPI MDSC-PNC Interface). A hierarchy of MDSC is possible with a recursive MPI interface. - [I-D.ietf-teas-actn-info-model] provides an information model for - ACTN interfaces. + [RFC8454] provides an information model for ACTN interfaces. 1.3. PCE and ACTN This document examines the PCE and ACTN architecture and describes how the PCE architecture is applicable to ACTN. It also lists the PCEP extensions that are needed to use PCEP as an ACTN interface. + This document also identifies any gaps in PCEP, that exist at the time of publication of this document. Further, ACTN, Stateful H-PCE, and PCECC are based on the same basic hierarchy framework and thus compatible with each other. 2. Architectural Considerations - ACTN [I-D.ietf-teas-actn-framework] architecture is based on - hierarchy and recursiveness of controllers. It defines three types - of controllers (depending on the functionalities they implement). - The main functionalities are - + ACTN [RFC8453] architecture is based on hierarchy and recursiveness + of controllers. It defines three types of controllers (depending on + the functionalities they implement). The main functionalities are - - o Multi domain coordination function + o Multi domain coordination - o Abstraction function + o Abstraction - o Customer mapping/translation function + o Customer mapping/translation - o Virtual service coordination function + o Virtual service coordination - Section 3 of [I-D.ietf-teas-actn-framework] describes these - functions. + Section 3 of [RFC8453] describes these functions. It should be noted that, this document lists all possible ways in which PCEP could be used for each of the above functions, but all functions are not required to be implemented via PCEP. Operator may choose to use the PCEP for multi domain coordination via stateful H-PCE but use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get the topology and support abstraction function. 2.1. Multi domain coordination via Hierarchy With the definition of domain being "everything that is under the - control of the single logical controller", as per - [I-D.ietf-teas-actn-framework], it is needed to have a control entity - that oversees the specific aspects of the different domains and to - build a single abstracted end-to-end network topology in order to - coordinate end-to-end path computation and path/service provisioning. + control of the single logical controller", as per [RFC8453], it is + needed to have a control entity that oversees the specific aspects of + the different domains and to build a single abstracted end-to-end + network topology in order to coordinate end-to-end path computation + and path/service provisioning. The MDSC in ACTN framework realizes this function by coordinating the per-domain PNCs in a hierarchy of controllers. It also needs to detach from the underlying network technology and express customer concerns by business needs. [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy of PCE with Parent PCE coordinating multi-domain path computation function between Child PCE(s). It is easy to see how these principles align, and thus how stateful H-PCE architecture can be @@ -303,21 +301,21 @@ coordination function. This includes domain sequence selection; E2E path computation; Controller (PCE) initiated path setup and reporting. This is also applicable to multi-layer coordination in case of IP+optical networks. [I-D.litkowski-pce-state-sync]" describes the procedures to allow a stateful communication between PCEs for various use-cases. The procedures and extensions are also applicable to Child and Parent PCE communication and thus useful for ACTN as well. -2.2. Abstraction function +2.2. Abstraction To realize ACTN, an abstracted view of the underlying network resources needs to be built. This includes global network-wide abstracted topology based on the underlying network resources of each domain. This also include abstract topology created as per the customer service connectivity requests and represented as a network slice allocated to each customer. In order to compute and provide optimal paths, PCEs require an accurate and timely Traffic Engineering Database (TED). @@ -336,40 +334,40 @@ [I-D.dhodylee-pce-pcep-ls] proposes another approaches for learning and maintaining the Link-State and TE information as an alternative to IGPs and BGP flooding, using PCEP itself. The child PCE can use this mechanism to transport Link-State and TE information from child PCE to a Parent PCE using PCEP. In ACTN, there is a need to control the level of abstraction based on the deployment scenario and business relationship between the controllers. The mechanism used to disseminate information from PNC (child PCE) to MDSC (parent PCE) should support abstraction. - [I-D.ietf-teas-actn-framework] describes a few alternative approaches - of abstraction. The resulting abstracted topology can be encoded - using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls] and its - optical network extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is - an attractive option when the operator would wish to have a single - control plane protocol (PCEP) to achieve ACTN functions. + [RFC8453] describes a few alternative approaches of abstraction. The + resulting abstracted topology can be encoded using the PCEP-LS + mechanisms [I-D.dhodylee-pce-pcep-ls] and its optical network + extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is an attractive + option when the operator would wish to have a single control plane + protocol (PCEP) to achieve ACTN functions. - [I-D.ietf-teas-actn-framework] discusses two ways to build abstract - topology from an MDSC standpoint with interaction with PNCs. The - primary method is called automatic generation of abstract topology by - configuration. With this method, automatic generation is based on - the abstraction/summarization of the whole domain by the PNC and its - advertisement on the MPI. The secondary method is called on-demand - generation of supplementary topology via Path Compute Request/Reply. - This method may be needed to obtain further complementary information - such as potential connectivity from child PCEs in order to facilitate - an end-to-end path provisioning. PCEP is well suited to support both + [RFC8453] discusses two ways to build abstract topology from an MDSC + standpoint with interaction with PNCs. The primary method is called + automatic generation of abstract topology by configuration. With + this method, automatic generation is based on the abstraction/ + summarization of the whole domain by the PNC and its advertisement on + the MPI. The secondary method is called on-demand generation of + supplementary topology via Path Compute Request/Reply. This method + may be needed to obtain further complementary information such as + potential connectivity from child PCEs in order to facilitate an end- + to-end path provisioning. PCEP is well suited to support both methods. -2.3. Customer mapping function +2.3. Customer mapping In ACTN, there is a need to map customer virtual network (VN) requirements into network provisioning request to the PNC. That is, the customer requests/commands are mapped into network provisioning requests that can be sent to the PNC. Specifically, it provides mapping and translation of a customer's service request into a set of parameters that are specific to a network type and technology such that network configuration process is made possible. [RFC8281] describes the setup, maintenance and teardown of PCE- @@ -409,26 +407,26 @@ the VN slice. During path computation, the impact of a path for an LSP is compared against the paths of other LSPs in the VN. This is to make sure that the overall optimization and SLA of the VN rather than of a single LSP. Similarly, during re-optimization, advanced path computation algorithm and optimization technique can be considered for all the LSPs belonging to a VN/customer and optimize them all together. 3. Interface Considerations - As per [I-D.ietf-teas-actn-framework], to allow virtualization and - multi domain coordination, the network has to provide open, - programmable interfaces, in which customer applications can create, - replace and modify virtual network resources and services in an - interactive, flexible and dynamic fashion while having no impact on - other customers. The two ACTN interfaces are - + As per [RFC8453], to allow virtualization and multi domain + coordination, the network has to provide open, programmable + interfaces, in which customer applications can create, replace and + modify virtual network resources and services in an interactive, + flexible and dynamic fashion while having no impact on other + customers. The two ACTN interfaces are - o The CNC-MDSC Interface (CMI) is an interface between a Customer Network Controller and a Multi Domain Service Coordinator. It requests the creation of the network resources, topology or services for the applications. The MDSC may also report potential network topology availability if queried for current capability from the Customer Network Controller. o The MDSC-PNC Interface (MPI) is an interface between a Multi Domain Service Coordinator and a Provisioning Network Controller. @@ -438,26 +435,26 @@ PNC. In multi-domain environments, the MDSC needs to establish multiple MPIs, one for each PNC, as there are multiple PNCs responsible for its domain control. o In case of hierarchy of MDSC, the MPI is applied recursively. From an abstraction point of view, the top level MDSC which interfaces the CNC operates on a higher level of abstraction (i.e., less granular level) than the lower level MSDCs. PCEP is especially suitable on the MPI as it meets the requirement - and the functions as set out in the ACTN framework - [I-D.ietf-teas-actn-framework]. Its recursive nature is well suited - via the multi-level hierarchy of PCE. PCEP can also be applied to - the CMI as the CNC can be a path computation client while the MDSC - can be a path computation server. The Section 4 describe how PCE and - PCEP could help realize ACTN on the MPI. + and the functions as set out in the ACTN framework [RFC8453]. Its + recursive nature is well suited via the multi-level hierarchy of PCE. + PCEP can also be applied to the CMI as the CNC can be a path + computation client while the MDSC can be a path computation server. + The Section 4 describe how PCE and PCEP could help realize ACTN on + the MPI. 4. Realizing ACTN with PCE (and PCEP) As per the example in the Figure 2, there are 4 domains, each with its own PNC and a MDSC at top. The PNC and MDSC need PCE as a important function. The PNC (or child PCE) already uses PCEP to communicate to the network device. It can utilize the PCEP as the MPI to communicate between controllers too. ****** @@ -599,26 +596,25 @@ on the abstract topology generated before with abstract nodes and links) and reported to the MDSC. 5. IANA Considerations This is an informational document and thus does not have any IANA allocations to be made. 6. Security Considerations - The ACTN framework described in [I-D.ietf-teas-actn-framework] - defines key components and interfaces for managed traffic engineered - networks. It also list various security considerations such as - request and control of resources, confidentially of the information, - and availability of function which should be taken into - consideration. + The ACTN framework described in [RFC8453] defines key components and + interfaces for managed traffic engineered networks. It also list + various security considerations such as request and control of + resources, confidentially of the information, and availability of + function which should be taken into consideration. When PCEP is used on the MPI, this interface needs to be secured, use of [RFC8253] is RECOMENDED. Each PCEP extension listed in this document, presents its individual security considerations, which continue to apply. 7. Acknowledgments The authors would like to thank Jonathan Hardwick for the inspiration behind this document. Further thanks to Avantika for her comments @@ -632,24 +628,24 @@ Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, . - [I-D.ietf-teas-actn-framework] - Ceccarelli, D. and Y. Lee, "Framework for Abstraction and - Control of Traffic Engineered Networks", draft-ietf-teas- - actn-framework-15 (work in progress), May 2018. + [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for + Abstraction and Control of TE Networks (ACTN)", RFC 8453, + DOI 10.17487/RFC8453, August 2018, + . 8.2. Informative References [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, . [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching @@ -741,75 +737,74 @@ Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, . + [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. + Yoon, "Information Model for Abstraction and Control of TE + Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, + September 2018, . + [I-D.ietf-pce-stateful-hpce] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., and O. Dios, "Hierarchical Stateful Path Computation - Element (PCE).", draft-ietf-pce-stateful-hpce-04 (work in - progress), March 2018. + Element (PCE).", draft-ietf-pce-stateful-hpce-05 (work in + progress), June 2018. [I-D.ietf-teas-actn-requirements] Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. Lee, "Requirements for Abstraction and Control of TE Networks", draft-ietf-teas-actn-requirements-09 (work in progress), March 2018. - [I-D.ietf-teas-actn-info-model] - Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. - Yoon, "Information Model for Abstraction and Control of TE - Networks (ACTN)", draft-ietf-teas-actn-info-model-09 (work - in progress), June 2018. - [I-D.ietf-pce-inter-area-as-applicability] King, D., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and O. Dios, "Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as- applicability-06 (work in progress), July 2016. [I-D.dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Distribution of Link-State and TE Information.", draft- - dhodylee-pce-pcep-ls-10 (work in progress), March 2018. + dhodylee-pce-pcep-ls-11 (work in progress), June 2018. [I-D.lee-pce-pcep-ls-optical] - Lee, Y., zhenghaomian@huawei.com, z., Ceccarelli, D., - weiw@bupt.edu.cn, w., Park, P., and B. Yoon, "PCEP - Extension for Distribution of Link-State and TE - information for Optical Networks", draft-lee-pce-pcep-ls- - optical-04 (work in progress), February 2018. + Lee, Y., Zheng, H., Ceccarelli, D., weiw@bupt.edu.cn, w., + Park, P., and B. Yoon, "PCEP Extension for Distribution of + Link-State and TE information for Optical Networks", + draft-lee-pce-pcep-ls-optical-05 (work in progress), + September 2018. [I-D.leedhody-pce-vn-association] Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP Extensions for Establishing Relationships Between Sets of LSPs and Virtual Networks", draft-leedhody-pce-vn- - association-04 (work in progress), February 2018. + association-05 (work in progress), June 2018. [I-D.litkowski-pce-state-sync] Litkowski, S., Sivabalan, S., and D. Dhody, "Inter Stateful Path Computation Element communication procedures", draft-litkowski-pce-state-sync-03 (work in progress), April 2018. [I-D.ietf-pce-association-policy] Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and J. Hardwick, "Path Computation Element communication Protocol extension for associating Policies and LSPs", - draft-ietf-pce-association-policy-02 (work in progress), - February 2018. + draft-ietf-pce-association-policy-03 (work in progress), + June 2018. [I-D.lee-pce-lsp-stitching-hpce] Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions for Stitching LSPs in Hierarchical Stateful PCE Model", draft-lee-pce-lsp-stitching-hpce-01 (work in progress), December 2017. Authors' Addresses Dhruv Dhody