draft-ietf-pce-applicability-actn-06.txt   draft-ietf-pce-applicability-actn-07.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 19, 2018 D. Ceccarelli Expires: April 25, 2019 D. Ceccarelli
Ericsson Ericsson
June 17, 2018 October 22, 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-06 draft-ietf-pce-applicability-actn-07
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 December 19, 2018. This Internet-Draft will expire on April 25, 2019.
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 28 skipping to change at page 2, line 28
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.1.3. Relationship to PCE based central control . . . . . . 4 1.1.3. Relationship to PCE based central control . . . . . . 4
1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5 1.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5
1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 7 1.3. PCE and ACTN . . . . . . . . . . . . . . . . . . . . . . 6
2. Architectural Considerations . . . . . . . . . . . . . . . . 7 2. Architectural Considerations . . . . . . . . . . . . . . . . 7
2.1. Multi domain coordination via Hierarchy . . . . . . . . . 7 2.1. Multi domain coordination via Hierarchy . . . . . . . . . 7
2.2. Abstraction function . . . . . . . . . . . . . . . . . . 8 2.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Customer mapping function . . . . . . . . . . . . . . . . 9 2.3. Customer mapping . . . . . . . . . . . . . . . . . . . . 9
2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10 2.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
3. Interface Considerations . . . . . . . . . . . . . . . . . . 10 3. Interface Considerations . . . . . . . . . . . . . . . . . . 10
4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11 4. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 5, line 8 skipping to change at page 5, line 8
[RFC8283] introduces the architecture for PCE as a central controller [RFC8283] introduces the architecture for PCE as a central controller
(PCECC), it further examines the motivations and applicability for (PCECC), it further examines the motivations and applicability for
PCEP as a southbound interface, and introduces the implications for PCEP as a southbound interface, and introduces the implications for
the protocol. The section 2.1.3 of [RFC8283] describe an hierarchy the protocol. The section 2.1.3 of [RFC8283] describe an hierarchy
of PCE-based controller as per the Hierarchy of PCE framework defined of PCE-based controller as per the Hierarchy of PCE framework defined
in [RFC6805]. 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. [RFC8453] describes the architecture model for ACTN
architecture model for ACTN including the entities (Customer Network including the entities (Customer Network Controller(CNC), Multi-
Controller(CNC), Multi-domain Service Coordinator(MDSC), and domain Service Coordinator(MDSC), and Provisioning Network Controller
Provisioning Network Controller (PNC) and their interfaces. (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 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
\ | / \ | /
\ | / \ | /
Boundary =============\==============|==============/============ Boundary =============\==============|==============/============
skipping to change at page 6, line 45 skipping to change at page 6, line 45
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
(CMI CNC-MDSC Interface) and one south (MPI MDSC-PNC Interface). A (CMI CNC-MDSC Interface) and one south (MPI MDSC-PNC Interface). A
hierarchy 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 [RFC8454] 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
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 Further, ACTN, Stateful H-PCE, and PCECC are based on the same basic
hierarchy framework and thus compatible with each other. 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 [RFC8453] architecture is based on hierarchy and recursiveness
hierarchy and recursiveness of controllers. It defines three types of controllers. It defines three types of controllers (depending on
of controllers (depending on the functionalities they implement). the functionalities they implement). The main functionalities are -
The main functionalities are -
o Multi domain coordination function o Multi domain coordination
o Abstraction function o Abstraction
o Customer mapping/translation function o Customer mapping/translation
o Virtual service coordination function o Virtual service coordination
Section 3 of [I-D.ietf-teas-actn-framework] describes these Section 3 of [RFC8453] 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 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 [RFC8453], it is
[I-D.ietf-teas-actn-framework], it is needed to have a control entity needed to have a control entity that oversees the specific aspects of
that oversees the specific aspects of the different domains and to the different domains and to build a single abstracted end-to-end
build a single abstracted end-to-end network topology in order to network topology in order to coordinate end-to-end path computation
coordinate end-to-end path computation and path/service provisioning. 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.ietf-pce-stateful-hpce] describes a hierarchy of [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a hierarchy 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
skipping to change at page 8, line 26 skipping to change at page 8, line 18
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. Abstraction function 2.2. Abstraction
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).
Traditionally this TED has been obtained from a link state (LS) Traditionally this TED has been obtained from a link state (LS)
routing protocol supporting traffic engineering extensions. PCE may routing protocol supporting traffic engineering extensions. PCE may
construct its TED by participating in the IGP ([RFC3630] and construct its TED by participating in the IGP ([RFC3630] and
[RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An
alternative is offered by BGP-LS [RFC7752]. alternative is offered by BGP-LS [RFC7752].
In case of H-PCE [RFC6805], the parent PCE needs to build the domain In case of H-PCE [RFC6805], the parent PCE needs to build the domain
topology map of the child domains and their interconnectivity. topology map of the child domains and their interconnectivity.
[RFC6805] and [I-D.ietf-pce-inter-area-as-applicability] suggest that [RFC6805] and [I-D.ietf-pce-inter-area-as-applicability] suggest that
BGP-LS could be used as a "northbound" TE advertisement from the BGP-LS could be used as a "northbound" TE advertisement from the
child PCE to the parent PCE. child PCE to the parent PCE.
[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.ietf-teas-actn-framework] describes a few alternative approaches [RFC8453] describes a few alternative approaches of abstraction. The
of abstraction. The resulting abstracted topology can be encoded resulting abstracted topology can be encoded using the PCEP-LS
using the PCEP-LS mechanisms [I-D.dhodylee-pce-pcep-ls] and its mechanisms [I-D.dhodylee-pce-pcep-ls] and its optical network
optical network extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is extension [I-D.lee-pce-pcep-ls-optical]. PCEP-LS is an attractive
an attractive option when the operator would wish to have a single option when the operator would wish to have a single control plane
control plane protocol (PCEP) to achieve ACTN functions. protocol (PCEP) to achieve ACTN functions.
[I-D.ietf-teas-actn-framework] discusses two ways to build abstract [RFC8453] discusses two ways to build abstract topology from an MDSC
topology from an MDSC standpoint with interaction with PNCs. The standpoint with interaction with PNCs. The primary method is called
primary method is called automatic generation of abstract topology by automatic generation of abstract topology by configuration. With
configuration. With this method, automatic generation is based on this method, automatic generation is based on the abstraction/
the abstraction/summarization of the whole domain by the PNC and its summarization of the whole domain by the PNC and its advertisement on
advertisement on the MPI. The secondary method is called on-demand the MPI. The secondary method is called on-demand generation of
generation of supplementary topology via Path Compute Request/Reply. supplementary topology via Path Compute Request/Reply. This method
This method may be needed to obtain further complementary information may be needed to obtain further complementary information such as
such as potential connectivity from child PCEs in order to facilitate potential connectivity from child PCEs in order to facilitate an end-
an end-to-end path provisioning. PCEP is well suited to support both to-end path provisioning. PCEP is well suited to support both
methods. methods.
2.3. Customer mapping function 2.3. Customer mapping
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,
the customer requests/commands are mapped into network provisioning the customer requests/commands are mapped into network provisioning
requests that can be sent to the PNC. Specifically, it provides requests that can be sent to the PNC. Specifically, it provides
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.
[RFC8281] describes the setup, maintenance and teardown of PCE- [RFC8281] describes the setup, maintenance and teardown of PCE-
skipping to change at page 10, line 36 skipping to change at page 10, line 29
the VN slice. During path computation, the impact of a path for an the VN slice. During path computation, the impact of a path for an
LSP is compared against the paths of other LSPs in the VN. This is LSP is compared against the paths of other LSPs in the VN. This is
to make sure that the overall optimization and SLA of the VN rather to make sure that the overall optimization and SLA of the VN rather
than of a single LSP. Similarly, during re-optimization, advanced than of a single LSP. Similarly, during re-optimization, advanced
path computation algorithm and optimization technique can be path computation algorithm and optimization technique can be
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 [RFC8453], to allow virtualization and multi domain
multi domain coordination, the network has to provide open, coordination, the network has to provide open, programmable
programmable interfaces, in which customer applications can create, interfaces, in which customer applications can create, replace and
replace and modify virtual network resources and services in an modify virtual network resources and services in an interactive,
interactive, flexible and dynamic fashion while having no impact on flexible and dynamic fashion while having no impact on other
other customers. The two ACTN interfaces are - 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 11, line 17 skipping to change at page 11, line 8
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 In case of hierarchy of MDSC, the MPI is applied recursively. o In case of hierarchy of MDSC, the MPI is applied recursively.
From an abstraction point of view, the top level MDSC which From an abstraction point of view, the top level MDSC which
interfaces the CNC operates on a higher level of abstraction interfaces the CNC operates on a higher level of abstraction
(i.e., less 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 [RFC8453]. Its
[I-D.ietf-teas-actn-framework]. Its recursive nature is well suited recursive nature is well suited via the multi-level hierarchy of PCE.
via the multi-level hierarchy of PCE. PCEP can also be applied to PCEP can also be applied to the CMI as the CNC can be a path
the CMI as the CNC can be a path computation client while the MDSC computation client while the MDSC can be a path computation server.
can be a path computation server. The Section 4 describe how PCE and The Section 4 describe how PCE and PCEP could help realize ACTN on
PCEP could help realize ACTN on the MPI. the MPI.
4. Realizing ACTN with PCE (and PCEP) 4. Realizing 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
its own PNC and a MDSC at top. The PNC and MDSC need PCE as a its own PNC and a MDSC at top. The PNC and MDSC need PCE as a
important function. The PNC (or child PCE) already uses PCEP to important function. The PNC (or child PCE) already uses PCEP to
communicate to the network device. It can utilize the PCEP as the communicate to the network device. It can utilize the PCEP as the
MPI to communicate between controllers too. MPI to communicate between controllers too.
****** ******
skipping to change at page 15, line 12 skipping to change at page 15, line 12
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. IANA Considerations 5. 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.
6. Security Considerations 6. Security Considerations
The ACTN framework described in [I-D.ietf-teas-actn-framework] The ACTN framework described in [RFC8453] defines key components and
defines key components and interfaces for managed traffic engineered interfaces for managed traffic engineered networks. It also list
networks. It also list various security considerations such as various security considerations such as request and control of
request and control of resources, confidentially of the information, resources, confidentially of the information, and availability of
and availability of function which should be taken into 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.
7. 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
skipping to change at page 15, line 45 skipping to change at page 15, line 44
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>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805, of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012, DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>. <https://www.rfc-editor.org/info/rfc6805>.
[I-D.ietf-teas-actn-framework] [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Ceccarelli, D. and Y. Lee, "Framework for Abstraction and Abstraction and Control of TE Networks (ACTN)", RFC 8453,
Control of Traffic Engineered Networks", draft-ietf-teas- DOI 10.17487/RFC8453, August 2018,
actn-framework-15 (work in progress), May 2018. <https://www.rfc-editor.org/info/rfc8453>.
8.2. Informative References 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
skipping to change at page 18, line 17 skipping to change at page 18, line 17
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 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control", Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017, RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>. <https://www.rfc-editor.org/info/rfc8283>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[I-D.ietf-pce-stateful-hpce] [I-D.ietf-pce-stateful-hpce]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D.,
and O. Dios, "Hierarchical Stateful Path Computation and O. Dios, "Hierarchical Stateful Path Computation
Element (PCE).", draft-ietf-pce-stateful-hpce-04 (work in Element (PCE).", draft-ietf-pce-stateful-hpce-05 (work in
progress), March 2018. progress), June 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-info-model]
Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", draft-ietf-teas-actn-info-model-09 (work
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
Distribution of Link-State and TE Information.", draft- Distribution of Link-State and TE Information.", draft-
dhodylee-pce-pcep-ls-10 (work in progress), March 2018. dhodylee-pce-pcep-ls-11 (work in progress), June 2018.
[I-D.lee-pce-pcep-ls-optical] [I-D.lee-pce-pcep-ls-optical]
Lee, Y., zhenghaomian@huawei.com, z., Ceccarelli, D., Lee, Y., Zheng, H., Ceccarelli, D., weiw@bupt.edu.cn, w.,
weiw@bupt.edu.cn, w., Park, P., and B. Yoon, "PCEP Park, P., and B. Yoon, "PCEP Extension for Distribution of
Extension for Distribution of Link-State and TE Link-State and TE information for Optical Networks",
information for Optical Networks", draft-lee-pce-pcep-ls- draft-lee-pce-pcep-ls-optical-05 (work in progress),
optical-04 (work in progress), February 2018. September 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-05 (work in progress), June 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-03 (work in procedures", draft-litkowski-pce-state-sync-03 (work in
progress), April 2018. 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-03 (work in progress),
February 2018. June 2018.
[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
 End of changes. 32 change blocks. 
87 lines changed or deleted 83 lines changed or added

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