draft-ietf-pce-applicability-actn-03.txt   draft-ietf-pce-applicability-actn-04.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 2, 2018 D. Ceccarelli Expires: September 6, 2018 D. Ceccarelli
Ericsson Ericsson
March 1, 2018 March 5, 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-03 draft-ietf-pce-applicability-actn-04
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 operations needed to orchestrate, control and manage virtual network (VN) operations needed to orchestrate, control and
large-scale multi-domain TE networks so as to facilitate network manage large-scale multi-domain TE networks so as to facilitate
programmability, automation, efficient resource sharing, and end-to- network programmability, automation, efficient resource sharing, and
end virtual service aware connectivity and network function end-to-end virtual service aware connectivity and network function
virtualization services. virtualization services.
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
This document examines the applicability of PCE to the ACTN This document examines the applicability of PCE to the ACTN
framework. framework.
Status of This Memo Status of This Memo
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 2, 2018. This Internet-Draft will expire on September 6, 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 48 skipping to change at page 2, line 48
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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.
The ability to compute shortest constrained TE LSPs in Multiprotocol The ability to compute shortest constrained TE LSPs in Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across
multiple domains has been identified as a key motivation for PCE multiple domains has been identified as a key motivation for PCE
development. development.
A stateful PCE [RFC8231] is capable of considering, for the purposes A stateful PCE [RFC8231] is capable of considering, for the purposes
of path computation, not only the network state in terms of links and of path computation, not only the network state in terms of links and
nodes (referred to as the Traffic Engineering Database or TED) but nodes (referred to as the Traffic Engineering Database or TED) but
also the status of active services (previously computed paths, and also the status of active services (previously computed paths, and
currently reserved resources, stored in the Label Switched Paths currently reserved resources, stored in the Label Switched Paths
Database (LSPDB). Database (LSP-DB).
[RFC8051] describes general considerations for a stateful PCE [RFC8051] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as deployment and examines its applicability and benefits, as well as
its challenges and limitations through a number of use cases. its challenges and limitations through a number of use cases.
[RFC8231] describes a set of extensions to PCEP to provide stateful [RFC8231] describes a set of extensions to PCEP to provide stateful
control. A stateful PCE has access to not only the information control. A stateful PCE has access to not only the information
carried by the network's Interior Gateway Protocol (IGP), but also carried by the network's Interior Gateway Protocol (IGP), but also
the set of active paths and their reserved resources for its the set of active paths and their reserved resources for its
computations. The additional state allows the PCE to compute computations. The additional state allows the PCE to compute
skipping to change at page 4, line 49 skipping to change at page 4, line 49
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 VNT, called
the Virtual Network Topology Manager (VNTM). the Virtual Network Topology Manager (VNTM).
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), Mult-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 \ | / Business \ | /
Boundary =============\==============|==============/============ Boundary =============\==============|==============/============
Between \ | / Between \ | /
Customer & ------- | CMI ------- Customer & ------- | CMI -------
Network Provider \ | / Network Provider \ | /
+---------------+ +---------------+
| MDSC | | MDSC |
+---------------+ +---------------+
/ | \ / | \
------------ | MPI ------------- ------------ | MPI -------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| SBI / | / \ | SBI / | / \
| / | SBI / \ | / | SBI / \
--------- ----- | / \ --------- ----- | / \
( ) ( ) | / \ ( ) ( ) | / \
- Control - ( Phys. ) | / ----- - Control - ( Phys. ) | / -----
( Plane ) ( Net ) | / ( ) ( Plane ) ( Net ) | / ( )
( Physical ) ----- | / ( Phys. ) ( Physical ) ----- | / ( Phys. )
( Network ) ----- ----- ( Net ) ( Network ) ----- ----- ( Net )
- - ( ) ( ) ----- - - ( ) ( ) -----
( ) ( Phys. ) ( Phys. ) ( ) ( Phys. ) ( Phys. )
--------- ( Net ) ( Net ) --------- ( Net ) ( Net )
----- ----- ----- -----
CMI - (CNC-MDSC Interface) CMI - (CNC-MDSC Interface)
MPI - (MDSC-PNC Interface) MPI - (MDSC-PNC Interface)
Figure 1: ACTN Hierarchy Figure 1: ACTN Hierarchy
The two interfaces with respect to the MDSC, one north of the MDSC The two interfaces with respect to the MDSC, one north of the MDSC
Interface) and MPI (MDSC-PNC Interface), respectively. A hierarchy (CMI CNC-MDSC Interface) and one south (MPI MDSC-PNC Interface). A
of MDSC is possible with a recursive MPI interface. hierarchy of MDSC is possible with a recursive MPI interface.
[I-D.ietf-teas-actn-info-model] provides an information model for [I-D.ietf-teas-actn-info-model] provides an information model for
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
skipping to change at page 6, line 31 skipping to change at page 6, line 31
o Virtualization/Abstraction function o Virtualization/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, in this document we list all possible ways It should be noted that, this document lists all possible ways in
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 or BGP-LS to get the topology and support H-PCE but use RESTCONF [RFC8040] or BGP-LS [RFC7752] to get the
virtualization/abstraction function. topology and support virtualization/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 9, line 37 skipping to change at page 9, line 37
other customers. The 3 ACTN interfaces are - other customers. The 3 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 Physical Network Controller. It Domain Service Coordinator and a Provisioning Network Controller.
communicates the creation request, if required, of new It communicates the creation request, if required, of new
connectivity of bandwidth changes in the physical network, via the connectivity of bandwidth changes in the physical network, via the
PNC. In multi-domain environments, the MDSC needs to establish PNC. In multi-domain environments, the MDSC needs to establish
multiple MPIs, one for each PNC, as there are multiple PNCs multiple MPIs, one for each PNC, as there are multiple PNCs
responsible for its domain control. responsible for its domain control.
o Incase of hierarchy of MDSC, the MPI is applied recursively. From o In case of hierarchy of MDSC, the MPI is applied recursively.
an abstraction point of view, the top level MDSC which interfaces From an abstraction point of view, the top level MDSC which
the CNC operates on a higher level of abstraction (i.e., less interfaces the CNC operates on a higher level of abstraction
granular level) than the lower level MSDCs. (i.e., less granular level) than the lower level MSDCs.
PCEP is especially suitable on the MPI as it meets the requirement PCEP is especially suitable on the MPI as it meets the requirement
and the functions as set out in the ACTN framework and the functions as set out in the ACTN framework
[I-D.ietf-teas-actn-framework]. Its recursive nature is well suited [I-D.ietf-teas-actn-framework]. Its recursive nature is well suited
via the multi-level hierarchy of PCE. The Section 4 describe how PCE via the multi-level hierarchy of PCE. The Section 4 describe how PCE
and PCEP could help realize ACTN. and PCEP could help realize ACTN.
4. Realizining ACTN with PCE (and PCEP) 4. Realizining ACTN with PCE (and PCEP)
As per the example in the Figure 2, there are 4 domains, each with As per the example in the Figure 2, there are 4 domains, each with
skipping to change at page 11, line 40 skipping to change at page 11, line 40
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. 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 PNC. messages to get the end to end path with the help of the child
Either way, the resulted E2E paths may be broken into per- PCEs (PNC). Either way, the resulted E2E paths may be broken
domain paths. into per-domain paths.
* A-B: (A-B13,B13-B31,B31-B) * A-B: (A-B13,B13-B31,B31-B)
* A-C: (A-B13,B13-B31,B34-B43,B43-C) * A-C: (A-B13,B13-B31,B34-B43,B43-C)
* Per Domain Path Instantiation: Based on the above path * Per Domain Path Instantiation: Based on the above path
computation, MDSC can issue the path instantiation request to computation, MDSC can issue the path instantiation request to
each PNC via PCInitiate message (see each PNC via PCInitiate message (see
[I-D.ietf-pce-stateful-hpce] and [I-D.ietf-pce-stateful-hpce] and
skipping to change at page 12, line 30 skipping to change at page 12, line 30
* State Synchronization: The state needs to be synchronized * State Synchronization: The state needs to be synchronized
between the parent PCE and child PCE. The mechanism described between the parent PCE and child PCE. The mechanism described
in [I-D.litkowski-pce-state-sync] can be used. in [I-D.litkowski-pce-state-sync] can be used.
o VN Modify: MDSC is requested to modify a VN, for example the o VN Modify: MDSC is requested to modify a VN, for example the
bandwidth for VN is increased. This may trigger path computation bandwidth for VN is increased. This may trigger path computation
at MDSC as described in the previous step and can trigger an at MDSC as described in the previous step and can trigger an
update to existing per-intra-domain path (via PCUpd message) or update to existing per-intra-domain path (via PCUpd message) or
creation (or deletion) of a per-domain path (via PCInitiate creation (or deletion) of a per-domain path (via PCInitiate
message). This should be done in make-before-break fashion. message). As described in [I-D.ietf-pce-stateful-hpce], this
should be done in make-before-break fashion.
o VN Delete: MDSC is requested to delete a VN, in this case, based 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 on the E2E paths and the resulting per-domain paths need to be
removed (via PCInitiate message). removed (via PCInitiate message).
o VN Update (based on network changes): Any change in the per-domain o VN Update (based on network changes): Any change in the per-domain
LSP are reported to the MDSC (via PCRpt message) as per LSP are reported to the MDSC (via PCRpt message) as per
[I-D.ietf-pce-stateful-hpce]. This may result in changes in the [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 E2E path or VN status. This may also trigger a re-optimization
leading to a new per-domain path, update to existing path, or leading to a new per-domain path, update to existing path, or
skipping to change at page 13, line 12 skipping to change at page 13, line 13
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. Relationship to PCE based central control
[I-D.ietf-teas-pce-central-control] introduces the architecture for [RFC8283] introduces the architecture for PCE as a central controller
PCE as a central controller (PCECC), it further examines the (PCECC), it further examines the motivations and applicability for
motivations and applicability for PCEP as a southbound interface, and PCEP as a southbound interface, and introduces the implications for
introduces the implications for the protocol. The section 2.1.3 of the protocol. The section 2.1.3 of [RFC8283] describe an hierarchy
[I-D.ietf-teas-pce-central-control] describe an hierarchy of PCE- of PCE-based controller as per the Hierarchy of PCE framework defined
based controller as per the Hierarchy of PCE framework defined in in [RFC6805]. Both ACTN and PCECC is based on the same basic
[RFC6805]. Both ACTN and PCECC is based on the same basic framework framework and thus compatible with each other.
and thus compatible with each other.
6. IANA Considerations 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 7. 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
skipping to change at page 15, line 32 skipping to change at page 15, line 32
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>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051, Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017, DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>. <https://www.rfc-editor.org/info/rfc8051>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
skipping to change at page 16, line 11 skipping to change at page 16, line 11
Path Computation Element Communication Protocol (PCEP)", Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017, RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>. <https://www.rfc-editor.org/info/rfc8253>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[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,
<https://www.rfc-editor.org/info/rfc8283>.
[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-02 (work in Element (PCE).", draft-ietf-pce-stateful-hpce-04 (work in
progress), October 2017. progress), March 2018.
[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-05
(work in progress), September 2017.
[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-08 (work in Networks", draft-ietf-teas-actn-requirements-09 (work in
progress), January 2018. progress), March 2018.
[I-D.ietf-teas-actn-framework] [I-D.ietf-teas-actn-framework]
Ceccarelli, D. and Y. Lee, "Framework for Abstraction and Ceccarelli, D. and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas- Control of Traffic Engineered Networks", draft-ietf-teas-
actn-framework-11 (work in progress), October 2017. 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-07 (work
skipping to change at page 16, line 50 skipping to change at page 16, line 50
[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
Distribution of Link-State and TE Information.", draft- Distribution of Link-State and TE Information.", draft-
dhodylee-pce-pcep-ls-09 (work in progress), January 2018. dhodylee-pce-pcep-ls-10 (work in progress), March 2018.
[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
 End of changes. 23 change blocks. 
78 lines changed or deleted 82 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/