--- 1/draft-ietf-pce-applicability-actn-11.txt 2019-05-16 22:13:12.737773101 -0700 +++ 2/draft-ietf-pce-applicability-actn-12.txt 2019-05-16 22:13:12.785774315 -0700 @@ -1,21 +1,21 @@ PCE Working Group D. Dhody Internet-Draft Y. Lee Intended status: Informational Huawei Technologies -Expires: October 8, 2019 D. Ceccarelli +Expires: November 17, 2019 D. Ceccarelli Ericsson - April 6, 2019 + May 16, 2019 Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) - draft-ietf-pce-applicability-actn-11 + draft-ietf-pce-applicability-actn-12 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. @@ -37,21 +37,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 October 8, 2019. + This Internet-Draft will expire on November 17, 2019. Copyright Notice Copyright (c) 2019 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 @@ -75,21 +75,21 @@ 3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9 3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 4. Interface Considerations . . . . . . . . . . . . . . . . . . 10 5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 9.2. Informative References . . . . . . . . . . . . . . . . . 16 + 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Additional Information . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Abstraction and Control of TE Networks (ACTN) [RFC8453] 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 @@ -291,23 +291,23 @@ o Virtual service coordination Section 3 of [RFC8453] describes these functions. It should be noted that this document lists all possible ways in which PCE could be used for each of the above functions, but all functions are not required to be implemented via PCE. Similarly, this document presents the ways in which PCEP could be used as the communications medium between functional components. Operators may choose to use the PCEP for multi-domain coordination via stateful - H-PCE, but alternatively use NETCONF [RFC6241], RESTCONF [RFC8040], - or BGP-LS [RFC7752] to get access to the topology and support - abstraction function. + H-PCE, but alternatively use Network Configuration Protocol (NETCONF) + [RFC6241], RESTCONF [RFC8040], or BGP - Link State (BGP-LS) [RFC7752] + to get access to the topology and support abstraction function. 3.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 [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. @@ -624,22 +624,24 @@ the device (with physical nodes and links) into an abstract path (based on the abstract topology generated before with abstract nodes and links) and report it to the MDSC. 6. IANA Considerations This document makes no requests for IANA action. 7. Security Considerations - Various security considerations for PCEP are described in [RFC5440], - [RFC6952], and [RFC8253]. Further, this document lists various + Various security considerations for PCEP are described in [RFC5440] + and [RFC8253]. Security considerations as stated in Section 10.1, + Section 10.6, and Section 10.7 of [RFC5440] continue to apply on PCEP + when used as ACTN interface. Further, this document lists various extensions of PCEP that are applicable, each of them specify various security considerations which continue to apply here. The ACTN framework described in [RFC8453] defines key components and interfaces for managed traffic engineered networks. It also lists various security considerations such as request and control of resources, confidentially of the information, and availability of function which should be taken into consideration. As per [RFC8453], securing the request and control of resources, @@ -647,25 +649,25 @@ should all be critical security considerations when deploying and operating ACTN platforms. From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components (with PCE being one of them). Furthermore, some ACTN components represent a single point of failure and threat vector and must also manage policy conflicts and eavesdropping of communication between different ACTN components. [RFC8453] further states that all protocols used to realize the ACTN framework should have rich security features, and customer, application and network data should - be stored in encrypted data stores. - - When PCEP is used as an ACTN interface, the security of PCEP provided - by Transport Layer Security (TLS) [RFC8253], as per the - recommendations and best current practices in [RFC7525], is used. + be stored in encrypted data stores. When PCEP is used as an ACTN + interface, the security of PCEP provided by Transport Layer Security + (TLS) [RFC8253], as per the recommendations and best current + practices in [RFC7525] (unless explicitly set aside in [RFC8253]), is + used. As per [RFC8453], regarding the MPI, a PKI- based mechanism is suggested, such as building a TLS or HTTPS connection between the MDSC and PNCs, to ensure trust between the physical network layer control components and the MDSC. Which MDSC the PNC exports topology information to, and the level of detail (full or abstracted), should also be authenticated, and specific access restrictions and topology views should be configurable and/or policy based. When PCEP is used in MPI, the security functions as per [RFC8253] are used to fulfill these requirements. @@ -678,21 +680,29 @@ 8. Acknowledgments The authors would like to thank Jonathan Hardwick for the inspiration behind this document. Further thanks to Avantika for her comments with suggested text. Thanks to Adrian Farrel and Daniel King for their substantial reviews. - Thanks to Yingzhen Qu for RTGDIR reviews. + Thanks to Yingzhen Qu for RTGDIR review. + + Thanks to Rifaat Shekh-Yusef for SECDIR review. + + Thanks to Meral Shirazipour for GENART review. + + Thanks to Roman Danyliw and Barry Leiba for IESG review comments. + + Thanks to Deborah Brungard for being the responsible AD. 9. References 9.1. Normative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . @@ -755,26 +765,20 @@ [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . - [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of - BGP, LDP, PCEP, and MSDP Issues According to the Keying - and Authentication for Routing Protocols (KARP) Design - Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, - . - [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, . [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, . @@ -829,22 +833,22 @@ . [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-06 (work in - progress), October 2018. + Element (PCE).", draft-ietf-pce-stateful-hpce-07 (work in + progress), April 2019. [I-D.ietf-pce-inter-area-as-applicability] King, D. and H. Zheng, "Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as- applicability-07 (work in progress), December 2018. [I-D.dhodylee-pce-pcep-ls] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Distribution of Link-State and TE Information.", draft-