draft-ietf-pce-applicability-actn-00.txt   draft-ietf-pce-applicability-actn-01.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: December 3, 2017 D. Ceccarelli Expires: December 31, 2017 D. Ceccarelli
Ericsson Ericsson
June 1, 2017 June 29, 2017
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-00 draft-ietf-pce-applicability-actn-01
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 operations needed to orchestrate, control and manage
large-scale multi-domain TE networks so as to facilitate network large-scale multi-domain TE networks so as to facilitate network
programmability, automation, efficient resource sharing, and end-to- programmability, automation, efficient resource sharing, and end-to-
end virtual service aware connectivity and network function 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 3, 2017. This Internet-Draft will expire on December 31, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 35 skipping to change at page 2, line 35
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.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 4
1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 5 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 5
2. Architectural Considerations . . . . . . . . . . . . . . . . 6 2. Architectural Considerations . . . . . . . . . . . . . . . . 6
2.1. Multi domain coordination via Hierarchy . . . . . . . . . 6 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 6
2.2. Virtualization/Abstraction function . . . . . . . . . . . 7 2.2. Virtualization/Abstraction function . . . . . . . . . . . 7
2.3. Customer mapping function . . . . . . . . . . . . . . . . 8 2.3. Customer mapping function . . . . . . . . . . . . . . . . 8
2.4. Virtual Network Operations . . . . . . . . . . . . . . . 8 2.4. Virtual Network Operations . . . . . . . . . . . . . . . 8
3. Interface Considerations . . . . . . . . . . . . . . . . . . 9 3. Interface Considerations . . . . . . . . . . . . . . . . . . 9
4. Realizining ACTN with PCE (and PCEP) . . . . . . . . . . . . 9 4. Realizining ACTN with PCE (and PCEP) . . . . . . . . . . . . 9
5. Relationship to PCE based central control . . . . . . . . . . 12 5. Relationship to PCE based central control . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 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.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
[RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can
be used for computing end-to-end paths for inter-domain MPLS Traffic be used for computing end-to-end paths for inter-domain MPLS Traffic
Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the
domain sequence is not known. Within the Hierarchical PCE (H-PCE) domain sequence is not known. Within the Hierarchical PCE (H-PCE)
architecture, the Parent PCE (P-PCE) is used to compute a multi- architecture, the Parent PCE (P-PCE) is used to compute a multi-
domain path based on the domain connectivity information. A Child domain path based on the domain connectivity information. A Child
PCE (C-PCE) may be responsible for a single domain or multiple PCE (C-PCE) may be responsible for a single domain or multiple
domains, it is used to compute the intra-domain path based on its domains, it is used to compute the intra-domain path based on its
domain topology information. domain topology information.
[I-D.dhodylee-pce-stateful-hpce] state the considerations for [I-D.ietf-pce-stateful-hpce] state the considerations for stateful
stateful PCE(s) in hierarchical PCE architecture. In particular, the PCE(s) in hierarchical PCE architecture. In particular, the behavior
behavior changes and additions to the existing stateful PCE changes and additions to the existing stateful PCE mechanisms
mechanisms (including PCE- initiated LSP setup and active PCE usage) (including PCE- initiated LSP setup and active PCE usage) in the
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 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)
skipping to change at page 6, line 44 skipping to change at page 6, line 44
[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.
The MDSC in ACTN framework realizes this function by coordinating the The MDSC in ACTN framework realizes this function by coordinating the
per-domain PNCs in a hierarchy of controllers. It also needs to per-domain PNCs in a hierarchy of controllers. It also needs to
detach from the underlying network technology and express customer detach from the underlying network technology and express customer
concerns by business needs. concerns by business needs.
[RFC6805] and [I-D.dhodylee-pce-stateful-hpce] describes a hierarchy [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy of
of PCE with Parent PCE coordinating multi-domain path computation PCE with Parent PCE coordinating multi-domain path computation
function between Child PCE(s). It is easy to see how these function between Child PCE(s). It is easy to see how these
principles align, and thus how stateful H-PCE architecture can be principles align, and thus how stateful H-PCE architecture can be
used to realize ACTN. used to realize ACTN.
The Per domain stitched LSP in the Hierarchical stateful PCE The Per domain stitched LSP in the Hierarchical stateful PCE
architecture, described in Section 3.3.1 of architecture, described in Section 3.3.1 of
[I-D.dhodylee-pce-stateful-hpce] is well suited for multi-domain [I-D.ietf-pce-stateful-hpce] is well suited for multi-domain
coordination function. This includes domain sequence selection; E2E 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.
skipping to change at page 8, line 21 skipping to change at page 8, line 21
mapping and translation of a customer's service request into a set of mapping and translation of a customer's service request into a set of
parameters that are specific to a network type and technology such parameters that are specific to a network type and technology such
that network configuration process is made possible. that network configuration process is made possible.
[I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and
teardown of PCE-initiated LSPs under the stateful PCE model, without teardown of PCE-initiated LSPs under the stateful PCE model, without
the need for local configuration on the PCC, thus allowing for a the need for local configuration on the PCC, thus allowing for a
dynamic network that is centrally controlled and deployed. To dynamic network that is centrally controlled and deployed. To
instantiate or delete an LSP, the PCE sends the Path Computation LSP instantiate or delete an LSP, the PCE sends the Path Computation LSP
Initiate Request (PCInitiate) message to the PCC. As described in Initiate Request (PCInitiate) message to the PCC. As described in
[I-D.dhodylee-pce-stateful-hpce], for inter-domain LSP in [I-D.ietf-pce-stateful-hpce], for inter-domain LSP in Hierarchical
Hierarchical PCE architecture, the initiation operations can be PCE architecture, the initiation operations can be carried out at the
carried out at the parent PCE. In which case after parent PCE parent PCE. In which case after parent PCE finishes the E2E path
finishes the E2E path computation, it can send the PCInitiate message computation, it can send the PCInitiate message to the child PCE, the
to the child PCE, the child PCE further propagates the initiate child PCE further propagates the initiate request to the LSR. The
request to the LSR. The customer request is received by the MDSC customer request is received by the MDSC (parent PCE) and based on
(parent PCE) and based on the business logic, global abstracted the business logic, global abstracted topology, network conditions
topology, network conditions and local policy, the MDSC (parent PCE) and local policy, the MDSC (parent PCE) translates this into per
translates this into per domain LSP initiation request that a PNC domain LSP initiation request that a PNC (child PCE) can understand
(child PCE) can understand and act on. This can be done via the and act on. This can be done via the PCInitiate message.
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 Network Operations
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.
skipping to change at page 11, line 44 skipping to change at page 11, line 44
Either way, the resulted E2E paths may be broken into per- Either way, the resulted E2E paths may be broken into per-
domain paths. 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.dhodylee-pce-stateful-hpce] and [I-D.ietf-pce-stateful-hpce] and
[I-D.leedhody-pce-vn-association]). A suitable stitching [I-D.leedhody-pce-vn-association]). A suitable stitching
mechanism would be use to stitch these per domain LSPs. mechanism would be use to stitch these per domain LSPs. One
such mechanism is described in
[I-D.lee-pce-lsp-stitching-hpce], where PCEP is extended to
support stitching in stateful H-PCE context.
* Per Domain Path Report: Each PNC should report the status of * Per Domain Path Report: Each PNC should report the status of
the per-domain LSP to the MDSC via PCRpt message, as per the the per-domain LSP to the MDSC via PCRpt message, as per the
Hierarchy of stateful PCE ([I-D.dhodylee-pce-stateful-hpce]). Hierarchy of stateful PCE ([I-D.ietf-pce-stateful-hpce]). The
The status of the end to end LSP (A-B and A-C) is made up when status of the end to end LSP (A-B and A-C) is made up when all
all the per domain LSP are reported up by the PNCs. the per domain LSP are reported up by the PNCs.
* Delegation: It is suggested that the per domain LSPs are * Delegation: It is suggested that the per domain LSPs are
delegated to respective PNC, so that they can control the path delegated to respective PNC, so that they can control the path
and attributes based on each domain network conditions. and attributes based on each domain network conditions.
* 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
skipping to change at page 12, line 26 skipping to change at page 12, line 29
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). 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.dhodylee-pce-stateful-hpce]. This may result in changes in [I-D.ietf-pce-stateful-hpce]. This may result in changes in the
the E2E path or VN status. This may also trigger a re- E2E path or VN status. This may also trigger a re-optimization
optimization leading to a new per-domain path, update to existing leading to a new per-domain path, update to existing path, or
path, or deletion of the path. deletion of the path.
o VN Protection: The VN protection/restoration requirements, need to o VN Protection: The VN protection/restoration requirements, need to
applied to each E2E path as well as each per domain path. The applied to each E2E path as well as each per domain path. The
MDSC needs to play a crucial role in coordinating the right MDSC needs to play a crucial role in coordinating the right
protection/restoration policy across each PNC. The existing protection/restoration policy across each PNC. The existing
protection/restoration mechanism of PCEP can be applied on each protection/restoration mechanism of PCEP can be applied on each
path. path.
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
skipping to change at page 15, line 24 skipping to change at page 15, line 35
<http://www.rfc-editor.org/info/rfc7752>. <http://www.rfc-editor.org/info/rfc7752>.
[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,
<http://www.rfc-editor.org/info/rfc8051>. <http://www.rfc-editor.org/info/rfc8051>.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-19 (work in progress), May 2017. pce-21 (work in progress), June 2017.
[I-D.ietf-pce-pce-initiated-lsp] [I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-09 (work in Model", draft-ietf-pce-pce-initiated-lsp-10 (work in
progress), March 2017. progress), June 2017.
[I-D.dhodylee-pce-stateful-hpce] [I-D.ietf-pce-stateful-hpce]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 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-dhodylee-pce-stateful-hpce-03 (work Element (PCE).", draft-ietf-pce-stateful-hpce-00 (work in
in progress), March 2017. progress), June 2017.
[I-D.ietf-teas-pce-central-control] [I-D.ietf-teas-pce-central-control]
Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and PCEP in a Network with Architecture for Use of PCE and PCEP in a Network with
Central Control", draft-ietf-teas-pce-central-control-02 Central Control", draft-ietf-teas-pce-central-control-03
(work in progress), May 2017. (work in progress), June 2017.
[I-D.ietf-teas-actn-requirements] [I-D.ietf-teas-actn-requirements]
Lee, Y., Dhody, D., Belotti, S., Pithewan, K., Ceccarelli, Lee, Y., Dhody, D., Belotti, S., Pithewan, K., Ceccarelli,
D., Miyasaka, T., and J. Shin, "Requirements for D., Miyasaka, T., and J. Shin, "Requirements for
Abstraction and Control of TE Networks", draft-ietf-teas- Abstraction and Control of TE Networks", draft-ietf-teas-
actn-requirements-05 (work in progress), May 2017. actn-requirements-05 (work in progress), May 2017.
[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-05 (work in progress), May 2017. actn-framework-06 (work in progress), June 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-00 (work Networks (ACTN)", draft-ietf-teas-actn-info-model-01 (work
in progress), February 2017. in progress), June 2017.
[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-07 (work in progress), March 2017. dhodylee-pce-pcep-ls-08 (work in progress), June 2017.
[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-02 (work in progress), March 2017. association-02 (work in progress), March 2017.
[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-01 (work in procedures", draft-litkowski-pce-state-sync-01 (work in
progress), February 2017. progress), February 2017.
[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-00 (work in progress), draft-ietf-pce-association-policy-01 (work in progress),
December 2016. June 2017.
[I-D.ietf-pce-pceps] [I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-14 (work in Transport for PCEP", draft-ietf-pce-pceps-14 (work in
progress), May 2017. progress), May 2017.
[I-D.lee-teas-actn-abstraction] [I-D.lee-teas-actn-abstraction]
Lee, Y., Dhody, D., Ceccarelli, D., and O. Dios, Lee, Y., Dhody, D., Ceccarelli, D., and O. Dios,
"Abstraction and Control of TE Networks (ACTN) Abstraction "Abstraction and Control of TE Networks (ACTN) Abstraction
Methods", draft-lee-teas-actn-abstraction-01 (work in Methods", draft-lee-teas-actn-abstraction-02 (work in
progress), March 2017. progress), June 2017.
[I-D.lee-pce-lsp-stitching-hpce]
Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions
for Stitching LSPs in Hierarchical Stateful PCE Model",
draft-lee-pce-lsp-stitching-hpce-00 (work in progress),
June 2017.
Authors' Addresses Authors' Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
 End of changes. 24 change blocks. 
50 lines changed or deleted 58 lines changed or added

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