draft-ietf-pce-applicability-actn-11.txt   draft-ietf-pce-applicability-actn-12.txt 
PCE Working Group D. Dhody PCE Working Group D. Dhody
Internet-Draft Y. Lee Internet-Draft Y. Lee
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: October 8, 2019 D. Ceccarelli Expires: November 17, 2019 D. Ceccarelli
Ericsson Ericsson
April 6, 2019 May 16, 2019
Applicability of the Path Computation Element (PCE) to the Abstraction Applicability of the Path Computation Element (PCE) to the Abstraction
and Control of TE Networks (ACTN) and Control of TE Networks (ACTN)
draft-ietf-pce-applicability-actn-11 draft-ietf-pce-applicability-actn-12
Abstract Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network (VN) operations needed to orchestrate, control and virtual network (VN) operations needed to orchestrate, control and
manage large-scale multi-domain TE networks so as to facilitate manage large-scale multi-domain TE networks so as to facilitate
network programmability, automation, efficient resource sharing, and network programmability, automation, efficient resource sharing, and
end-to-end virtual service aware connectivity and network function end-to-end virtual service aware connectivity and network function
virtualization services. virtualization services.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9 3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9
3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
4. Interface Considerations . . . . . . . . . . . . . . . . . . 10 4. Interface Considerations . . . . . . . . . . . . . . . . . . 10
5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Additional Information . . . . . . . . . . . . . . . 21 Appendix A. Additional Information . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Abstraction and Control of TE Networks (ACTN) [RFC8453] refers to the Abstraction and Control of TE Networks (ACTN) [RFC8453] refers to the
set of virtual network (VN) operations needed to orchestrate, control set of virtual network (VN) operations needed to orchestrate, control
and manage large-scale multi-domain TE networks so as to facilitate and manage large-scale multi-domain TE networks so as to facilitate
network programmability, automation, efficient resource sharing, and network programmability, automation, efficient resource sharing, and
end-to-end virtual service aware connectivity and network function end-to-end virtual service aware connectivity and network function
skipping to change at page 7, line 28 skipping to change at page 7, line 28
o Virtual service coordination o Virtual service coordination
Section 3 of [RFC8453] describes these functions. Section 3 of [RFC8453] describes these functions.
It should be noted that this document lists all possible ways in 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 which PCE could be used for each of the above functions, but all
functions are not required to be implemented via PCE. Similarly, functions are not required to be implemented via PCE. Similarly,
this document presents the ways in which PCEP could be used as the this document presents the ways in which PCEP could be used as the
communications medium between functional components. Operators may communications medium between functional components. Operators may
choose to use the PCEP for multi-domain coordination via stateful choose to use the PCEP for multi-domain coordination via stateful
H-PCE, but alternatively use NETCONF [RFC6241], RESTCONF [RFC8040], H-PCE, but alternatively use Network Configuration Protocol (NETCONF)
or BGP-LS [RFC7752] to get access to the topology and support [RFC6241], RESTCONF [RFC8040], or BGP - Link State (BGP-LS) [RFC7752]
abstraction function. to get access to the topology and support abstraction function.
3.1. Multi-Domain Coordination via Hierarchy 3.1. Multi-Domain Coordination via Hierarchy
With the definition of domain being "everything that is under the With the definition of domain being "everything that is under the
control of the single logical controller", as per [RFC8453], it is control of the single logical controller", as per [RFC8453], it is
needed to have a control entity that oversees the specific aspects of needed to have a control entity that oversees the specific aspects of
the different domains and to build a single abstracted end-to-end the different domains and to build a single abstracted end-to-end
network topology in order to coordinate end-to-end path computation network topology in order to coordinate end-to-end path computation
and path/service provisioning. and path/service provisioning.
skipping to change at page 15, line 11 skipping to change at page 15, line 11
the device (with physical nodes and links) into an abstract path the device (with physical nodes and links) into an abstract path
(based on the abstract topology generated before with abstract (based on the abstract topology generated before with abstract
nodes and links) and report it to the MDSC. nodes and links) and report it to the MDSC.
6. IANA Considerations 6. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
7. Security Considerations 7. Security Considerations
Various security considerations for PCEP are described in [RFC5440], Various security considerations for PCEP are described in [RFC5440]
[RFC6952], and [RFC8253]. Further, this document lists various 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 extensions of PCEP that are applicable, each of them specify various
security considerations which continue to apply here. security considerations which continue to apply here.
The ACTN framework described in [RFC8453] defines key components and The ACTN framework described in [RFC8453] defines key components and
interfaces for managed traffic engineered networks. It also lists interfaces for managed traffic engineered networks. It also lists
various security considerations such as request and control of various security considerations such as request and control of
resources, confidentially of the information, and availability of resources, confidentially of the information, and availability of
function which should be taken into consideration. function which should be taken into consideration.
As per [RFC8453], securing the request and control of resources, As per [RFC8453], securing the request and control of resources,
skipping to change at page 15, line 34 skipping to change at page 15, line 36
should all be critical security considerations when deploying and should all be critical security considerations when deploying and
operating ACTN platforms. From a security and reliability operating ACTN platforms. From a security and reliability
perspective, ACTN may encounter many risks such as malicious attack perspective, ACTN may encounter many risks such as malicious attack
and rogue elements attempting to connect to various ACTN components and rogue elements attempting to connect to various ACTN components
(with PCE being one of them). Furthermore, some ACTN components (with PCE being one of them). Furthermore, some ACTN components
represent a single point of failure and threat vector and must also represent a single point of failure and threat vector and must also
manage policy conflicts and eavesdropping of communication between manage policy conflicts and eavesdropping of communication between
different ACTN components. [RFC8453] further states that all different ACTN components. [RFC8453] further states that all
protocols used to realize the ACTN framework should have rich protocols used to realize the ACTN framework should have rich
security features, and customer, application and network data should security features, and customer, application and network data should
be stored in encrypted data stores. be stored in encrypted data stores. When PCEP is used as an ACTN
interface, the security of PCEP provided by Transport Layer Security
When PCEP is used as an ACTN interface, the security of PCEP provided (TLS) [RFC8253], as per the recommendations and best current
by Transport Layer Security (TLS) [RFC8253], as per the practices in [RFC7525] (unless explicitly set aside in [RFC8253]), is
recommendations and best current practices in [RFC7525], is used. used.
As per [RFC8453], regarding the MPI, a PKI- based mechanism is As per [RFC8453], regarding the MPI, a PKI- based mechanism is
suggested, such as building a TLS or HTTPS connection between the suggested, such as building a TLS or HTTPS connection between the
MDSC and PNCs, to ensure trust between the physical network layer MDSC and PNCs, to ensure trust between the physical network layer
control components and the MDSC. Which MDSC the PNC exports topology control components and the MDSC. Which MDSC the PNC exports topology
information to, and the level of detail (full or abstracted), should information to, and the level of detail (full or abstracted), should
also be authenticated, and specific access restrictions and topology also be authenticated, and specific access restrictions and topology
views should be configurable and/or policy based. When PCEP is used views should be configurable and/or policy based. When PCEP is used
in MPI, the security functions as per [RFC8253] are used to fulfill in MPI, the security functions as per [RFC8253] are used to fulfill
these requirements. these requirements.
skipping to change at page 16, line 16 skipping to change at page 16, line 20
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Jonathan Hardwick for the inspiration The authors would like to thank Jonathan Hardwick for the inspiration
behind this document. Further thanks to Avantika for her comments behind this document. Further thanks to Avantika for her comments
with suggested text. with suggested text.
Thanks to Adrian Farrel and Daniel King for their substantial Thanks to Adrian Farrel and Daniel King for their substantial
reviews. 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. References
9.1. Normative References 9.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
skipping to change at page 17, line 48 skipping to change at page 18, line 15
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS "Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
September 2009, <https://www.rfc-editor.org/info/rfc5623>. September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[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,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>. <https://www.rfc-editor.org/info/rfc7149>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<https://www.rfc-editor.org/info/rfc7399>. <https://www.rfc-editor.org/info/rfc7399>.
skipping to change at page 19, line 25 skipping to change at page 19, line 37
<https://www.rfc-editor.org/info/rfc8283>. <https://www.rfc-editor.org/info/rfc8283>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>. September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[I-D.ietf-pce-stateful-hpce] [I-D.ietf-pce-stateful-hpce]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D.,
and O. Dios, "Hierarchical Stateful Path Computation and O. Dios, "Hierarchical Stateful Path Computation
Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in Element (PCE).", draft-ietf-pce-stateful-hpce-07 (work in
progress), October 2018. progress), April 2019.
[I-D.ietf-pce-inter-area-as-applicability] [I-D.ietf-pce-inter-area-as-applicability]
King, D. and H. Zheng, "Applicability of the Path King, D. and H. Zheng, "Applicability of the Path
Computation Element to Inter-Area and Inter-AS MPLS and Computation Element to Inter-Area and Inter-AS MPLS and
GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as- GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as-
applicability-07 (work in progress), December 2018. applicability-07 (work in progress), December 2018.
[I-D.dhodylee-pce-pcep-ls] [I-D.dhodylee-pce-pcep-ls]
Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for
Distribution of Link-State and TE Information.", draft- Distribution of Link-State and TE Information.", draft-
 End of changes. 11 change blocks. 
24 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/