draft-ietf-pce-applicability-actn-05.txt   draft-ietf-pce-applicability-actn-06.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: September 6, 2018 D. Ceccarelli Expires: December 19, 2018 D. Ceccarelli
Ericsson Ericsson
March 5, 2018 June 17, 2018
Applicability of Path Computation Element (PCE) for Abstraction and Applicability of Path Computation Element (PCE) for Abstraction and
Control of TE Networks (ACTN) Control of TE Networks (ACTN)
draft-ietf-pce-applicability-actn-05 draft-ietf-pce-applicability-actn-06
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 45 skipping to change at page 1, line 45
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 September 6, 2018. This Internet-Draft will expire on December 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Path Computation Element (PCE) . . . . . . . . . . . . . 2 1.1. Path Computation Element (PCE) . . . . . . . . . . . . . 2
1.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 3 1.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 3
1.1.2. PCE in multi-domain and multi-layer deployments . . . 4 1.1.2. PCE in multi-domain and multi-layer deployments . . . 4
1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 4 1.1.3. Relationship to PCE based central control . . . . . . 4
1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5
2. Architectural Considerations . . . . . . . . . . . . . . . . 6 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Multi domain coordination via Hierarchy . . . . . . . . . 6 2. Architectural Considerations . . . . . . . . . . . . . . . . 7
2.2. Virtualization/Abstraction function . . . . . . . . . . . 7 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 7
2.3. Customer mapping function . . . . . . . . . . . . . . . . 8 2.2. Abstraction function . . . . . . . . . . . . . . . . . . 8
2.4. Virtual Network Operations . . . . . . . . . . . . . . . 9 2.3. Customer mapping function . . . . . . . . . . . . . . . . 9
3. Interface Considerations . . . . . . . . . . . . . . . . . . 9 2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 10 3. Interface Considerations . . . . . . . . . . . . . . . . . . 10
5. Relationship to PCE based central control . . . . . . . . . . 14 4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
1.1. Path Computation Element (PCE) 1.1. Path Computation Element (PCE)
The Path Computation Element Communication Protocol (PCEP) [RFC5440] The Path Computation Element Communication Protocol (PCEP) [RFC5440]
provides mechanisms for Path Computation Elements (PCEs) [RFC4655] to provides mechanisms for Path Computation Elements (PCEs) [RFC4655] to
perform path computations in response to Path Computation Clients perform path computations in response to Path Computation Clients
(PCCs) requests. (PCCs) requests.
skipping to change at page 3, line 37 skipping to change at page 3, line 37
interactions. [RFC8281] describes the setup, maintenance and interactions. [RFC8281] describes the setup, maintenance and
teardown of PCE-initiated LSPs under the stateful PCE model. teardown of PCE-initiated LSPs under the stateful PCE model.
[RFC8231] also describes the active stateful PCE. The active PCE [RFC8231] also describes the active stateful PCE. The active PCE
functionality allows a PCE to reroute an existing LSP or make changes functionality allows a PCE to reroute an existing LSP or make changes
to the attributes of an existing LSP, or a PCC to delegate control of to the attributes of an existing LSP, or a PCC to delegate control of
specific LSPs to a new PCE. specific LSPs to a new PCE.
1.1.1. Role of PCE in SDN 1.1.1. Role of PCE in SDN
Software-Defined Networking (SDN) refers to a separation between the Software-Defined Networking (SDN) [RFC7149] refers to a separation
control elements and the forwarding components so that software between the control elements and the forwarding components so that
running in a centralized system called a controller, can act to software running in a centralized system called a controller, can act
program the devices in the network to behave in specific ways. A to program the devices in the network to behave in specific ways. A
required element in an SDN architecture is a component that plans how required element in an SDN architecture is a component that plans how
the network resources will be used and how the devices will be the network resources will be used and how the devices will be
programmed. It is possible to view this component as performing programmed. It is possible to view this component as performing
specific computations to place flows within the network given specific computations to place flows within the network given
knowledge of the availability of network resources, how other knowledge of the availability of network resources, how other
forwarding devices are programmed, and the way that other flows are forwarding devices are programmed, and the way that other flows are
routed. It is concluded in [RFC7399], that this is the same function routed. It is concluded in [RFC7399], that this is the same function
that a PCE might offer in a network operated using a dynamic control that a PCE might offer in a network operated using a dynamic control
plane. This is the function and purpose of a PCE, and the way that a plane. This is the function and purpose of a PCE, and the way that a
PCE integrates into a wider network control system including SDN is PCE integrates into a wider network control system including SDN is
skipping to change at page 4, line 41 skipping to change at page 4, line 41
[I-D.ietf-pce-stateful-hpce] state the considerations for stateful [I-D.ietf-pce-stateful-hpce] state the considerations for stateful
PCE(s) in hierarchical PCE architecture. In particular, the behavior PCE(s) in hierarchical PCE architecture. In particular, the behavior
changes and additions to the existing stateful PCE mechanisms changes and additions to the existing stateful PCE mechanisms
(including PCE- initiated LSP setup and active PCE usage) in the (including PCE- initiated LSP setup and active PCE usage) in the
context of networks using the H-PCE architecture. context of networks using the H-PCE architecture.
[RFC5623] describes a framework for applying the PCE-based [RFC5623] describes a framework for applying the PCE-based
architecture to inter-layer to (G)MPLS TE. It provides suggestions architecture to inter-layer to (G)MPLS TE. It provides suggestions
for the deployment of PCE in support of multi-layer networks. It for the deployment of PCE in support of multi-layer networks. It
also describes the relationship between PCE and a functional also describes the relationship between PCE and a functional
component in charge of the control and management of the VNT, called component in charge of the control and management of the Virtual
the Virtual Network Topology Manager (VNTM). Network Topology (VNT) [RFC5212], called the VNT Manager (VNTM).
1.1.3. Relationship to PCE based central control
[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) 1.2. Abstraction and Control of TE Networks (ACTN)
[I-D.ietf-teas-actn-requirements] describes the high-level ACTN [I-D.ietf-teas-actn-requirements] describes the high-level ACTN
requirements. [I-D.ietf-teas-actn-framework] describes the requirements. [I-D.ietf-teas-actn-framework] describes the
architecture model for ACTN including the entities (Customer Network architecture model for ACTN including the entities (Customer Network
Controller(CNC), Multi-domain Service Coordinator(MDSC), and Controller(CNC), Multi-domain Service Coordinator(MDSC), and
Provisioning Network Controller (PNC) and their interfaces. Provisioning Network Controller (PNC) and their interfaces.
The ACTN reference architecture identified a three-tier control The ACTN reference architecture identified a three-tier control
hierarchy as depicted in Figure 1: hierarchy as depicted in Figure 1:
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| CNC | | CNC | | CNC | | CNC | | CNC | | CNC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
\ | / \ | /
Business \ | / \ | /
Boundary =============\==============|==============/============ Boundary =============\==============|==============/============
Between \ | / Between \ | /
Customer & ------- | CMI ------- Customer & ------- | CMI -------
Network Provider \ | / Network Operator \ | /
+---------------+ +---------------+
| MDSC | | MDSC |
+---------------+ +---------------+
/ | \ / | \
------------ | MPI ------------- ------------ | MPI -------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| SBI / | / \ | SBI / | / \
skipping to change at page 6, line 13 skipping to change at page 7, line 13
ACTN interfaces. ACTN interfaces.
1.3. PCE and ACTN 1.3. PCE and ACTN
This document examines the PCE and ACTN architecture and describes This document examines the PCE and ACTN architecture and describes
how the PCE architecture is applicable to ACTN. It also lists the how the PCE architecture is applicable to ACTN. It also lists the
PCEP extensions that are needed to use PCEP as an ACTN interface. PCEP extensions that are needed to use PCEP as an ACTN interface.
This document also identifies any gaps in PCEP, that exist at the This document also identifies any gaps in PCEP, that exist at the
time of publication of this document. 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 2. Architectural Considerations
ACTN [I-D.ietf-teas-actn-framework] architecture is based on ACTN [I-D.ietf-teas-actn-framework] architecture is based on
hierarchy and recursiveness of controllers. It defines three types hierarchy and recursiveness of controllers. It defines three types
of controllers (depending on the functionalities they implement). of controllers (depending on the functionalities they implement).
The main functionalities are - The main functionalities are -
o Multi domain coordination function o Multi domain coordination function
o Virtualization/Abstraction function o Abstraction function
o Customer mapping/translation function o Customer mapping/translation function
o Virtual service coordination function o Virtual service coordination function
Section 3 of [I-D.ietf-teas-actn-framework] describes these Section 3 of [I-D.ietf-teas-actn-framework] describes these
functions. 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 PCEP could be used for each of the above functions, but all which PCEP could be used for each of the above functions, but all
functions are not required to be implemented via PCEP. Operator may functions are not required to be implemented via PCEP. Operator 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 use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get the H-PCE but use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get the
topology and support virtualization/abstraction function. topology and support abstraction function.
2.1. Multi domain coordination via Hierarchy 2.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 control of the single logical controller", as per
[I-D.ietf-teas-actn-framework], it is needed to have a control entity [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 that oversees the specific aspects of the different domains and to
build a single abstracted end-to-end network topology in order to build a single abstracted end-to-end network topology in order to
coordinate end-to-end path computation and path/service provisioning. coordinate end-to-end path computation and path/service provisioning.
skipping to change at page 7, line 24 skipping to change at page 8, line 26
coordination function. This includes domain sequence selection; E2E coordination function. This includes domain sequence selection; E2E
path computation; Controller (PCE) initiated path setup and path computation; Controller (PCE) initiated path setup and
reporting. This is also applicable to multi-layer coordination in reporting. This is also applicable to multi-layer coordination in
case of IP+optical networks. case of IP+optical networks.
[I-D.litkowski-pce-state-sync]" describes the procedures to allow a [I-D.litkowski-pce-state-sync]" describes the procedures to allow a
stateful communication between PCEs for various use-cases. The stateful communication between PCEs for various use-cases. The
procedures and extensions are also applicable to Child and Parent PCE procedures and extensions are also applicable to Child and Parent PCE
communication and thus useful for ACTN as well. communication and thus useful for ACTN as well.
2.2. Virtualization/Abstraction function 2.2. Abstraction function
To realize ACTN, an abstracted view of the underlying network To realize ACTN, an abstracted view of the underlying network
resources needs to be built. This includes global network-wide resources needs to be built. This includes global network-wide
abstracted topology based on the underlying network resources of each abstracted topology based on the underlying network resources of each
domain. This also include abstract topology created as per the domain. This also include abstract topology created as per the
customer service connectivity requests and represented as a network customer service connectivity requests and represented as a network
slice allocated to each customer. slice allocated to each customer.
In order to compute and provide optimal paths, PCEs require an In order to compute and provide optimal paths, PCEs require an
accurate and timely Traffic Engineering Database (TED). accurate and timely Traffic Engineering Database (TED).
skipping to change at page 8, line 9 skipping to change at page 9, line 11
[I-D.dhodylee-pce-pcep-ls] proposes another approaches for learning [I-D.dhodylee-pce-pcep-ls] proposes another approaches for learning
and maintaining the Link-State and TE information as an alternative and maintaining the Link-State and TE information as an alternative
to IGPs and BGP flooding, using PCEP itself. The child PCE can use to IGPs and BGP flooding, using PCEP itself. The child PCE can use
this mechanism to transport Link-State and TE information from child this mechanism to transport Link-State and TE information from child
PCE to a Parent PCE using PCEP. PCE to a Parent PCE using PCEP.
In ACTN, there is a need to control the level of abstraction based on In ACTN, there is a need to control the level of abstraction based on
the deployment scenario and business relationship between the the deployment scenario and business relationship between the
controllers. The mechanism used to disseminate information from PNC controllers. The mechanism used to disseminate information from PNC
(child PCE) to MDSC (parent PCE) should support abstraction. (child PCE) to MDSC (parent PCE) should support abstraction.
[I-D.lee-teas-actn-abstraction] describes a few alternative [I-D.ietf-teas-actn-framework] describes a few alternative approaches
approaches of abstraction. The resulting abstracted topology can be of abstraction. The resulting abstracted topology can be encoded
encoded using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls] and using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls] and its
its optical network extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS optical network extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is
is an attractive option when the operator would wish to have a single an attractive option when the operator would wish to have a single
control plane protocol (PCEP) to achieve ACTN functions. control plane protocol (PCEP) to achieve ACTN functions.
[I-D.ietf-teas-actn-framework] discusses two ways to build abstract [I-D.ietf-teas-actn-framework] discusses two ways to build abstract
topology from an MDSC standpoint with interaction with PNCs. The topology from an MDSC standpoint with interaction with PNCs. The
primary method is called authomatic generation of abstract topology primary method is called automatic generation of abstract topology by
by configuration. with this method, automatic generation is based on configuration. With this method, automatic generation is based on
the abstraction/summarization of the whole domain by the PNC and its the abstraction/summarization of the whole domain by the PNC and its
advertisement on the MPI. The seconday method is called on-demand advertisement on the MPI. The secondary method is called on-demand
generation of supplementary topology via Path Compute Request/Reply. generation of supplementary topology via Path Compute Request/Reply.
This method may be needed to obtain further complementary information This method may be needed to obtain further complementary information
such as potential connectivity from child PCEs in order to facilitate such as potential connectivity from child PCEs in order to facilitate
an end-to-end path provisioning. PCEP is well suited to support both an end-to-end path provisioning. PCEP is well suited to support both
methods. methods.
2.3. Customer mapping function 2.3. Customer mapping function
In ACTN, there is a need to map customer virtual network (VN) In ACTN, there is a need to map customer virtual network (VN)
requirements into network provisioning request to the PNC. That is, requirements into network provisioning request to the PNC. That is,
skipping to change at page 9, line 10 skipping to change at page 10, line 12
child PCE further propagates the initiate request to the LSR. The child PCE further propagates the initiate request to the LSR. The
customer request is received by the MDSC (parent PCE) and based on customer request is received by the MDSC (parent PCE) and based on
the business logic, global abstracted topology, network conditions the business logic, global abstracted topology, network conditions
and local policy, the MDSC (parent PCE) translates this into per and local policy, the MDSC (parent PCE) translates this into per
domain LSP initiation request that a PNC (child PCE) can understand domain LSP initiation request that a PNC (child PCE) can understand
and act on. This can be done via the PCInitiate message. and act on. This can be done via the PCInitiate message.
PCEP extensions for associating opaque policy between PCEP peer PCEP extensions for associating opaque policy between PCEP peer
[I-D.ietf-pce-association-policy] can be used. [I-D.ietf-pce-association-policy] can be used.
2.4. Virtual Network Operations 2.4. Virtual Service Coordination
Virtual service coordination function in ACTN incorporates customer Virtual service coordination function in ACTN incorporates customer
service-related information into the virtual network service service-related information into the virtual network service
operations in order to seamlessly operate virtual networks while operations in order to seamlessly operate virtual networks while
meeting customer's service requirements. meeting customer's service requirements.
[I-D.leedhody-pce-vn-association] describes the need for associating [I-D.leedhody-pce-vn-association] describes the need for associating
a set of LSPs with a VN "construct" to facilitate VN operations in a set of LSPs with a VN "construct" to facilitate VN operations in
PCE architecture. This association allows the PCEs to identify which PCE architecture. This association allows the PCEs to identify which
LSPs belong to a certain VN. LSPs belong to a certain VN.
skipping to change at page 9, line 39 skipping to change at page 10, line 41
considered for all the LSPs belonging to a VN/customer and optimize considered for all the LSPs belonging to a VN/customer and optimize
them all together. them all together.
3. Interface Considerations 3. Interface Considerations
As per [I-D.ietf-teas-actn-framework], to allow virtualization and As per [I-D.ietf-teas-actn-framework], to allow virtualization and
multi domain coordination, the network has to provide open, multi domain coordination, the network has to provide open,
programmable interfaces, in which customer applications can create, programmable interfaces, in which customer applications can create,
replace and modify virtual network resources and services in an replace and modify virtual network resources and services in an
interactive, flexible and dynamic fashion while having no impact on interactive, flexible and dynamic fashion while having no impact on
other customers. The 3 ACTN interfaces are - other customers. The two ACTN interfaces are -
o The CNC-MDSC Interface (CMI) is an interface between a Customer o The CNC-MDSC Interface (CMI) is an interface between a Customer
Network Controller and a Multi Domain Service Coordinator. It Network Controller and a Multi Domain Service Coordinator. It
requests the creation of the network resources, topology or requests the creation of the network resources, topology or
services for the applications. The MDSC may also report potential services for the applications. The MDSC may also report potential
network topology availability if queried for current capability network topology availability if queried for current capability
from the Customer Network Controller. from the Customer Network Controller.
o The MDSC-PNC Interface (MPI) is an interface between a Multi o The MDSC-PNC Interface (MPI) is an interface between a Multi
Domain Service Coordinator and a Provisioning Network Controller. Domain Service Coordinator and a Provisioning Network Controller.
skipping to change at page 12, line 21 skipping to change at page 13, line 21
o VN Instantiate: MDSC is requested to instantiate a VN, the minimal o VN Instantiate: MDSC is requested to instantiate a VN, the minimal
information that is required would be a VN identifier and a set of information that is required would be a VN identifier and a set of
end points. Various path computation, setup constraints and end points. Various path computation, setup constraints and
objective functions may also be provided. In PCE terms, a VN objective functions may also be provided. In PCE terms, a VN
Instantiate can be considered as a set of paths belonging to the Instantiate can be considered as a set of paths belonging to the
same VN. As described in Section 2.4 and same VN. As described in Section 2.4 and
[I-D.leedhody-pce-vn-association] the VN association can help in [I-D.leedhody-pce-vn-association] the VN association can help in
identifying the set of paths that belong to a VN. The rest of the identifying the set of paths that belong to a VN. The rest of the
information like the endpoints, constraints and objective function information like the endpoints, constraints and objective function
is already defined in PCEP in terms of a single path. (OF) is already defined in PCEP in terms of a single path.
* Path Computation: As per the example in the Figure 2, the VN * Path Computation: As per the example in the Figure 2, the VN
instantiate requires two end to end paths between (A in Domain instantiate requires two end to end paths between (A in Domain
1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The
MDSC (or parent PCE) triggers the end to end path computation MDSC (or parent PCE) triggers the end to end path computation
for these two paths. MDSC can do path computation based on the for these two paths. MDSC can do path computation based on the
abstracted domain topology that it already has or it may use abstracted domain topology that it already has or it may use
the H-PCE procedures (Section 2.1) using the PCReq and PCRep the H-PCE procedures (Section 2.1) using the PCReq and PCRep
messages to get the end to end path with the help of the child messages to get the end to end path with the help of the child
PCEs (PNC). Either way, the resulted E2E paths may be broken PCEs (PNC). Either way, the resulted E2E paths may be broken
skipping to change at page 14, line 5 skipping to change at page 15, line 5
o In case PNC generates an abstract topology to the MDSC, the o In case PNC generates an abstract topology to the MDSC, the
PCInitiate/PCUpd messages from the MDSC to a PNC will contain a PCInitiate/PCUpd messages from the MDSC to a PNC will contain a
path with abstract nodes and links. PNC would need to take that path with abstract nodes and links. PNC would need to take that
as an input for path computation to get a path with physical nodes as an input for path computation to get a path with physical nodes
and links. Similarly PNC would convert the path received from the and links. Similarly PNC would convert the path received from the
device (with physical nodes and links) into abstract path (based device (with physical nodes and links) into abstract path (based
on the abstract topology generated before with abstract nodes and on the abstract topology generated before with abstract nodes and
links) and reported to the MDSC. links) and reported to the MDSC.
5. Relationship to PCE based central control 5. IANA Considerations
[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]. Both ACTN and PCECC is based on the same basic
framework and thus compatible with each other.
6. IANA Considerations
This is an informational document and thus does not have any IANA This is an informational document and thus does not have any IANA
allocations to be made. allocations to be made.
7. Security Considerations 6. Security Considerations
The ACTN framework described in [I-D.ietf-teas-actn-framework] The ACTN framework described in [I-D.ietf-teas-actn-framework]
defines key components and interfaces for managed traffic engineered defines key components and interfaces for managed traffic engineered
networks. It also list various security considerations such as networks. It also list various security considerations such as
request and control of resources, confidentially of the information, request and control of resources, confidentially of the information,
and availability of function which should be taken into and availability of function which should be taken into
consideration. consideration.
When PCEP is used on the MPI, this interface needs to be secured, use When PCEP is used on the MPI, this interface needs to be secured, use
of [RFC8253] is RECOMENDED. Each PCEP extension listed in this of [RFC8253] is RECOMENDED. Each PCEP extension listed in this
document, presents its individual security considerations, which document, presents its individual security considerations, which
continue to apply. continue to apply.
8. Acknowledgments 7. 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.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
9.2. Informative References [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,
<https://www.rfc-editor.org/info/rfc6805>.
[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.
8.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>. <https://www.rfc-editor.org/info/rfc4203>.
skipping to change at page 15, line 28 skipping to change at page 16, line 28
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>.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing Inter- Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<https://www.rfc-editor.org/info/rfc5152>. <https://www.rfc-editor.org/info/rfc5152>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
DOI 10.17487/RFC5212, July 2008,
<https://www.rfc-editor.org/info/rfc5212>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>. <https://www.rfc-editor.org/info/rfc5307>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
skipping to change at page 16, line 5 skipping to change at page 17, line 10
Procedure to Compute Shortest Constrained Inter-Domain Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441, Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009, DOI 10.17487/RFC5441, April 2009,
<https://www.rfc-editor.org/info/rfc5441>. <https://www.rfc-editor.org/info/rfc5441>.
[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>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Path Computation Element Architecture to the Determination Networking: A Perspective from within a Service Provider
of a Sequence of Domains in MPLS and GMPLS", RFC 6805, Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc7149>.
<https://www.rfc-editor.org/info/rfc6805>.
[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>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015, DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>. <https://www.rfc-editor.org/info/rfc7491>.
skipping to change at page 17, line 23 skipping to change at page 18, line 29
and O. Dios, "Hierarchical Stateful Path Computation and O. Dios, "Hierarchical Stateful Path Computation
Element (PCE).", draft-ietf-pce-stateful-hpce-04 (work in Element (PCE).", draft-ietf-pce-stateful-hpce-04 (work in
progress), March 2018. progress), March 2018.
[I-D.ietf-teas-actn-requirements] [I-D.ietf-teas-actn-requirements]
Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K. Lee, Y., Ceccarelli, D., Miyasaka, T., Shin, J., and K.
Lee, "Requirements for Abstraction and Control of TE Lee, "Requirements for Abstraction and Control of TE
Networks", draft-ietf-teas-actn-requirements-09 (work in Networks", draft-ietf-teas-actn-requirements-09 (work in
progress), March 2018. progress), March 2018.
[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-11 (work in progress), October 2017.
[I-D.ietf-teas-actn-info-model] [I-D.ietf-teas-actn-info-model]
Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. 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)", draft-ietf-teas-actn-info-model-07 (work Networks (ACTN)", draft-ietf-teas-actn-info-model-09 (work
in progress), February 2018. in progress), June 2018.
[I-D.ietf-pce-inter-area-as-applicability] [I-D.ietf-pce-inter-area-as-applicability]
King, D., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and King, D., Meuric, J., Dugeon, O., Zhao, Q., Dhody, D., and
O. Dios, "Applicability of the Path Computation Element to O. Dios, "Applicability of the Path Computation Element to
Inter-Area and Inter-AS MPLS and GMPLS Traffic Inter-Area and Inter-AS MPLS and GMPLS Traffic
Engineering", draft-ietf-pce-inter-area-as- Engineering", draft-ietf-pce-inter-area-as-
applicability-06 (work in progress), July 2016. applicability-06 (work in progress), July 2016.
[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
skipping to change at page 18, line 14 skipping to change at page 19, line 14
[I-D.leedhody-pce-vn-association] [I-D.leedhody-pce-vn-association]
Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP Lee, Y., Dhody, D., Zhang, X., and D. Ceccarelli, "PCEP
Extensions for Establishing Relationships Between Sets of Extensions for Establishing Relationships Between Sets of
LSPs and Virtual Networks", draft-leedhody-pce-vn- LSPs and Virtual Networks", draft-leedhody-pce-vn-
association-04 (work in progress), February 2018. association-04 (work in progress), February 2018.
[I-D.litkowski-pce-state-sync] [I-D.litkowski-pce-state-sync]
Litkowski, S., Sivabalan, S., and D. Dhody, "Inter Litkowski, S., Sivabalan, S., and D. Dhody, "Inter
Stateful Path Computation Element communication Stateful Path Computation Element communication
procedures", draft-litkowski-pce-state-sync-02 (work in procedures", draft-litkowski-pce-state-sync-03 (work in
progress), August 2017. progress), April 2018.
[I-D.ietf-pce-association-policy] [I-D.ietf-pce-association-policy]
Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and Dhody, D., Sivabalan, S., Litkowski, S., Tantsura, J., and
J. Hardwick, "Path Computation Element communication J. Hardwick, "Path Computation Element communication
Protocol extension for associating Policies and LSPs", Protocol extension for associating Policies and LSPs",
draft-ietf-pce-association-policy-02 (work in progress), draft-ietf-pce-association-policy-02 (work in progress),
February 2018. February 2018.
[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-02 (work in
progress), June 2017.
[I-D.lee-pce-lsp-stitching-hpce] [I-D.lee-pce-lsp-stitching-hpce]
Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions
for Stitching LSPs in Hierarchical Stateful PCE Model", for Stitching LSPs in Hierarchical Stateful PCE Model",
draft-lee-pce-lsp-stitching-hpce-01 (work in progress), draft-lee-pce-lsp-stitching-hpce-01 (work in progress),
December 2017. December 2017.
Authors' Addresses Authors' Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
 End of changes. 31 change blocks. 
79 lines changed or deleted 86 lines changed or added

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