draft-ietf-teas-pce-central-control-05.txt		rfc8283.txt
	TEAS Working Group A. Farrel, Ed.		Internet Engineering Task Force (IETF) A. Farrel, Ed.
	Internet-Draft Juniper Networks		Request for Comments: 8283 Juniper Networks
	Intended status: Informational Q. Zhao, Ed.		Category: Informational Q. Zhao, Ed.
	Expires: March 8, 2018 R. Li		ISSN: 2070-1721 R. Li
	Huawei Technologies		Huawei Technologies
	C. Zhou		C. Zhou
	Cisco Systems		Cisco Systems
	September 4, 2017		December 2017
	An Architecture for Use of PCE and PCEP in a Network with Central		An Architecture for Use of PCE and the PCE Communication Protocol (PCEP)
	Control		in a Network with Central Control
	draft-ietf-teas-pce-central-control-05
	Abstract		Abstract
	The Path Computation Element (PCE) is a core component of Software		The Path Computation Element (PCE) is a core component of Software-
	Defined Networking (SDN) systems. It can compute optimal paths for		Defined Networking (SDN) systems. It can compute optimal paths for
	traffic across a network and can also update the paths to reflect		traffic across a network and can also update the paths to reflect
	changes in the network or traffic demands.		changes in the network or traffic demands.
	PCE was developed to derive paths for MPLS Label Switched Paths		PCE was developed to derive paths for MPLS Label Switched Paths
	(LSPs) supplying them to the head end of the LSP using the Path		(LSPs), which are supplied to the head end of the LSP using the Path
	Computation Element Communication Protocol (PCEP).		Computation Element Communication Protocol (PCEP).
	SDN has a broader applicability than signaled MPLS traffic engineered		SDN has a broader applicability than signaled MPLS traffic-engineered
	networks, and the PCE may be used to determine paths in a range of		(TE) networks, and the PCE may be used to determine paths in a range
	use cases including static LSPs, segment routing, service function		of use cases including static LSPs, segment routing, Service Function
	chaining, and most forms of routed or switched network. It is,		Chaining (SFC), and most forms of a routed or switched network. It
	therefore, reasonable to consider PCEP as a control protocol for use		is, therefore, reasonable to consider PCEP as a control protocol for
	in these environments to allow the PCE to be fully enabled as a		use in these environments to allow the PCE to be fully enabled as a
	central controller.		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 control protocol in this environment, and introduces the		PCEP as a control protocol in this environment, and introduces the
	implications for the protocol. A PCE-based central controller can		implications for the protocol. A PCE-based central controller can
	simplify the processing of distributed control plane by blending it		simplify the processing of a distributed control plane by blending it
	with elements 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 document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 7841.
	This Internet-Draft will expire on March 8, 2018.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8283.
	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		(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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 7		2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 8
	2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 8		2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 9
	2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 9		2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 10
	2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12		2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12
	3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13		3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14		3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14
	3.1.1. Applicability to Control Plane Operated Networks . . 14		3.1.1. Applicability to Control-Plane Operated Networks . . 14
	3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14		3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14
	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 . . . . . . . . . . . . . . . . . . . 19		5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	6. Manageability Considerations . . . . . . . . . . . . . . . . 19		6. Manageability Considerations . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		8.2. Informative References . . . . . . . . . . . . . . . . . 21
	10.1. Normative References . . . . . . . . . . . . . . . . . . 22		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
	10.2. Informative References . . . . . . . . . . . . . . . . . 22		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	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 [RFC8231] and PCE-initiated use of network
	of network resources [I-D.ietf-pce-pce-initiated-lsp].		resources [RFC8281].
	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		so that software running in a centralized system, called a
	controller, can act to program the devices in the network to behave		controller, can act to program the devices in the network to behave
	in specific ways. A required element in an SDN architecture is a		in specific ways. A required element in an SDN architecture is a
	component that plans how the network resources will be used and how		component that plans how the network resources will be used and how
	the devices will be programmed. It is possible to view this		the devices will be programmed. It is possible to view this
	component as performing specific computations to place traffic flows		component as performing specific computations to place traffic flows
	within the network given knowledge of the availability of network		within the network given knowledge of the availability of network
	resources, how other forwarding devices are programmed, and the way		resources, how other forwarding devices are programmed, and the way
	that other flows are routed. This is the function and purpose of a		that other flows are routed. This is the function and purpose of a
	PCE, and the way that a PCE integrates into a wider network control		PCE, and the way that a PCE integrates into a wider network control
	system (including an SDN system) is 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 (known as Path Computation Clients - PCCs) and the results		elements (known as Path Computation Clients (PCCs)), and the results
	of the path computations were supplied to network elements using the		of the path computations were supplied to network elements using the
	Path Computation Element Communication Protocol (PCEP) [RFC5440].		Path Computation Element Communication Protocol (PCEP) [RFC5440].
	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 [RFC8281].
	[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 [SR-ARCH], SFC [RFC7665], and indeed any
	service function chaining (SFC) [RFC7665], and indeed any form of		form of routed or switched network. It is, therefore, reasonable to
	routed or switched network. It is, therefore, reasonable to consider		consider PCEP as a general southbound control protocol (i.e., a
	PCEP as a general southbound control protocol (i.e., a control		control protocol for communicating from the central controller to
	protocol for communicating from the central controller to network		network elements) for use in these environments to allow the PCE to
	elements) for use in these environments to allow the PCE to be fully		be fully enabled as a central controller.
	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 as an extension of the architecture described in [RFC4655]		controller as an extension of the architecture described in [RFC4655]
	and assumes the continued use of PCEP as the protocol used between		and assumes the continued use of PCEP as the protocol used between
	PCE and PCC. The document also examines the motivations and		PCE and PCC. This document also examines the motivations and
	applicability for PCEP as a southbound interface and introduces the		applicability for PCEP as a Southbound Interface (SBI) and introduces
	implications for the protocol used in this way. A PCE-based central		the implications for the protocol used in this way. A PCE-based
	controller can simplify the processing of distributed control plane		central controller can simplify the processing of a distributed
	by blending it with elements of SDN and without necessarily		control plane by blending it with elements of SDN and without
	completely replacing it.		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
	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
	those who have read and understood [RFC4655] and		those who have read and understood [RFC4655] and [RFC8281].
	[I-D.ietf-pce-pce-initiated-lsp].
	In this mode of operation, the central controller is asked to create		In this mode of operation, the central controller is asked to create
	connectivity by a network orchestrator, a service manager, an		connectivity by a network orchestrator, a service manager, an
	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)		Note that other databases (such as an LSP Database (LSP-DB)) might
	might also be used, but for simplicity of illustration, just the TED		also be used, but for simplicity of illustration, just the TED is
	is shown.		shown.
	--------------------------------------------		--------------------------------------------
	| Orchestrator / Service Manager / OSS / NMS |		| Orchestrator / Service Manager / OSS / NMS |
	--------------------------------------------		--------------------------------------------
	^		^
	|		|
	v		v
	------------		------------
	| | -----		| | -----
	| PCE-based |<---| TED |		| PCE-Based |<---| TED |
	| Controller | -----		| Controller | -----
	| |		| |
	------------		------------
	^		^
	PCEP|		PCEP|
	v		v
	---- ---- ---- ----		---- ---- ---- ----
	| NE |<--------->| NE |<--->| NE |<--->| NE |		| NE |<--------->| NE |<--->| NE |<--->| NE |
	---- Signaling ---- ---- ----		---- Signaling ---- ---- ----
	Protocol		Protocol
	Figure 1: Architecture for Central Controller with Control Plane		Figure 1: Architecture for the Central Controller with
			a 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 a Southbound Interface (SBI) that provides an interface to each		using an SBI that provides an interface to each NE.
	NE.
	--------------------------------------------		--------------------------------------------
	| Orchestrator / Service Manager / OSS / NMS |		| Orchestrator / Service Manager / OSS / NMS |
	--------------------------------------------		--------------------------------------------
	^		^
	|		|
	v		v
	------------		------------
	| | -----		| | -----
	| PCE-based |<---| TED |		| PCE-Based |<---| TED |
	| Controller | -----		| Controller | -----
	| |		| |
	------------		------------
	^		^
	| PCEP		| PCEP
	v		v
	------------		------------
	| Network |		| Network |
	| Controller |		| Controller |
	/------------\		/------------\
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 47 ¶
	----/ ---- ---- \----		----/ ---- ---- \----
	| NE | | NE | | NE | | NE |		| NE | | NE | | NE | | NE |
	---- ---- ---- ----		---- ---- ---- ----
	Figure 2: Architecture Including a Network Controller		Figure 2: Architecture Including a Network Controller
	The approach in Figure 2 delivers the SDN functionality but is overly		The approach in Figure 2 delivers the SDN functionality but is overly
	complicated and insufficiently flexible.		complicated and insufficiently flexible.
	o The complication is created by the use of two controllers in a		o The complication is created by the use of two controllers in a
	hierarchical organization, and the resultant use of two protocols		hierarchical organization and the resultant use of two protocols
	in a southbound direction.		in a southbound direction.
	o The lack of flexibility arises from the assumed or required lack		o The lack of flexibility arises from the assumed or required lack
	of a control plane.		of a control plane.
	This document describes an architecture that reduces the number of		This document describes an architecture that reduces the number of
	components and is flexible to a number of deployment models and use		components and is flexible to a number of deployment models and use
	cases. In this hybrid approach (shown in Figure 3) the network		cases. In this hybrid approach (shown in Figure 3), the network
	controller is PCE-enabled and can also speak PCEP as the SBI (i.e.,		controller is PCE enabled and can also speak PCEP as the SBI (i.e.,
	it can communicate with each node along the path using PCEP). That		it can communicate with each node along the path using PCEP). That
	means that the controller can communicate with a conventional control		means that the controller can communicate with a conventional
	plane-enabled NE using PCEP and can also use the same protocol to		control-plane-enabled NE using PCEP and can also use the same
	program individual NEs. In this way the PCE-based controller can		protocol to program individual NEs. In this way, the PCE-based
	control a wider range of networks and deliver many different		controller can control a wider range of networks and deliver many
	functions as described in Section 3.		different 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
	------------		------------
	| | -----		| | -----
	| PCE-based |<---| TED |		| PCE-Based |<---| TED |
	| Controller | -----		| Controller | -----
	| |		| |
	/------------\		/------------\
	PCEP / ^ ^ \		PCEP / ^ ^ \
	/ | | \		/ | | \
	/ v v \		/ v v \
	/ ---- ---- \		/ ---- ---- \
	/ | NE | | NE | \		/ | NE | | NE | \
	----/ ---- ---- \----		----/ ---- ---- \----
	| NE | | NE |		| NE | | NE |
	skipping to change at page 7, line 48 ¶		skipping to change at page 8, line 10 ¶
	:......>| NE |...| NE |<....:		:......>| NE |...| NE |<....:
	Signaling Protocol ---- ----		Signaling Protocol ---- ----
	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 of the controller or overload of the controller. These		failure of the controller or overload of the controller. These
	concerns are not unique to the use of a PCE-based controller, but		concerns are not unique to the use of a PCE-based controller, but
	need to be addressed in this document before the PCE-based controller		they need to be addressed in this document before the PCE-based
	architecture can be considered for use in all but the smallest		controller architecture can be considered for use in all but the
	networks.		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 may use 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
	The first and simplest approach to handling controller overload or		The first and simplest approach to handling controller overload or
	scalability is to use multiple controllers, each responsible for a		scalability is to use multiple controllers, each responsible for a
	part of the network. We can call the resultant areas of control		part of the network. We can call the resultant areas of control
	"domains" [RFC4655].		"domains" [RFC4655].
	This approach is shown in Figure 4. It can clearly address some of		This approach is shown in Figure 4. It can clearly address some of
	the scaling and overload concerns since each controller now only has		the scaling and overload concerns since each controller now only has
	responsibility for a subset of the network elements. But this comes		responsibility for a subset of the network elements. But this comes
	at a cost because end-to-end connections require coordination between		at a cost because end-to-end connections require coordination between
	the controllers. Furthermore, this technique does not remove the		the controllers. Furthermore, this technique does not remove the
	single-point-of-failure concern even if it does reduce the impact on		concern about a single point-of-failure even if it does reduce the
	the network of the failure of a single controller.		impact on the network of the failure of a single controller.
	Note that PCEP is designed to work as a PCE-to-PCE protocol as well		Note that PCEP is designed to work as a PCE-to-PCE protocol as well
	as a PCE-to-PCC protocol, so it should be possible to use it to		as a PCE-to-PCC protocol, so it should be possible to use it to
	coordinate between PCE-based controllers in this model.		coordinate between PCE-based controllers in this model.
	--------------------------------------------		--------------------------------------------
	| Orchestrator / Service Manager / OSS / NMS |		| Orchestrator / Service Manager / OSS / NMS |
	--------------------------------------------		--------------------------------------------
	^ ^		^ ^
	| |		| |
	v v		v v
	------------ Coord- ------------		------------ Coordi- ------------
	----- | | ination | | -----		----- | | nation | | -----
	| 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
	2.1.2. Multiple Parallel Controllers		2.1.2. Multiple Parallel Controllers
	Multiple controllers may be deployed where each controller is capable		Multiple controllers may be deployed where each controller is capable
	of controlling all of the network elements. Thus the failure of any		of controlling all of the network elements. Thus, the failure of any
	one controller will not leave the network unmanageable and, in normal		one controller will not leave the network unmanageable and, in normal
	circumstances, the load can be distributed across the controllers.		circumstances, the load can be distributed across the controllers.
	Multiple parallel controllers may be deployed as shown in Figure 5.		Multiple parallel controllers may be deployed as shown in Figure 5.
	Each controller is capable of controlling all of the network elements		Each controller is capable of controlling all of the network
	thus the failure of any one controller will not leave the network		elements; thus, the failure of any one controller will not leave the
	unmanageable and, in normal circumstances, the load can be		network unmanageable, and in normal circumstances, the load can be
	distributed across the controllers. In this model, the orchestrator		distributed across the controllers. In this model, the orchestrator
	(or any requester) must select a controller to consume its request.		(or any requester) must select a controller to consume its request.
	--------------------------------------------		--------------------------------------------
	| Orchestrator / Service Manager / OSS / NMS |		| Orchestrator / Service Manager / OSS / NMS |
	--------------------------------------------		--------------------------------------------
	^ ^		^ ^
	| ___________________ |		| ___________________ |
	| | Synchronization | |		| | Synchronization | |
	v v v v		v v v v
	------------ ------------		------------ ------------
	| | ----- | |		| | ----- | |
	| 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
	An alternate approach is to present the controllers as a "cluster"		An alternate approach is to present the controllers as a "cluster"
	that represents itself externally as a single controller as in		that represents itself externally as a single controller as in
	Figure 3 but which is actually comprised of multiple controllers.		Figure 3 but that is actually comprised of multiple controllers. The
	The size of the cluster may be varied according to load in the manner		size of the cluster may be varied according to the load in the manner
	of network functions virtualization (NFV) and the cluster is		of Network Functions Virtualization (NFV), and the cluster is
	responsible for sharing load among the members of the cluster. This		responsible for sharing load among the members of the cluster. This
	approach is shown in Figure 6.		approach is shown in Figure 6.
	--------------------------------------------		--------------------------------------------
	| Orchestrator / Service Manager / OSS / NMS |		| Orchestrator / Service Manager / OSS / NMS |
	--------------------------------------------		--------------------------------------------
	^		^
	|		|
	--------------------------+-------------------------		--------------------------+-------------------------
	| Controller ______________|_____________ |		| Controller ______________|_____________ |
	| Cluster | | |		| Cluster | | |
	| | ___________________ | |		| | ___________________ | |
	| | | Synchronization | | |		| | | Synchronization | | |
	| v v v v |		| v v v v |
	| ------------ ----- ------------ |		| ------------ ----- ------------ |
	| | PCE-based |<---| TED |--->| PCE-based | |		| | PCE-Based |<---| TED |--->| PCE-Based | |
	| | Controller | ----- | Controller | |		| | Controller | ----- | Controller | |
	| | Instance | | Instance | |		| | Instance | | Instance | |
	| ------------ ------------ |		| ------------ ------------ |
	| ^ ^ |		| ^ ^ |
	| |____________________________| |		| |____________________________| |
	| | |		| | |
	--------------------------+-------------------------		--------------------------+-------------------------
	_____________|_____________		_____________|_____________
	| | | |		| | | |
	v v v v		v v v v
	---- ---- ---- ----		---- ---- ---- ----
	| NE | | NE | | NE | | NE |		| NE | | NE | | NE | | NE |
	---- ---- ---- ----		---- ---- ---- ----
	Figure 6: Multiple Controllers Presented as a Cluster		Figure 6: Multiple Controllers Presented as a Cluster
	To achieve full redundancy and to be able to continue to provide full		To achieve full redundancy and to be able to continue to provide full
	function in the event of the failure a controller, the controllers		function in the event of a controller failure, the controllers must
	must synchronize with each other. This is nominally a simple task if		synchronize with each other. This is nominally a simple task if
	there are just two controllers, but can actually be quite complex if		there are just two controllers but can actually be quite complex if
	state changes in the network are not to be lost. Furthermore, if		state changes in the network are not to be lost. Furthermore, if
	there are more than two controllers, the synchronization between		there are more than two controllers, the synchronization between
	controllers can become a hard problem.		controllers can become a hard problem.
	Synchronization issues are often off-loaded as "database		Synchronization issues are often off-loaded as "database
	synchronization" problems because distributed database packages have		synchronization" problems, because distributed database packages have
	already had to address these challenges, or by using a shared		already had to address these challenges, or by using a shared
	database. In networking the problem may also be addressed by		database. In networking, the problem may also be addressed by
	collecting the state from the network (effectively using the network		collecting the state from the network (effectively using the network
	as a database) using normal routing protocols such as OSPF, IS-IS,		as a database) using normal routing protocols such as OSPF, IS-IS,
	and BGP. It should be noted that addressing the synchronization		and BGP. It should be noted that addressing the synchronization
	problem through a shared database may be hiding the issues of		problem through a shared database may be hiding the issues of
	congestion and of a single point of failure: whole the controllers		congestion and of a single point of failure: while the controllers
	may have been made resilient by allowing redundancy, the shared		may have been made resilient by allowing redundancy, the shared
	database is still a problem and so the whole system is still		database is still a problem, so the whole system is still vulnerable.
	vulnerable.
	2.1.3. Hierarchical Controllers		2.1.3. Hierarchical Controllers
	Figure 7 shows an approach with hierarchical controllers. This		Figure 7 shows an approach with hierarchical controllers. This
	approach was developed for PCEs in [RFC6805] and appears in various		approach was developed for PCEs in [RFC6805] and appears in various
	SDN architectures where a "parent PCE", an "orchestrator", or "super		SDN architectures where a "parent PCE", an "orchestrator", or a
	controller" takes responsibility for a high-level view of the network		"super controller" takes responsibility for a high-level view of the
	before distributing tasks to lower level PCEs or controllers.		network 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 a PCE-based		Note that this model can be arbitrarily recursive with a PCE-based
	controller being the child of one parent PCE-based controller while		controller being the child of one parent PCE-based controller while
	acting as the parent of another set of PCE-based 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 |
	skipping to change at page 13, line 47 ¶		skipping to change at page 13, line 47 ¶
	Figure 7: Hierarchical Controllers		Figure 7: Hierarchical Controllers
	3. Applicability		3. Applicability
	This section gives a very high-level introduction to the		This section gives a very high-level introduction to the
	applicability of a PCE-based centralized controller. There is no		applicability of a PCE-based centralized controller. There is no
	attempt to explain each use case in detail, and the inclusion of a		attempt to explain each use case in detail, and the inclusion of a
	use case is not intended to suggest that deploying a PCE-based		use case is not intended to suggest that deploying a PCE-based
	controller is a mandatory or recommended approach. The sections		controller is a mandatory or recommended approach. The sections
	below are provided as a stimulus to discussion of the applicability		below are provided as a stimulus to the discussion of the
	of a PCE-based controller and it is expected that separate documents		applicability of a PCE-based controller, and it is expected that
	will be written to develop the use cases in which there is interest		separate documents will be written to develop the use cases in which
	for implementation and deployment. As described in Section 4		there is interest for implementation and deployment. As described in
	specific enhancements to PCEP may be needed for some of these use		Section 4, specific enhancements to PCEP may be needed for some of
	cases and it is expected that the documents that develop each use		these use cases, and it is expected that the documents that develop
	case will also address any extensions to PCEP.		each use case will also address any extensions to PCEP.
	The rest of this section is divided into two sub-sections. The first		The rest of this section is divided into two sub-sections. The first
	approaches the question of applicability from a consideration of the		approaches the question of applicability from a consideration of the
	network technology. The second looks at the high-level functions		network technology. The second looks at the high-level functions
	that can be delivered by using a PCE-based controller.		that can be delivered by using a PCE-based controller.
	As previously mentioned, this section is intended to just make		As previously mentioned, this section is intended to just make
	suggestions. Thus the material supplied is very brief. The omission		suggestions. Thus, the material supplied is very brief. The
	of a use case is in no way meant to imply some limit on the		omission of a use case is in no way meant to imply some limit on the
	applicability of PCE-based control.		applicability of PCE-based control.
	3.1. Technology-Oriented Applicability		3.1. Technology-Oriented Applicability
	This section provides a list of use cases based on network		This section provides a list of use cases based on network
	technology.		technology.
	3.1.1. Applicability to Control Plane Operated Networks		3.1.1. Applicability to Control-Plane Operated Networks
	This mode of operation is the common approach for an active, stateful		This mode of operation is the common approach for an active, stateful
	PCE to control a traffic engineered MPLS or GMPLS network		PCE to control a traffic-engineered MPLS or GMPLS network [RFC8231].
	[I-D.ietf-pce-stateful-pce]. Note that the PCE-based controller		Note that the PCE-based controller determines what LSPs are needed
	determines what LSPs are needed and where to place them. PCEP is		and where to place them. PCEP is used to instruct the head end of
	used to instruct the head end of each LSP, and the head end signals		each LSP, and the head end signals in the control plane to set up the
	in the control plane to set up the LSP.		LSP.
	In this mode of operation, the PCE may construct its TED in a number		In this mode of operation, the PCE may construct its TED in a number
	of ways as described in [RFC4655] including (but not limited to)		of ways as described in [RFC4655], including (but not limited to)
	participating in the IGP or receiving information from a network		participating in the IGP or receiving information from a network
	element via BGP-LS [RFC7752].		element via BGP-LS [RFC7752].
	3.1.2. Static LSPs in MPLS		3.1.2. Static LSPs in MPLS
	Static LSPs are provisioned without the use of a control plane. This		Static LSPs are provisioned without the use of a control plane. This
	means that they are established using management plane or "manual"		means that they are established using a management plane or "manual"
	configuration.		configuration.
	Static LSPs can be provisioned as explicit label instructions at each		Static LSPs can be provisioned as explicit label instructions at each
	hop on the end-to-end path LSP. Each router along the path must be		hop on the end-to-end path LSP. Each router along the path must be
	told what label forwarding instructions to program and what resources		told what label-forwarding instructions to program and what resources
	to reserve. The PCE-based controller keeps a view of the network and		to reserve. The PCE-based controller keeps a view of the network and
	determines the paths of the end-to-end LSPs just as it does for the		determines the paths of the end-to-end LSPs just as it does for the
	use case described in Section 3.1.1, but the controller uses PCEP to		use case described in Section 3.1.1, but the controller uses PCEP to
	communicate with each router along the path of the end-to-end LSP.		communicate with each router along the path of the end-to-end LSP.
	In this case the PCE-based controller will take responsibility for		In this case, the PCE-based controller will take responsibility for
	managing some part of the MPLS label space for each of the routers		managing some part of the MPLS label space for each of the routers
	that it controls, and may taker wider responsibility for partitioning		that it controls, and it may taker wider responsibility for
	the label space for each router and allocating different parts for		partitioning the label space for each router and allocating different
	different uses communicating the ranges to the router using PCEP.		parts for different uses, communicating the ranges to the router
			using PCEP.
	3.1.3. MPLS Multicast		3.1.3. MPLS Multicast
	Multicast LSPs may be provisioned with a control plane or as static		Multicast LSPs may be provisioned with a control plane or as static
	LSPs. No extra considerations apply above those in Section 3.1.1 and		LSPs. No extra considerations apply above those described in
	Section 3.1.2 except, of course, to note that the PCE must also		Sections 3.1.1 and 3.1.2 except, of course, to note that the PCE must
	include the instructions about where the LSP branches, i.e., where		also include the instructions about where the LSP branches, i.e.,
	packets must be copied.		where packets must be copied.
	3.1.4. Transport SDN		3.1.4. Transport SDN
	Transport SDN (T-SDN) is the application of SDN techniques to		Transport SDN (T-SDN) is the application of SDN techniques to
	transport networks. In this respect a transport network is a network		transport networks. In this respect, a transport network is a
	built from any technology below the IP layer and designed to carry		network built from any technology below the IP layer and designed to
	traffic transparently in a connection-oriented way. Thus, an MPLS		carry traffic transparently in a connection-oriented way. Thus, an
	traffic engineering network is a transport network although it is		MPLS traffic-engineered network is a transport network, although it
	more common to consider technologies such as Time Division		is more common to consider technologies such as Time Division
	Multiplexing (TDM) and Optical Transport Networks (OTN).		Multiplexing (TDM) and Optical Transport Networks (OTNs) to be
			transport networks.
	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 Sections 3.1.1, 3.1.2, and 3.1.3
	Section 3.1.3 apply so that the normal PCEP message allow a PCE-based		apply so that the normal PCEP message allows a PCE-based central
	central controller to provision a transport network. It is usually		controller to provision a transport network. It is usually the case
	the case that additional technology-specific parameters are needed to		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, such as optical
	optical characteristic. Such parameters will need to be carried in		characteristic. Such parameters will need to be carried in the PCEP
	the PCEP messages: new protocol extensions may be needed, as		messages: new protocol extensions may be needed, as described, for
	described, for example,in [I-D.ietf-pce-wson-rwa-ext].		example, in [PCEP-WSON-RWA].
	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 [SR-ARCH]. It relies on a series of
	It relies on a series of forwarding instructions being placed in the		forwarding instructions being placed in the header of a packet. At
	header of a packet. At each hop in the network a router looks at the		each hop in the network, a router looks at the first instruction and
	first instruction and may: continue to forward the packet unchanged;		may: continue to forward the packet unchanged; strip the top
	strip the top instruction and forward the packet; or strip the top		instruction and forward the packet; or strip the top instruction,
	instruction, insert some additional instructions, and forward the		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, configuring
	configuring the forwarding actions on the routers, and for telling		the forwarding actions on the routers, and telling the edge routers
	the edge routers what instructions to attach to packets as they enter		what instructions to attach to packets as they enter the network.
	the network. These last two operations can be achieved using PCEP		These last two operations can be achieved using PCEP, and the
	and the PCE-based controller will assume responsibility for managing		PCE-based controller will assume responsibility for managing the
	the space of labels or path identifiers used to determine how packets		space of labels or path identifiers used to determine how packets are
	are forwarded.		forwarded.
	3.1.6. Service Function Chaining		3.1.6. Service Function Chaining
	Service Function Chaining (SFC) is described in [RFC7665]. It is the		SFC is described in [RFC7665]. It is the process of directing
	process of directing traffic in a network such that it passes through		traffic in a network such that it passes through specific hardware
	specific hardware devices or virtual machines (known as service		devices or virtual machines (known as service function nodes) that
	function nodes) that can perform particular desired functions on the		can perform particular desired functions on the traffic. The set of
	traffic. The set of functions to be performed and the order in which		functions to be performed and the order in which they are to be
	they are to be performed is known as a Service Function Chain. The		performed is known as a service function chain. The chain is
	chain is enhanced with the locations at which the service functions		enhanced with the locations at which the service functions are to be
	are to be performed to derive a Service Function Path (SFP). Each		performed to derive a Service Function Path (SFP). Each packet is
	packet is marked as belonging to a specific SFP and that marking lets		marked as belonging to a specific SFP, and that marking lets each
	each successive service function node know which functions to perform		successive service function node know which functions to perform and
	and to which service function node to send the packet next.		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
	based controller, and that controller can use PCEP to program the		PCE-based controller, and that controller can use PCEP to program the
	network and install the service function chains and any required		network and install the service function chains and any required
	tunnels.		tunnels.
	3.2. High-Level Applicability		3.2. High-Level Applicability
	This section provides a list of the high-level functions that can be		This section provides a list of the high-level functions that can be
	delivered by using a PCE-based controller.		delivered by using a PCE-based controller.
	3.2.1. Traffic Engineering		3.2.1. Traffic Engineering
	According to [RFC2702], Traffic Engineering (TE) is concerned with		According to [RFC2702], TE is concerned with performance optimization
	performance optimization of operational networks. In general, it		of operational networks. In general, it encompasses the application
	encompasses the application of technology and scientific principles		of technology and scientific principles to the measurement, modeling,
	to the measurement, modeling, characterization, control of Internet		characterization, control of Internet traffic, and application of
	traffic, and the application of such knowledge and techniques to		such knowledge and techniques to achieve specific performance
	achieve specific performance objectives.		objectives.
	From a practical point of view this involves having an understanding		From a practical point of view, this involves having an understanding
	of the topology of the network, the characteristics of the nodes and		of the topology of the network, the characteristics of the nodes and
	links in the network, and the traffic demands and flows across the		links in the network, and the traffic demands and flows across the
	network. It also requires that actions can be taken to ensure that		network. It also requires that actions can be taken to ensure that
	traffic follows specific paths through the network.		traffic follows specific paths through the network.
	PCE was specifically developed to address TE in an MPLS network, and		PCE was specifically developed to address TE in an MPLS network, so a
	so a PCE-based controller is well suited to analyze TE problems and		PCE-based controller is well suited to analyze TE problems and supply
	supply answers that can be installed in the network using PCEP. PCEP		answers that can be installed in the network using PCEP. PCEP can be
	can be responsible for initiating paths across the network through a		responsible for initiating paths across the network through a control
	control plane, or for installing state in the network node by node		plane or for installing state in the network node by node such as in
	such as in a Segment Routed network (see Section 3.1.5) or by		a segment-routed network (see Section 3.1.5) or by configuring IGP
	configuring IGP metrics.		metrics.
	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 SFC (where it indicates along
	(where it indicates along which service function path a packet should		which service function path a packet should be forwarded). In
	be forwarded). In conjunction with traffic engineering, traffic		conjunction with traffic engineering, traffic classification is an
	classification is an important enabler for load balancing.		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
	based controller.		PCE-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.		paths or connections.
	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) services (such as Layer 3 VPNs
	or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985].		[RFC4364] 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
	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 / Guidance for Solution Developers		4. Protocol Implications / Guidance for Solution Developers
	PCEP is a 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 clients (the PCCs, i.e., the		responses between a server (the PCE) and clients (the PCCs, i.e., the
	network elements). In particular, it has a message (PCInitiate		network elements). In particular, it has a message (the LSP Initiate
	[I-D.ietf-pce-pce-initiated-lsp]) that can be sent by the PCE to		Request (PCInitiate); see [RFC8281]) 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.		(Path Computation State Report (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. [RFC5440]		compatibility and do not impact existing PCEP deployments. [RFC5440]
	already describes how legacy implementations handle unknown protocol		already describes how legacy implementations handle unknown protocol
	extensions and how to use the PCEP Open message to indicate support		extensions and how to use the PCEP Open message to indicate support
	for PCEP features. Where possible, consistent with the general		for PCEP features. 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.
	It is anticipated that new documents (such as		It is anticipated that new documents (such as [PCEP-CONTROLLER]) will
	[I-D.zhao-pce-pcep-extension-for-pce-controller]) will be produced		be produced for each use case dependent on support and demand. Such
	for each use case dependent on support and demand. Such documents		documents will explain the use case and define the necessary protocol
	will explain the use case and define the necessary protocol
	extensions.		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.		testing can be limited to the specific profiles.
	Note that protocol mechanisms to handle synchronization of state in		Note that protocol mechanisms to handle synchronization of state in
	parallel PCE-based controllers will also be required if parallel		parallel PCE-based controllers will also be required if parallel
	controllers are used as described in Section 2.1.2. There is a		controllers are used as described in Section 2.1.2. In [RFC8231],
	discussion of mechanisms to achieve PCE state synchronization in		there is a discussion of mechanisms to achieve PCE state
	[I-D.ietf-pce-stateful-pce].		synchronization.
	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, 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 [RFC8253].
	[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.		so it is more likely to be operated with a high level of security.
	However, an architecture with a central controller has a central		However, an architecture with a central controller has a central
	point of failure and this is also a security weakness since the		point of failure, and this is also a security weakness since the
	network can be vulnerable to denial of service attacks on the		network can be vulnerable to denial-of-service attacks on the
	controller. Similarly, the central controller provides a focus for		controller. Similarly, the central controller provides a focus for
	interception and modification of messages sent to individual NEs. In		interception and modification of messages sent to individual NEs. In
	short, while the interactions with a PCE-based controller are not		short, while the interactions with a PCE-based controller are not
	substantially different to those in any other SDN architecture, the		substantially different to those in any other SDN architecture, the
	security implications of SDN have not been fully discussed or		security implications of SDN have not been fully discussed or
	described. Therefore, protocol and applicability work around		described. Therefore, protocol and applicability work-around
	solutions for this architecture must take proper account of these		solutions for this architecture must take proper account of these
	concerns.		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 control protocol (PCEP).
	An implementation of a PCE-based controller will require access to		An implementation of a PCE-based controller will require access to
	information about the state of the network, its nodes, and its links.		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		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		collected using the mechanisms already in place (such as listening to
	the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-		the IGPs, using BGP-LS [RFC7752], or northbound export of
	encoded data [I-D.ietf-teas-yang-te-topo] from the network elements		YANG-encoded data [YANG-TE] from the network elements to the
	to the controller). More information may be collected in the LSP		controller). More information may be collected in the LSP database
	database as described for stateful PCEs as described in [RFC7399] and		for stateful PCEs as described in [RFC7399] and [RFC8231].
	[I-D.ietf-pce-stateful-pce]. Additional information may be needed		Additional information may be needed for other specific use cases and
	for other specific use cases and will need to be collected and passed		will need to be collected and passed to the controller. This may
	to the controller. This may require protocol extensions for the		require protocol extensions for the mechanisms listed in this
	mechanisms listed in this paragraph.		paragraph.
	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		[RFC5440] contains a substantive Manageability Considerations section
	considerations section that examines how a PCE-based system and a		that examines how a PCE-based system and a PCE-enabled system may be
	PCE-enabled system may be managed. A MIB module for PCEP was		managed. A MIB module for PCEP was published as [RFC7420], and a
	published as RFC 7420 [RFC7420] and a YANG module for PCEP has also		YANG module for PCEP has also been proposed [YANG-PCEP].
	been proposed [I-D.pkd-pce-pcep-yang].
	7. IANA Considerations		7. IANA Considerations
	This document makes no requests for IANA action.		This document does not require any IANA actions.
	8. Contributors
	The following people contributed to discussions that led to the
	development of this document:
	Cyril Margaria
	Email: cmargaria@juniper.net
	Sudhir Cheruathur
	Email: scheruathur@juniper.net
	Dhruv Dhody
	Email: dhruv.dhody@huawei.com
	Daniel King
	Email: daniel@olddog.co.uk
	Iftekhar Hussain
	Email: IHussain@infinera.com
	Anurag Sharma
	Email: AnSharma@infinera.com
	Eric Wu
	Email: eric.wu@huawei.com
	9. Acknowledgements
	The ideas in this document owe a lot to the work started by the
	authors of [I-D.zhao-teas-pcecc-use-cases] and
	[I-D.zhao-pce-pcep-extension-for-pce-controller]. The authors of
	this document fully acknowledge the prior work and thank those
	involved for opening the discussion. The individuals concerned are:
	King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li.
	This document has benefited from the discussions within a small ad
	hoc design team the members of which are listed as document
	contributors.
	Thanks to Michael Scharf and Andy Malis for a lively discussion of
	this document.
	Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call
	comments on this document.
	Spencer Dawkins, Adam Roach, and Ben Campbell provided helpful
	comments during IESG review.
	10. References
	10.1. Normative References		8. References
	[I-D.ietf-pce-pce-initiated-lsp]		8.1. Normative 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-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, <https://www.rfc-		DOI 10.17487/RFC4655, August 2006,
	editor.org/info/rfc4655>.		<https://www.rfc-editor.org/info/rfc4655>.
	[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation		[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,		Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009, <https://www.rfc-		DOI 10.17487/RFC5440, March 2009,
	editor.org/info/rfc5440>.		<https://www.rfc-editor.org/info/rfc5440>.
	10.2. Informative References
	[I-D.ietf-pce-pceps]
	Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
	Transport for PCEP", draft-ietf-pce-pceps-16 (work in
	progress), August 2017.
	[I-D.ietf-pce-stateful-pce]
	Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
	Extensions for Stateful PCE", draft-ietf-pce-stateful-
	pce-21 (work in progress), June 2017.
	[I-D.ietf-pce-wson-rwa-ext]
	Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing
	and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06
	(work in progress), December 2016.
	[I-D.ietf-spring-segment-routing]		[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,		Computation Element Communication Protocol (PCEP)
	and R. Shakir, "Segment Routing Architecture", draft-ietf-		Extensions for PCE-Initiated LSP Setup in a Stateful PCE
	spring-segment-routing-12 (work in progress), June 2017.		Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
			<https://www.rfc-editor.org/info/rfc8281>.
	[I-D.ietf-teas-yang-te-topo]		8.2. Informative References
	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]		[PCECC] Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou,
	Dhody, D., Hardwick, J., Beeram, V., and j.		C., Communications, T., Rachitskiy, A., and A. Gulida,
	jefftant@gmail.com, "A YANG Data Model for Path		"The Use Cases for Using PCE as the Central
	Computation Element Communications Protocol (PCEP)",		Controller(PCECC) of LSPs", Work in Progress,
	draft-pkd-pce-pcep-yang-06 (work in progress), July 2016.		draft-zhao-teas-pcecc-use-cases-02, October 2016.
	[I-D.zhao-pce-pcep-extension-for-pce-controller]		[PCEP-CONTROLLER]
	Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A.,		Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A.,
	and C. Zhou, "PCEP Procedures and Protocol Extensions for		and C. Zhou, "PCEP Procedures and Protocol Extensions for
	Using PCE as a Central Controller (PCECC) of LSPs", draft-		Using PCE as a Central Controller (PCECC) of LSPs", Work
	zhao-pce-pcep-extension-for-pce-controller-05 (work in		in Progress, draft-zhao-pce-pcep-extension-for-pce-
	progress), June 2017.		controller-06, October 2017.
	[I-D.zhao-teas-pcecc-use-cases]		[PCEP-WSON-RWA]
	Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou,		Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing
	C., Communications, T., Rachitskiy, A., and A. Gulida,		and Wavelength Assignment", Work in Progress,
	"The Use Cases for Using PCE as the Central		draft-ietf-pce-wson-rwa-ext-07, November 2017.
	Controller(PCECC) of LSPs", draft-zhao-teas-pcecc-use-
	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,
	<https://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, <https://www.rfc-		DOI 10.17487/RFC3985, March 2005,
	editor.org/info/rfc3985>.		<https://www.rfc-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, <https://www.rfc-		DOI 10.17487/RFC4090, May 2005,
	editor.org/info/rfc4090>.		<https://www.rfc-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, <https://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, <https://www.rfc-		DOI 10.17487/RFC4427, March 2006,
	editor.org/info/rfc4427>.		<https://www.rfc-editor.org/info/rfc4427>.
	[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, <https://www.rfc-		DOI 10.17487/RFC6805, November 2012,
	editor.org/info/rfc6805>.		<https://www.rfc-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,
	<https://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, <https://www.rfc-		DOI 10.17487/RFC7399, October 2014,
	editor.org/info/rfc7399>.		<https://www.rfc-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,
	<https://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, <https://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, <https://www.rfc-		DOI 10.17487/RFC7491, March 2015,
	editor.org/info/rfc7491>.		<https://www.rfc-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, <https://www.rfc-		DOI 10.17487/RFC7665, October 2015,
	editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
	[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
	S. Ray, "North-Bound Distribution of Link-State and		S. Ray, "North-Bound Distribution of Link-State and
	Traffic Engineering (TE) Information Using BGP", RFC 7752,		Traffic Engineering (TE) Information Using BGP", RFC 7752,
	DOI 10.17487/RFC7752, March 2016, <https://www.rfc-		DOI 10.17487/RFC7752, March 2016,
	editor.org/info/rfc7752>.		<https://www.rfc-editor.org/info/rfc7752>.
			[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
			Computation Element Communication Protocol (PCEP)
			Extensions for Stateful PCE", RFC 8231,
			DOI 10.17487/RFC8231, September 2017,
			<https://www.rfc-editor.org/info/rfc8231>.
			[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
			"PCEPS: Usage of TLS to Provide a Secure Transport for the
			Path Computation Element Communication Protocol (PCEP)",
			RFC 8253, DOI 10.17487/RFC8253, October 2017,
			<https://www.rfc-editor.org/info/rfc8253>.
			[SR-ARCH] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
			Litkowski, S., and R. Shakir, "Segment Routing
			Architecture", Work in Progress, draft-ietf-spring-
			segment-routing-13, October 2017.
			[YANG-PCEP]
			Dhody, D., Hardwick, J., Beeram, V., and j.
			jefftant@gmail.com, "A YANG Data Model for Path
			Computation Element Communications Protocol (PCEP)", Work
			in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
			[YANG-TE] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
			O. Dios, "YANG Data Model for Traffic Engineering (TE)
			Topologies", Work in Progress, draft-ietf-teas-yang-te-
			topo-13, October 2017.
			Acknowledgments
			The ideas in this document owe a lot to the work started by the
			authors of [PCECC] and [PCEP-CONTROLLER]. The authors of this
			document fully acknowledge the prior work and thank those involved
			for opening the discussion. The individuals concerned are: King Ke,
			Luyuan Fang, Chao Zhou, Boris Zhang, and Zhenbin Li.
			This document has benefited from the discussions within a small ad
			hoc design team; the members of which are listed as document
			contributors.
			Thanks to Michael Scharf and Andy Malis for a lively discussion of
			this document.
			Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call
			comments on this document.
			Spencer Dawkins, Adam Roach, and Ben Campbell provided helpful
			comments during IESG review.
			Contributors
			The following people contributed to discussions that led to the
			development of this document:
			Cyril Margaria
			Email: cmargaria@juniper.net
			Sudhir Cheruathur
			Email: scheruathur@juniper.net
			Dhruv Dhody
			Email: dhruv.dhody@huawei.com
			Daniel King
			Email: daniel@olddog.co.uk
			Iftekhar Hussain
			Email: IHussain@infinera.com
			Anurag Sharma
			Email: AnSharma@infinera.com
			Eric Wu
			Email: eric.wu@huawei.com
	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
	125 Nagog Technology Park		125 Nagog Technology Park
	Acton, MA 01719		Acton, MA 01719
	USA		United States of America
	Email: quintin.zhao@huawei.com		Email: quintin.zhao@huawei.com
	Robin Li		Robin Li
	Huawei Technologies		Huawei Technologies
	Huawei Bld., No.156 Beiqing Road		Huawei Bld., No.156 Beiqing Road
	Beijing 100095		Beijing 100095
	China		China
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
End of changes. 110 change blocks.
	383 lines changed or deleted		377 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/