draft-ietf-teas-pce-central-control-00.txt   draft-ietf-teas-pce-central-control-01.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: March 5, 2017 R. Li Expires: June 8, 2017 R. Li
Huawei Technologies Huawei Technologies
C. Zhou C. Zhou
Cisco Systems Cisco Systems
September 1, 2016 December 5, 2016
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-00 draft-ietf-teas-pce-central-control-01
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 any definition
of "optimal" and can also monitor changes in resource availability of "optimal" and can also monitor changes in resource availability
and traffic demands to update the paths. 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 any form 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 general southbound control protocol for use in these environments to
allow the PCE to be fully enabled as a central controller. allow the PCE to be 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 southbound interface, and introduces the implications for
the protocol. This document does not describe the use cases in the protocol. This document does not describe the use cases in
detail and does not define protocol extensions: that work is left for detail and does not define protocol extensions: that work is left for
other documents. other documents.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 March 5, 2017. This Internet-Draft will expire on June 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 25 skipping to change at page 3, line 25
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].
According to [RFC7399], Software Defined Networking (SDN) refers to a According to [RFC7399], Software Defined Networking (SDN) refers to a
separation between the control elements and the forwarding components separation between the control elements and the forwarding components
so that software running in a centralized system called a controller, so that software running in a centralized system, called a
can act to program the devices in the network to behave in specific controller, can act to program the devices in the network to behave
ways. A required element in an SDN architecture is a component that in specific ways. A required element in an SDN architecture is a
plans how the network resources will be used and how the devices will component that plans how the network resources will be used and how
be programmed. It is possible to view this component as performing the devices will be programmed. It is possible to view this
specific computations to place flows within the network given component as performing specific computations to place traffic flows
knowledge of the availability of network resources, how other within the network given knowledge of the availability of network
forwarding devices are programmed, and the way that other flows are resources, how other forwarding devices are programmed, and the way
routed. This is the function and purpose of a PCE, and the way that that other flows are routed. This is the function and purpose of a
a PCE integrates into a wider network control system including SDN is PCE, and the way that a PCE integrates into a wider network control
presented in [RFC7491]. system (including an SDN system) is presented in [RFC7491].
In early PCE implementations, where the PCE was used to derive paths In early PCE implementations, where the PCE was used to derive paths
for MPLS Label Switched Paths (LSPs), paths were requested by network for MPLS Label Switched Paths (LSPs), paths were requested by network
elements and the results of the path computations were supplied to elements (known as Path Computation Clients - PCCs) and the results
network elements using the Path Computation Element Communication of the path computations were supplied to network elements using the
Protocol (PCEP) [RFC5440]. This protocol was later extended to allow Path Computation Element Communication Protocol (PCEP) [RFC5440].
a PCE to send unsolicited requests to the network for LSP This protocol was later extended to allow a PCE to send unsolicited
establishment [I-D.ietf-pce-pce-initiated-lsp]. requests to the network for LSP establishment
[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 for use in these
environments to allow the PCE to be fully enabled as a central environments to allow the PCE to be fully enabled as a central
controller. 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, examines the motivations and applicability for PCEP as a
southbound interface, and introduces the implications for the southbound interface, and introduces the implications for the
protocol. This document dos not describe the use cases in detail and protocol. This document does not describe the use cases in detail
does not define protocol extensions: that work is left for other and does not define protocol extensions: that work is left for other
documents. 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
established. Figure 1 shows how this control relationship works in a established. Figure 1 shows how this control relationship works in a
network with an active control plane. This is a familiar view for network with an active control plane. This is a familiar view for
skipping to change at page 5, line 35 skipping to change at page 5, line 35
Figure 1: Architecture for Central Controller with Control Plane Figure 1: Architecture for Central Controller with Control Plane
Although the architecture shown in Figure 1 represents a form of SDN, Although the architecture shown in Figure 1 represents a form of SDN,
one objective of SDN in some environments is to remove the dependency one objective of SDN in some environments is to remove the dependency
on a control plane. A transition architecture toward this goal is on a control plane. A transition architecture toward this goal is
presented in [RFC7491] and is shown in Figure 2. In this case, presented in [RFC7491] and is shown in Figure 2. In this case,
services are still requested in the same way, and the PCE-based services are still requested in the same way, and the PCE-based
controller still requests use of the network using PCEP. The main controller still requests use of the network using PCEP. The main
difference is that the consumer of the PCEP messages is a Network difference is that the consumer of the PCEP messages is a Network
Controller that provisions the resources and instructs the data plane Controller that provisions the resources and instructs the data plane
using Southbound Interface (SBI) that provides an interface to each using a Southbound Interface (SBI) that provides an interface to each
NE. NE.
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^
| |
v v
------------ ------------
| | ----- | | -----
skipping to change at page 7, line 42 skipping to change at page 7, line 42
^ ---- ---- ^ ^ ---- ---- ^
:......>| 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 or overload of the single controller. These concerns are not
unique to the use of a PCE-based controller but need to be addressed unique to the use of a PCE-based controller, but need to be addressed
in this document before the PCE-based controller architecture can be in this document before the PCE-based controller architecture can be
considered for use in all but the smallest networks. 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.
skipping to change at page 9, line 15 skipping to change at page 9, line 15
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^ ^ ^
| | | |
v v v v
------------ Coord- ------------ ------------ Coord- ------------
----- | | ination | | ----- ----- | | ination | | -----
| TED |--->| PCE-based |<-------->| PCE-based |<---| TED | | TED |--->| PCE-based |<-------->| PCE-based |<---| TED |
----- | Controller | | Controller | ----- ----- | Controller | | Controller | -----
| | | | | | :: | |
/------------ ------------\ /------------ :: ------------\
/ ^ ^ ^ ^ \ / ^ ^ :: ^ ^ \
/ | | | | \ / | | :: | | \
| | | | | | | | | :: | | |
v v v :: v v v v v v :: v v v
---- ---- ---- :: ---- ---- ---- ---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE | | NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ---- ---- ---- ---- :: ---- ---- ----
:: ::
Domain 1 :: Domain 2 Domain 1 :: Domain 2
:: ::
Figure 4: Multiple Controllers on a Partitioned Network Figure 4: Multiple Controllers on a Partitioned Network
skipping to change at page 10, line 22 skipping to change at page 10, line 22
------------ ------------ ------------ ------------
| | ----- | | | | ----- | |
| PCE-based |<---| TED |--->| PCE-based | | PCE-based |<---| TED |--->| PCE-based |
| Controller | ----- | Controller | | Controller | ----- | Controller |
| |__ ...........| | | |__ ...........| |
------------\ \_:__ :------------ ------------\ \_:__ :------------
^ ^ \___: \ .....: ^ ^ ^ ^ \___: \ .....: ^ ^
| | .....:\ \_:___ ..: : | | .....:\ \_:___ ..: :
| |__:___ \___:_ \_:___ : | |__:___ \___:_ \_:___ :
| ....: | .....: | ..: | : | ....: | .....: | ..: | :
| : | : | : | : | : | : | :
v v v v v v v v v v v v v v v v
---- ---- ---- ---- ---- ---- ---- ----
| NE | | NE | | NE | | NE | | NE | | NE | | NE | | NE |
---- ---- ---- ---- ---- ---- ---- ----
Figure 5: Multiple Redundant Controllers Figure 5: Multiple Redundant Controllers
2.1.3. Hierarchical Controllers 2.1.3. Hierarchical Controllers
Figure 6 shows an approach with hierarchical controllers. This Figure 6 shows an approach with hierarchical controllers. This
skipping to change at page 10, line 44 skipping to change at page 10, line 44
SDN architectures where a "parent PCE", an "orchestrator", or "super SDN architectures where a "parent PCE", an "orchestrator", or "super
controller" takes responsibility for a high-level view of the network controller" takes responsibility for a high-level view of the network
before distributing tasks to lower level PCEs or controllers. before distributing tasks to lower level PCEs or controllers.
On its own, this approach does little to protect against the failure On its own, this approach does little to protect against the failure
of a controller, but it can make significant improvements in loading of a controller, but it can make significant improvements in loading
and scaling of the individual controllers. It also offers a good way and scaling of the individual controllers. It also offers a good way
to support end-to-end connectivity across multiple administrative or to support end-to-end connectivity across multiple administrative or
technology-specific domains. technology-specific domains.
Note that this model can be arbitrarily recursive with one PCE-based Note that this model can be arbitrarily recursive with a PCE-based
controller acting as the parent of of another set of PCE-based controller being the child of one parent PCE-based controller while
controllers. acting as the parent of another set of PCE-based controllers.
-------------------------------------------- --------------------------------------------
| Orchestrator / Service Manager / OSS / NMS | | Orchestrator / Service Manager / OSS / NMS |
-------------------------------------------- --------------------------------------------
^ ^
| |
v v
------------ ------------
| Parent | ----- | Parent | -----
| PCE-based |<---| TED | | PCE-based |<---| TED |
| Controller | ----- | Controller | -----
| | | |
------------ ------------
^ ^ ^ ^
| | | |
v v v :: v
------------ ------------ ------------ :: ------------
----- | | | | ----- ----- | | :: | | -----
| TED |--->| PCE-based | | PCE-based |<---| TED | | TED |--->| PCE-based | :: | PCE-based |<---| TED |
----- | Controller | | Controller | ----- ----- | Controller | :: | Controller | -----
/| | | |\ /| | :: | |\
/ ------------ ------------ \ / ------------ :: ------------ \
/ ^ ^ ^ ^ \ / ^ ^ :: ^ ^ \
/ | | | | \ / | | :: | | \
/ | | | | \ / | | :: | | \
| | | :: | | | | | | :: | | |
v v v :: v v v v v v :: v v v
---- ---- ---- :: ---- ---- ---- ---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE | | NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ---- ---- ---- ---- :: ---- ---- ----
:: ::
Domain 1 :: Domain 2 Domain 1 :: Domain 2
:: ::
Figure 6: Hierarchical Controllers Figure 6: Hierarchical Controllers
skipping to change at page 13, line 34 skipping to change at page 13, line 34
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. It may be the case that additional technology- Section 3.1.3 apply. It may be the case that additional technology-
specific parameters are needed to configure the NEs and these specific parameters are needed to configure the NEs and these
parameters will need to be carried in the PCEP messages. parameters will need to be carried in the PCEP messages.
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 or 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
the edge routers what instructions to attach to packets as they enter the edge routers what instructions to attach to packets as they enter
the network. These last two operations can be achieved using PCEP the network. These last two operations can be achieved using PCEP
and the PCE-based controller will assume responsibility for managing and the PCE-based controller will assume responsibility for managing
the space of labels or path identifiers used to determine how packets the space of labels or path identifiers used to determine how packets
are forwarded. are forwarded.
3.1.6. Service Function Chaining 3.1.6. Service Function Chaining
Service Function Chaining (SFC) is described in [RFC7665]. It is the Service Function Chaining (SFC) is described in [RFC7665]. It is the
process of directing traffic in a network such that it passes through process of directing traffic in a network such that it passes through
specific hardware devices or virtual machines (known as service specific hardware devices or virtual machines (known as service
function nodes) that can perform particular desired functions on the function nodes) that can perform particular desired functions on the
traffic. The set of functions to be performed and the locations at traffic. The set of functions to be performed and the order in which
which they are to be performed is known as service function chain. they are to be performed is known as a Service Function Chain. The
Each packet is marked as belonging to a specific chain and that chain is enhanced with the locations at which the service functions
marking lets each successive service function node know which are to be performed to derive a Service Function Path (SFP). Each
functions to perform and to which service function node to send the packet is marked as belonging to a specific SFP and that marking lets
packet next. each successive service function node know which functions to perform
and to which service function node to send the packet next.
To operate an SFC network the service function nodes must be To operate an SFC network the service function nodes must be
configured to understand the packet markings and the edge nodes must configured to understand the packet markings and the edge nodes must
be told how to mark packets entering the network. Additionally it be told how to mark packets entering the network. Additionally it
may be necessary to establish tunnels between service function nodes may be necessary to establish tunnels between service function nodes
to carry the traffic. to carry the traffic.
Planning an SFC network requires load balancing between service Planning an SFC network requires load balancing between service
function nodes and traffic engineering across the network that function nodes and traffic engineering across the network that
connects them. These are operations that can be performed by a PCE- connects them. These are operations that can be performed by a PCE-
skipping to change at page 15, line 19 skipping to change at page 15, line 22
3.2.2. Traffic Classification 3.2.2. Traffic Classification
Traffic classification is an important part of traffic engineering. Traffic classification is an important part of traffic engineering.
It is the process of looking at a packet to determine how it should It is the process of looking at a packet to determine how it should
be treated as it is forwarded through the network. It applies in be treated as it is forwarded through the network. It applies in
many scenarios including MPLS traffic engineering (where it many scenarios including MPLS traffic engineering (where it
determines what traffic is forwarded onto which LSPs), segment determines what traffic is forwarded onto which LSPs), segment
routing (where it is used to select which set of forwarding routing (where it is used to select which set of forwarding
instructions to add to a packet), and service function chaining instructions to add to a packet), and service function chaining
(where it indicates along which service function chain a packet (where it indicates along which service function path a packet should
should be forwarded). be forwarded). In conjunction with traffic engineering, traffic
classification is an important enabler for load balancing.
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
skipping to change at page 16, line 7 skipping to change at page 16, line 7
Delivering services over a network in an optimal way requires Delivering services over a network in an optimal way requires
coordination in the way that network resources are allocated to coordination in the way that network resources are allocated to
support the services. A PCE-based central controller can consider support the services. A PCE-based central controller can consider
the whole network and all components of a service at once when the whole network and all components of a service at once when
planning how to deliver the service. It can then use PCEP to manage planning how to deliver the service. It can then use PCEP to manage
the network resources and to install the necessary associations the network resources and to install the necessary associations
between those resources. between those resources.
4. Protocol Implications 4. Protocol Implications
PCEP is push-pull protocol that is designed to move requests and PCEP is a push-pull protocol that is designed to move requests and
responses between a server (the PCE) and Path Computation Clients responses between a server (the PCE) and clients (the PCCs, i.e., the
(PCCs - the network elements). In particular, it has a message network elements). In particular, it has a message (PCInitiate
(PCInitiate [I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the [I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the PCE to
PCE to install state or cause actions at the PCC, and a response install state or cause actions at the PCC, and a response message
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 small extensions controller. The only work expected to be needed is small extensions
to carry additional or specific information elements for the to carry additional or specific information elements for the
individual use cases. Where possible, consistent with the general individual use cases. Where possible, consistent with the general
principles of how protocols are extended, any additions to the principles of how protocols are extended, any additions to the
protocol should be made in a generic way such that they are open to protocol should be made in a generic way such that they are open to
use in a range of applications. use in a range of applications.
skipping to change at page 16, line 37 skipping to change at page 16, line 37
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
with out 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 However, debate will rage over overall system security and the
opportunity for attacks in an architecture with a central controller opportunity for attacks in an architecture with a central controller
since the network can be vulnerable to denial of service attacks on since the network can be vulnerable to denial of service attacks on
the controller, and the forwarding system may be harmed by attacks on the controller, and the forwarding system may be harmed by attacks on
the messages sent to individual routers. In short, while the the messages sent to individual NEs. In short, while the
interactions with a PCE-based controller are not substantially interactions with a PCE-based controller are not substantially
different from those in any other SDN architecture, the security different from those in any other SDN architecture, the security
implications of SDN are still open for discussion. The IRTF's SDN implications of SDN are still open for discussion. The IRTF's SDN
Research Group (SDNRG) continues to discuss this topic. Research Group (SDNRG) continues to discuss this topic.
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.
skipping to change at page 18, line 46 skipping to change at page 18, line 46
progress), July 2016. progress), July 2016.
[I-D.ietf-pce-pceps] [I-D.ietf-pce-pceps]
Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
Transport for PCEP", draft-ietf-pce-pceps-10 (work in Transport for PCEP", draft-ietf-pce-pceps-10 (work in
progress), July 2016. progress), July 2016.
[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-15 (work in progress), July 2016. pce-18 (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-09 (work in progress), July 2016. spring-segment-routing-10 (work in progress), November
2016.
[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., and C. Zhou, "PCEP Procedures
and Protocol Extensions for Using PCE as a Central and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs", draft-zhao-pce-pcep- Controller (PCECC) of LSPs", draft-zhao-pce-pcep-
extension-for-pce-controller-03 (work in progress), March extension-for-pce-controller-03 (work in progress), March
2016. 2016.
[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-01 (work in progress), July 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>. <http://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,
<http://www.rfc-editor.org/info/rfc3985>. <http://www.rfc-editor.org/info/rfc3985>.
skipping to change at page 20, line 52 skipping to change at page 20, line 52
[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,
<http://www.rfc-editor.org/info/rfc7665>. <http://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses Authors' Addresses
Adrian Farrel (editor) Adrian Farrel (editor)
Juniper Networks Juniper Networks
Email: adrian@olddog.co.uk Email: afarrel@juniper.net
Quintin Zhao (editor) Quintin Zhao (editor)
Huawei Technologies Huawei Technologies
125 Nagog Technology Park 125 Nagog Technology Park
Acton, MA 01719 Acton, MA 01719
USA USA
Email: quintin.zhao@huawei.com Email: quintin.zhao@huawei.com
Robin Li Robin Li
Huawei Technologies Huawei Technologies
 End of changes. 26 change blocks. 
69 lines changed or deleted 73 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/