draft-ietf-teas-pce-central-control-03.txt   draft-ietf-teas-pce-central-control-04.txt 
TEAS Working Group A. Farrel, Ed. TEAS Working Group A. Farrel, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational Q. Zhao, Ed. Intended status: Informational Q. Zhao, Ed.
Expires: December 17, 2017 R. Li Expires: February 25, 2018 R. Li
Huawei Technologies Huawei Technologies
C. Zhou C. Zhou
Cisco Systems Cisco Systems
June 15, 2017 August 24, 2017
An Architecture for Use of PCE and PCEP in a Network with Central An Architecture for Use of PCE and PCEP in a Network with Central
Control Control
draft-ietf-teas-pce-central-control-03 draft-ietf-teas-pce-central-control-04
Abstract Abstract
The Path Computation Element (PCE) has become established as a core The Path Computation Element (PCE) has become established as a core
component of Software Defined Networking (SDN) systems. It can component of Software Defined Networking (SDN) systems. It can
compute optimal paths for traffic across a network for any definition compute optimal paths for traffic across a network for most
of "optimal" and can also monitor changes in resource availability definitions of "optimal" and can also monitor changes in resource
and traffic demands to update the paths. availability and traffic demands to update the paths.
Conventionally, the PCE has been used to derive paths for MPLS Label Conventionally, the PCE has been used to derive paths for MPLS Label
Switched Paths (LSPs). These paths are supplied using the Path Switched Paths (LSPs). These paths are supplied using the Path
Computation Element Communication Protocol (PCEP) to the head end of Computation Element Communication Protocol (PCEP) to the head end of
the LSP for signaling in the MPLS network. the LSP for signaling in the MPLS network.
SDN has a far broader applicability than just signaled MPLS traffic SDN has a far broader applicability than just signaled MPLS traffic
engineered networks, and the PCE may be used to determine paths in a engineered networks, and the PCE may be used to determine paths in a
wide range of use cases including static LSPs, segment routing, wide range of use cases including static LSPs, segment routing,
service function chaining (SFC), and indeed any form of routed or service function chaining (SFC), and indeed most forms of routed or
switched network. It is, therefore, reasonable to consider PCEP as a switched network. It is, therefore, reasonable to consider PCEP as a
general southbound control protocol for use in these environments to control protocol for use in these environments to allow the PCE to be
allow the PCE to be fully enabled as a central controller. fully enabled as a central controller.
This document briefly introduces the architecture for PCE as a This document briefly introduces the architecture for PCE as a
central controller, examines the motivations and applicability for central controller, examines the motivations and applicability for
PCEP as a southbound interface, and introduces the implications for PCEP as a control protocol in this environment, and introduces the
the protocol. A PCE-based central controller can simplify the implications for the protocol. A PCE-based central controller can
processing of distributed control plane by blending it with elements simplify the processing of distributed control plane by blending it
of SDN and without necessarily completely replacing it. with elements of SDN and without necessarily completely replacing it.
This document does not describe use cases in detail and does not This document does not describe use cases in detail and does not
define protocol extensions: that work is left for other documents. define protocol extensions: that work is left for other documents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 17, 2017. This Internet-Draft will expire on February 25, 2018.
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 3, line 10 skipping to change at page 3, line 10
3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15 3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15
3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15 3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15
3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15 3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15
3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16 3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16
3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16 3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16
3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16 3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16
3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17 3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17
3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17 3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17
4. Protocol Implications / Guidance for Solution Developers . . 18 4. Protocol Implications / Guidance for Solution Developers . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Manageability Considerations . . . . . . . . . . . . . . . . 19 6. Manageability Considerations . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The Path Computation Element (PCE) [RFC4655] was developed to offload The Path Computation Element (PCE) [RFC4655] was developed to offload
path computation function from routers in an MPLS traffic engineered path computation function from routers in an MPLS traffic engineered
network. Since then, the role and function of the PCE has grown to network. Since then, the role and function of the PCE has grown to
cover a number of other uses (such as GMPLS [RFC7025]) and to allow cover a number of other uses (such as GMPLS [RFC7025]) and to allow
delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use
of network resources [I-D.ietf-pce-pce-initiated-lsp]. of network resources [I-D.ietf-pce-pce-initiated-lsp].
skipping to change at page 4, line 11 skipping to change at page 4, line 11
This protocol was later extended to allow a PCE to send unsolicited This protocol was later extended to allow a PCE to send unsolicited
requests to the network for LSP establishment requests to the network for LSP establishment
[I-D.ietf-pce-pce-initiated-lsp]. [I-D.ietf-pce-pce-initiated-lsp].
SDN has a far broader applicability than just signaled MPLS or GMPLS SDN has a far broader applicability than just signaled MPLS or GMPLS
traffic engineered networks. The PCE component in an SDN system may traffic engineered networks. The PCE component in an SDN system may
be used to determine paths in a wide range of use cases including be used to determine paths in a wide range of use cases including
static LSPs, segment routing [I-D.ietf-spring-segment-routing], static LSPs, segment routing [I-D.ietf-spring-segment-routing],
service function chaining (SFC) [RFC7665], and indeed any form of service function chaining (SFC) [RFC7665], and indeed any form of
routed or switched network. It is, therefore, reasonable to consider routed or switched network. It is, therefore, reasonable to consider
PCEP as a general southbound control protocol for use in these PCEP as a general southbound control protocol (i.e., a control
environments to allow the PCE to be fully enabled as a central protocol for communicating from the central controller to network
controller. elements) for use in these environments to allow the PCE to be fully
enabled as a central controller.
This document introduces the architecture for PCE as a central This document introduces the architecture for PCE as a central
controller, examines the motivations and applicability for PCEP as a controller as an extension of the architecture described in [RFC4655]
southbound interface, and introduces the implications for the and assumes the continued use of PCEP as the protocol used between
protocol. A PCE-based central controller can simplify the processing PCE and PCC. The document also examines the motivations and
of distributed control plane by blending it with elements of SDN and applicability for PCEP as a southbound interface and introduces the
without necessarily completely replacing it. implications for the protocol used in this way. A PCE-based central
controller can simplify the processing of distributed control plane
by blending it with elements of SDN and without necessarily
completely replacing it.
This document does not describe use cases in detail and does not This document does not describe use cases in detail and does not
define protocol extensions: that work is left for other documents. define protocol extensions: that work is left for other documents.
2. Architecture 2. Architecture
The architecture for the use of PCE within centralized control of a The architecture for the use of PCE within centralized control of a
network is based on the understanding that a PCE can determine how network is based on the understanding that a PCE can determine how
connections should be placed and how resources should be used within connections should be placed and how resources should be used within
the network, and that the PCE can then cause those connections to be the network, and that the PCE can then cause those connections to be
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Operations Support System (OSS), a Network Management Station (NMS), Operations Support System (OSS), a Network Management Station (NMS),
or some other application. The PCE-based controller computes paths or some other application. The PCE-based controller computes paths
with awareness of the network topology, the available resources, and with awareness of the network topology, the available resources, and
the other services supported in the network. This information is the other services supported in the network. This information is
held in the Traffic Engineering Database (TED) and other databases held in the Traffic Engineering Database (TED) and other databases
available to the PCE. Then the PCE sends a request using PCEP to one available to the PCE. Then the PCE sends a request using PCEP to one
of the Network Elements (NEs), and that NE uses a control plane to of the Network Elements (NEs), and that NE uses a control plane to
establish the requested connections and reserve the network establish the requested connections and reserve the network
resources. resources.
Note that other databases (such as a database of LSPs - the LSP-DB)
might also be used, but for simplicity of illustration, just the TED
is shown.
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^
| |
v v
------------ ------------
| | ----- | | -----
| PCE-based |<---| TED | | PCE-based |<---| TED |
| Controller | ----- | Controller | -----
skipping to change at page 7, line 13 skipping to change at page 7, line 13
program individual NEs. In this way the PCE-based controller can program individual NEs. In this way the PCE-based controller can
control a wider range of networks and deliver many different control a wider range of networks and deliver many different
functions as described in Section 3. functions as described in Section 3.
There will be a trade-off in different application scenarios. In There will be a trade-off in different application scenarios. In
some cases the use of a control plane will simplify deployment (for some cases the use of a control plane will simplify deployment (for
example, by distributing recovery actions), and in other cases a example, by distributing recovery actions), and in other cases a
control plane may add operational complexity. control plane may add operational complexity.
PCEP is essentially already capable of acting as an SBI and only PCEP is essentially already capable of acting as an SBI and only
small, use case- specific modifications to the protocol are needed to small, use case specific modifications to the protocol are needed to
support this architecture. The implications for the protocol are support this architecture. The implications for the protocol are
discussed further in Section 4. discussed further in Section 4.
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^
| |
v v
------------ ------------
skipping to change at page 7, line 46 skipping to change at page 7, line 46
---- ---- ---- ----
^ ---- ---- ^ ^ ---- ---- ^
:......>| NE |...| NE |<....: :......>| NE |...| NE |<....:
Control Plane ---- ---- Control Plane ---- ----
Figure 3: Architecture for Node-by-Node Central Control Figure 3: Architecture for Node-by-Node Central Control
2.1. Resilience and Scaling 2.1. Resilience and Scaling
Systems with central controllers are vulnerable to two problems: Systems with central controllers are vulnerable to two problems:
failure or overload of the single controller. These concerns are not failure of the controller or overload of the controller. These
unique to the use of a PCE-based controller, but need to be addressed concerns are not unique to the use of a PCE-based controller, but
in this document before the PCE-based controller architecture can be need to be addressed in this document before the PCE-based controller
considered for use in all but the smallest networks. architecture can be considered for use in all but the smallest
networks.
There are three architectural mechanisms that can be applied to There are three architectural mechanisms that can be applied to
address these issues. The mechanisms are described separately for address these issues. The mechanisms are described separately for
clarity, but a deployment use may any combination of the approaches. clarity, but a deployment use may any combination of the approaches.
For simplicity of illustration, these three approaches are shown in For simplicity of illustration, these three approaches are shown in
the sections that follow without a control plane. However, the the sections that follow without a control plane. However, the
general, hybrid approach of Figure 3 is applicable in each case. general, hybrid approach of Figure 3 is applicable in each case.
2.1.1. Partitioned Network 2.1.1. Partitioned Network
skipping to change at page 15, line 31 skipping to change at page 15, line 31
Multiplexing (TDM) and Optical Transport Networks (OTN). Multiplexing (TDM) and Optical Transport Networks (OTN).
Transport networks may be operated with or without a control plane Transport networks may be operated with or without a control plane
and may have point-to-point or point-to-multipoint connections. and may have point-to-point or point-to-multipoint connections.
Thus, all of the considerations in Section 3.1.1, Section 3.1.2, and Thus, all of the considerations in Section 3.1.1, Section 3.1.2, and
Section 3.1.3 apply so that the normal PCEP message allow a PCE-based Section 3.1.3 apply so that the normal PCEP message allow a PCE-based
central controller to provision a transport network. It is usually central controller to provision a transport network. It is usually
the case that additional technology-specific parameters are needed to the case that additional technology-specific parameters are needed to
configure the NEs or LSPs in transport networks: parameters such as configure the NEs or LSPs in transport networks: parameters such as
optical characteristic. Such parameters will need to be carried in optical characteristic. Such parameters will need to be carried in
the PCEP messages: new protocol extensions may be needed, and some the PCEP messages: new protocol extensions may be needed, as
are already being worked on in [I-D.ietf-pce-wson-rwa-ext]. described, for example,in [I-D.ietf-pce-wson-rwa-ext].
3.1.5. Segment Routing 3.1.5. Segment Routing
Segment routing is described in [I-D.ietf-spring-segment-routing]. Segment routing is described in [I-D.ietf-spring-segment-routing].
It relies on a series of forwarding instructions being placed in the It relies on a series of forwarding instructions being placed in the
header or a packet. At each hop in the network a router looks at the header of a packet. At each hop in the network a router looks at the
first instruction and may: continue to forward the packet unchanged; first instruction and may: continue to forward the packet unchanged;
strip the top instruction and forward the packet; or strip the top strip the top instruction and forward the packet; or strip the top
instruction, insert some additional instructions, and forward the instruction, insert some additional instructions, and forward the
packet. packet.
The segment routing architecture supports operations that can be used The segment routing architecture supports operations that can be used
to steer packet flows in a network thus providing a form of traffic to steer packet flows in a network thus providing a form of traffic
engineering. A PCE-based controller can be responsible for computing engineering. A PCE-based controller can be responsible for computing
the paths for packet flows in a segment routing network, for the paths for packet flows in a segment routing network, for
configuring the forwarding actions on the routers, and for telling configuring the forwarding actions on the routers, and for telling
skipping to change at page 17, line 37 skipping to change at page 17, line 37
Traffic classification is closely linked to the computational Traffic classification is closely linked to the computational
elements of planning for the network functions just listed because it elements of planning for the network functions just listed because it
determines how traffic load is balanced and distributed through the determines how traffic load is balanced and distributed through the
network. Therefore, selecting what traffic classification should be network. Therefore, selecting what traffic classification should be
performed by a router is an important part of the work done by a PCE- performed by a router is an important part of the work done by a PCE-
based controller. based controller.
Instructions can be passed from the controller to the routers using Instructions can be passed from the controller to the routers using
PCEP. These instructions tell the routers how to map traffic to PCEP. These instructions tell the routers how to map traffic to
paths or connections. The instructions may use the concept of a paths or connections.
Forwarding Equivalence Class (FEC).
3.2.3. Service Delivery 3.2.3. Service Delivery
Various network services may be offered over a network. These Various network services may be offered over a network. These
include protection services (including end-to-end protection include protection services (including end-to-end protection
[RFC4427], restoration after failure, and fast reroute [RFC4090]), [RFC4427], restoration after failure, and fast reroute [RFC4090]),
Virtual Private Network (VPN) service (such as Layer 3 VPNs [RFC4364] Virtual Private Network (VPN) service (such as Layer 3 VPNs [RFC4364]
or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985].
Delivering services over a network in an optimal way requires Delivering services over a network in an optimal way requires
skipping to change at page 18, line 22 skipping to change at page 18, line 21
network elements). In particular, it has a message (PCInitiate network elements). In particular, it has a message (PCInitiate
[I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the PCE to [I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the PCE to
install state or cause actions at the PCC, and a response message install state or cause actions at the PCC, and a response message
(PCRpt) that is used to confirm the request. (PCRpt) that is used to confirm the request.
As such, there is an expectation that only relatively minor changes As such, there is an expectation that only relatively minor changes
to PCEP are required to support the concept of a PCE-based to PCEP are required to support the concept of a PCE-based
controller. The only work expected to be needed is extensions to controller. The only work expected to be needed is extensions to
existing PCEP messages to carry additional or specific information existing PCEP messages to carry additional or specific information
elements for the individual use cases, which maintain backward elements for the individual use cases, which maintain backward
compatibility and do not impact existing PCEP deployments. Where compatibility and do not impact existing PCEP deployments. [RFC5440]
possible, consistent with the general principles of how protocols are already describes how legacy implementations handle unknown protocol
extended, any additions to the protocol should be made in a generic extensions and how to use the PCEP Open message to indicate support
way such that they are open to use in a range of applications. for PCEP features. Where possible, consistent with the general
principles of how protocols are extended, any additions to the
protocol should be made in a generic way such that they are open to
use in a range of applications.
It is anticipated that new documents will be produced for each use It is anticipated that new documents (such as
case dependent on support and demand. Such documents will explain [I-D.zhao-pce-pcep-extension-for-pce-controller]) will be produced
the use case and define the necessary protocol extensions. for each use case dependent on support and demand. Such documents
will explain the use case and define the necessary protocol
extensions.
Protocol extensions could have impact on existing PCEP deployments Protocol extensions could have impact on existing PCEP deployments
and the interoperability between different implementations. It is and the interoperability between different implementations. It is
anticipated that changes of the PCEP protocol or addition of anticipated that changes of the PCEP protocol or addition of
information elements could require additional testing to ensure information elements could require additional testing to ensure
interoperability between different PCEP implementations. interoperability between different PCEP implementations.
It is reasonable to expect that implementations are able to select a It is reasonable to expect that implementations are able to select a
subset or profile of the protocol extensions and PCEP features that subset or profile of the protocol extensions and PCEP features that
are relevant for the application scenario in which they will be are relevant for the application scenario in which they will be
deployed. Identification of these profiles should form part of the deployed. Identification of these profiles should form part of the
protocol itself so that interoperability can be easily determined and protocol itself so that interoperability can be easily determined and
so that testing can be limited to the specific profiles. so that testing can be limited to the specific profiles.
Note that protocol mechanisms to handle synchronization of state in
parallel PCE-based controllers will also be required if parallel
controllers are used as described in Section 2.1.2. There is a
discussion of mechanisms to achieve PCE state synchronization in
[I-D.ietf-pce-stateful-pce].
5. Security Considerations 5. Security Considerations
Security considerations for a PCE-based controller are little Security considerations for a PCE-based controller are little
different from those for any other PCE system. That is, the different from those for any other PCE system. That is, the
operation relies heavily on the use and security of PCEP and so operation relies heavily on the use and security of PCEP and so
consideration should be given to the security features discussed in consideration should be given to the security features discussed in
[RFC5440] and the additional mechanisms described in [RFC5440] and the additional mechanisms described in
[I-D.ietf-pce-pceps]. [I-D.ietf-pce-pceps].
It should be observed that the trust model of a network that operates It should be observed that the trust model of a network that operates
without a control plane is different from one with a control plane. without a control plane is different from one with a control plane.
The conventional "chain of trust" used with a control plane is The conventional "chain of trust" used with a control plane is
replaced by individual trust relationships between the controller and replaced by individual trust relationships between the controller and
each individual NE. This model may be considerably easier to manage each individual NE. This model may be considerably easier to manage
and so is more likely to be operated with a high level of security. and so is more likely to be operated with a high level of security.
However, debate will rage over overall system security and the
opportunity for attacks in an architecture with a central controller However, an architecture with a central controller has a central
since the network can be vulnerable to denial of service attacks on point of failure and this is also a security weakness since the
the controller, and the forwarding system may be harmed by attacks on network can be vulnerable to denial of service attacks on the
the messages sent to individual NEs. In short, while the controller. Similarly, the central controller provides a focus for
interactions with a PCE-based controller are not substantially interception and modification of messages sent to individual NEs. In
different from those in any other SDN architecture, the security short, while the interactions with a PCE-based controller are not
implications of SDN are still open for discussion. The IRTF's SDN substantially different to those in any other SDN architecture, the
Research Group (SDNRG) discussed this topic. security implications of SDN have not been fully discussed or
described. Therefore, protocol and applicability work around
solutions for this architecture must take proper account of these
concerns.
It is expected that each new document that is produced for a specific It is expected that each new document that is produced for a specific
use case will also include considerations of the security impacts of use case will also include considerations of the security impacts of
the use of a PCE-based central controller on the network type and the use of a PCE-based central controller on the network type and
services being managed. services being managed.
6. Manageability Considerations 6. Manageability Considerations
The architecture described in this document is a management The architecture described in this document is a management
architecture: the PCE-based controller is a management component that architecture: the PCE-based controller is a management component that
controls the network through a southbound management protocol (PCEP). controls the network through a southbound management protocol (PCEP).
An implementation of a PCE-based controller will require access to
information about the state of the network, its nodes, and its links.
Some of this will be the TED as is normal for a PCE and can be
collected using the mechanisms already in place (such as listening to
the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-
encoded data [I-D.ietf-teas-yang-te-topo]). More information may be
collected in the LSP database as described for stateful PCEs as
described in [RFC7399] and [I-D.ietf-pce-stateful-pce]. Additional
information may be needed for other specific use cases and will need
to be collected and passed to the controller.
The use of different PCEP options and protocol extensions may have an The use of different PCEP options and protocol extensions may have an
impact on interoperability, which is a management issue. As noted in impact on interoperability, which is a management issue. As noted in
Section 4, protocol extensions should be done in a way that makes it Section 4, protocol extensions should be done in a way that makes it
possible to identify profiles of PCEP to aid interoperability and possible to identify profiles of PCEP to aid interoperability and
this will aid deployment and manageability. this will aid deployment and manageability.
RFC 5440 [RFC5440] contains a substantive manageability RFC 5440 [RFC5440] contains a substantive manageability
considerations section that examines how a PCE-based system and a considerations section that examines how a PCE-based system and a
PCE-enabled system may be managed. A MIB module for PCEP was PCE-enabled system may be managed. A MIB module for PCEP was
published as RFC 7420 [RFC7420] and a YANG module for PCEP has also published as RFC 7420 [RFC7420] and a YANG module for PCEP has also
skipping to change at page 20, line 42 skipping to change at page 21, line 21
involved for opening the discussion. The individuals concerned are: involved for opening the discussion. The individuals concerned are:
King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li. King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li.
This document has benefited from the discussions within a small ad This document has benefited from the discussions within a small ad
hoc design team the members of which are listed as document hoc design team the members of which are listed as document
contributors. contributors.
Thanks to Michael Scharf and Andy Malis for a lively discussion of Thanks to Michael Scharf and Andy Malis for a lively discussion of
this document. this document.
Thanks to Phil Bedard and Aijun Wang for last call comments on this Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call
document. comments on this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-10 (work in
progress), June 2017.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4655>. editor.org/info/rfc4655>.
10.2. Informative References [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, <https://www.rfc-
editor.org/info/rfc5440>.
[I-D.ietf-pce-pce-initiated-lsp] 10.2. Informative References
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-09 (work in
progress), March 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-16 (work in
progress), May 2017. progress), August 2017.
[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-wson-rwa-ext] [I-D.ietf-pce-wson-rwa-ext]
Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing
and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06 and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06
(work in progress), December 2016. (work in progress), December 2016.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-11 (work in progress), February spring-segment-routing-12 (work in progress), June 2017.
2017.
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for TE Topologies", draft-ietf-
teas-yang-te-topo-12 (work in progress), July 2017.
[I-D.pkd-pce-pcep-yang] [I-D.pkd-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and j. Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)", Computation Element Communications Protocol (PCEP)",
draft-pkd-pce-pcep-yang-06 (work in progress), July 2016. draft-pkd-pce-pcep-yang-06 (work in progress), July 2016.
[I-D.zhao-pce-pcep-extension-for-pce-controller] [I-D.zhao-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Dhody, D., and C. Zhou, "PCEP Procedures Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A.,
and Protocol Extensions for Using PCE as a Central and C. Zhou, "PCEP Procedures and Protocol Extensions for
Controller (PCECC) of LSPs", draft-zhao-pce-pcep- Using PCE as a Central Controller (PCECC) of LSPs", draft-
extension-for-pce-controller-04 (work in progress), zhao-pce-pcep-extension-for-pce-controller-05 (work in
January 2017. progress), June 2017.
[I-D.zhao-teas-pcecc-use-cases] [I-D.zhao-teas-pcecc-use-cases]
Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou, Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou,
C., Communications, T., Rachitskiy, A., and A. Gulida, C., Communications, T., Rachitskiy, A., and A. Gulida,
"The Use Cases for Using PCE as the Central "The Use Cases for Using PCE as the Central
Controller(PCECC) of LSPs", draft-zhao-teas-pcecc-use- Controller(PCECC) of LSPs", draft-zhao-teas-pcecc-use-
cases-02 (work in progress), October 2016. cases-02 (work in progress), October 2016.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999, RFC 2702, DOI 10.17487/RFC2702, September 1999,
<http://www.rfc-editor.org/info/rfc2702>. <https://www.rfc-editor.org/info/rfc2702>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3985>. editor.org/info/rfc3985>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005, DOI 10.17487/RFC4090, May 2005, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4090>. editor.org/info/rfc4090>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized (Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4427>. editor.org/info/rfc4427>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://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-
<http://www.rfc-editor.org/info/rfc6805>. editor.org/info/rfc6805>.
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
Margaria, "Requirements for GMPLS Applications of PCE", Margaria, "Requirements for GMPLS Applications of PCE",
RFC 7025, DOI 10.17487/RFC7025, September 2013, RFC 7025, DOI 10.17487/RFC7025, September 2013,
<http://www.rfc-editor.org/info/rfc7025>. <https://www.rfc-editor.org/info/rfc7025>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7399>. editor.org/info/rfc7399>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Communication Protocol Hardwick, "Path Computation Element Communication Protocol
(PCEP) Management Information Base (MIB) Module", (PCEP) Management Information Base (MIB) Module",
RFC 7420, DOI 10.17487/RFC7420, December 2014, RFC 7420, DOI 10.17487/RFC7420, December 2014,
<http://www.rfc-editor.org/info/rfc7420>. <https://www.rfc-editor.org/info/rfc7420>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7491>. editor.org/info/rfc7491>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7665>. editor.org/info/rfc7665>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, <https://www.rfc-
editor.org/info/rfc7752>.
Authors' Addresses Authors' Addresses
Adrian Farrel (editor) Adrian Farrel (editor)
Juniper Networks Juniper Networks
Email: afarrel@juniper.net Email: afarrel@juniper.net
Quintin Zhao (editor) Quintin Zhao (editor)
Huawei Technologies Huawei Technologies
 End of changes. 45 change blocks. 
99 lines changed or deleted 142 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/