--- 1/draft-ietf-pce-applicability-actn-00.txt 2017-06-29 03:13:08.477858097 -0700 +++ 2/draft-ietf-pce-applicability-actn-01.txt 2017-06-29 03:13:08.521859140 -0700 @@ -1,21 +1,21 @@ PCE Working Group D. Dhody Internet-Draft Y. Lee Intended status: Informational Huawei Technologies -Expires: December 3, 2017 D. Ceccarelli +Expires: December 31, 2017 D. Ceccarelli Ericsson - June 1, 2017 + June 29, 2017 Applicability of Path Computation Element (PCE) for Abstraction and Control of TE Networks (ACTN) - draft-ietf-pce-applicability-actn-00 + draft-ietf-pce-applicability-actn-01 Abstract Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network 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 http://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 3, 2017. + This Internet-Draft will expire on December 31, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -66,27 +66,27 @@ 1.1.2. PCE in multi-domain and multi-layer deployments . . . 4 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 4 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 5 2. Architectural Considerations . . . . . . . . . . . . . . . . 6 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 6 2.2. Virtualization/Abstraction function . . . . . . . . . . . 7 2.3. Customer mapping function . . . . . . . . . . . . . . . . 8 2.4. Virtual Network Operations . . . . . . . . . . . . . . . 8 3. Interface Considerations . . . . . . . . . . . . . . . . . . 9 4. Realizining ACTN with PCE (and PCEP) . . . . . . . . . . . . 9 - 5. Relationship to PCE based central control . . . . . . . . . . 12 + 5. Relationship to PCE based central control . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 9.2. Informative References . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction 1.1. Path Computation Element (PCE) The Path Computation Element communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Elements (PCEs) [RFC4655] to perform path computations in response to Path Computation Clients (PCCs) requests. @@ -159,25 +159,25 @@ [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can be used for computing end-to-end paths for inter-domain MPLS Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the domain sequence is not known. Within the Hierarchical PCE (H-PCE) architecture, the Parent PCE (P-PCE) is used to compute a multi- domain path based on the domain connectivity information. A Child PCE (C-PCE) may be responsible for a single domain or multiple domains, it is used to compute the intra-domain path based on its domain topology information. - [I-D.dhodylee-pce-stateful-hpce] state the considerations for - stateful PCE(s) in hierarchical PCE architecture. In particular, the - behavior changes and additions to the existing stateful PCE - mechanisms (including PCE- initiated LSP setup and active PCE usage) - in the context of networks using the H-PCE architecture. + [I-D.ietf-pce-stateful-hpce] state the considerations for stateful + PCE(s) in hierarchical PCE architecture. In particular, the behavior + changes and additions to the existing stateful PCE mechanisms + (including PCE- initiated LSP setup and active PCE usage) in the + context of networks using the H-PCE architecture. [RFC5623] describes a framework for applying the PCE-based architecture to inter-layer to (G)MPLS TE. It provides suggestions for the deployment of PCE in support of multi-layer networks. It also describes the relationship between PCE and a functional component in charge of the control and management of the VNT, called the Virtual Network Topology Manager (VNTM). 1.2. Abstraction and Control of TE Networks (ACTN) @@ -264,29 +264,29 @@ [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. 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.dhodylee-pce-stateful-hpce] describes a hierarchy - of PCE with Parent PCE coordinating multi-domain path computation + [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 used to realize ACTN. The Per domain stitched LSP in the Hierarchical stateful PCE architecture, described in Section 3.3.1 of - [I-D.dhodylee-pce-stateful-hpce] is well suited for multi-domain + [I-D.ietf-pce-stateful-hpce] is well suited for multi-domain 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. @@ -338,31 +338,30 @@ 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. [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. To instantiate or delete an LSP, the PCE sends the Path Computation LSP Initiate Request (PCInitiate) message to the PCC. As described in - [I-D.dhodylee-pce-stateful-hpce], for inter-domain LSP in - Hierarchical PCE architecture, the initiation operations can be - carried out at the parent PCE. In which case after parent PCE - finishes the E2E path computation, it can send the PCInitiate message - to the child PCE, the child PCE further propagates the initiate - request to the LSR. The customer request is received by the MDSC - (parent PCE) and based on the business logic, global abstracted - topology, network conditions and local policy, the MDSC (parent PCE) - translates this into per domain LSP initiation request that a PNC - (child PCE) can understand and act on. This can be done via the - PCInitiate message. + [I-D.ietf-pce-stateful-hpce], for inter-domain LSP in Hierarchical + PCE architecture, the initiation operations can be carried out at the + parent PCE. In which case after parent PCE finishes the E2E path + computation, it can send the PCInitiate message to the child PCE, the + child PCE further propagates the initiate request to the LSR. The + customer request is received by the MDSC (parent PCE) and based on + the business logic, global abstracted topology, network conditions + and local policy, the MDSC (parent PCE) translates this into per + domain LSP initiation request that a PNC (child PCE) can understand + and act on. This can be done via the PCInitiate message. PCEP extensions for associating opaque policy between PCEP peer [I-D.ietf-pce-association-policy] can be used. 2.4. Virtual Network Operations Virtual service coordination function in ACTN incorporates customer service-related information into the virtual network service operations in order to seamlessly operate virtual networks while meeting customer's service requirements. @@ -505,29 +504,32 @@ Either way, the resulted E2E paths may be broken into per- domain paths. * A-B: (A-B13,B13-B31,B31-B) * A-C: (A-B13,B13-B31,B34-B43,B43-C) * Per Domain Path Instantiation: Based on the above path computation, MDSC can issue the path instantiation request to each PNC via PCInitiate message (see - [I-D.dhodylee-pce-stateful-hpce] and + [I-D.ietf-pce-stateful-hpce] and [I-D.leedhody-pce-vn-association]). A suitable stitching - mechanism would be use to stitch these per domain LSPs. + mechanism would be use to stitch these per domain LSPs. One + such mechanism is described in + [I-D.lee-pce-lsp-stitching-hpce], where PCEP is extended to + support stitching in stateful H-PCE context. * Per Domain Path Report: Each PNC should report the status of the per-domain LSP to the MDSC via PCRpt message, as per the - Hierarchy of stateful PCE ([I-D.dhodylee-pce-stateful-hpce]). - The status of the end to end LSP (A-B and A-C) is made up when - all the per domain LSP are reported up by the PNCs. + Hierarchy of stateful PCE ([I-D.ietf-pce-stateful-hpce]). The + status of the end to end LSP (A-B and A-C) is made up when all + the per domain LSP are reported up by the PNCs. * Delegation: It is suggested that the per domain LSPs are delegated to respective PNC, so that they can control the path and attributes based on each domain network conditions. * State Synchronization: The state needs to be synchronized between the parent PCE and child PCE. The mechanism described in [I-D.litkowski-pce-state-sync] can be used. o VN Modify: MDSC is requested to modify a VN, for example the @@ -536,24 +538,24 @@ update to existing per-intra-domain path (via PCUpd message) or creation (or deletion) of a per-domain path (via PCInitiate message). This should be done in make-before-break fashion. o VN Delete: MDSC is requested to delete a VN, in this case, based on the E2E paths and the resulting per-domain paths need to be removed (via PCInitiate message). o VN Update (based on network changes): Any change in the per-domain LSP are reported to the MDSC (via PCRpt message) as per - [I-D.dhodylee-pce-stateful-hpce]. This may result in changes in - the E2E path or VN status. This may also trigger a re- - optimization leading to a new per-domain path, update to existing - path, or deletion of the path. + [I-D.ietf-pce-stateful-hpce]. This may result in changes in the + E2E path or VN status. This may also trigger a re-optimization + leading to a new per-domain path, update to existing path, or + deletion of the path. o VN Protection: The VN protection/restoration requirements, need to applied to each E2E path as well as each per domain path. The MDSC needs to play a crucial role in coordinating the right protection/restoration policy across each PNC. The existing protection/restoration mechanism of PCEP can be applied on each path. o In case PNC generates an abstract topology to the MDSC, the PCInitiate/PCUpd messages from the MDSC to a PNC will contain a @@ -677,98 +678,104 @@ . [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, . [I-D.ietf-pce-stateful-pce] Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful- - pce-19 (work in progress), May 2017. + pce-21 (work in progress), June 2017. [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE - Model", draft-ietf-pce-pce-initiated-lsp-09 (work in - progress), March 2017. + Model", draft-ietf-pce-pce-initiated-lsp-10 (work in + progress), June 2017. - [I-D.dhodylee-pce-stateful-hpce] + [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-dhodylee-pce-stateful-hpce-03 (work - in progress), March 2017. + Element (PCE).", draft-ietf-pce-stateful-hpce-00 (work in + progress), June 2017. [I-D.ietf-teas-pce-central-control] Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An Architecture for Use of PCE and PCEP in a Network with - Central Control", draft-ietf-teas-pce-central-control-02 - (work in progress), May 2017. + Central Control", draft-ietf-teas-pce-central-control-03 + (work in progress), June 2017. [I-D.ietf-teas-actn-requirements] Lee, Y., Dhody, D., Belotti, S., Pithewan, K., Ceccarelli, D., Miyasaka, T., and J. Shin, "Requirements for Abstraction and Control of TE Networks", draft-ietf-teas- actn-requirements-05 (work in progress), May 2017. [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-05 (work in progress), May 2017. + actn-framework-06 (work in progress), June 2017. [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-00 (work - in progress), February 2017. + Networks (ACTN)", draft-ietf-teas-actn-info-model-01 (work + in progress), June 2017. [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-07 (work in progress), March 2017. + dhodylee-pce-pcep-ls-08 (work in progress), June 2017. [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-02 (work in progress), March 2017. [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-01 (work in progress), February 2017. [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-00 (work in progress), - December 2016. + draft-ietf-pce-association-policy-01 (work in progress), + June 2017. [I-D.ietf-pce-pceps] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", draft-ietf-pce-pceps-14 (work in progress), May 2017. [I-D.lee-teas-actn-abstraction] Lee, Y., Dhody, D., Ceccarelli, D., and O. Dios, "Abstraction and Control of TE Networks (ACTN) Abstraction - Methods", draft-lee-teas-actn-abstraction-01 (work in - progress), March 2017. + Methods", draft-lee-teas-actn-abstraction-02 (work in + progress), June 2017. + + [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-00 (work in progress), + June 2017. Authors' Addresses Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com