< draft-ietf-teas-pce-central-control-02.txt		draft-ietf-teas-pce-central-control-03.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: November 15, 2017 R. Li		Expires: December 17, 2017 R. Li
	Huawei Technologies		Huawei Technologies
	C. Zhou		C. Zhou
	Cisco Systems		Cisco Systems
	May 14, 2017		June 15, 2017
	An Architecture for Use of PCE and PCEP in a Network with Central		An Architecture for Use of PCE and PCEP in a Network with Central
	Control		Control
	draft-ietf-teas-pce-central-control-02		draft-ietf-teas-pce-central-control-03
	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
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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. A PCE-based central controller can simplify the
	detail and does not define protocol extensions: that work is left for		processing of distributed control plane by blending it with elements
	other documents.		of SDN and without necessarily completely replacing it.
			This document does not describe use cases in detail and does not
			define protocol extensions: that work is left for other documents.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 15, 2017.		This Internet-Draft will expire on December 17, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 44 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 7		2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 7
	2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 8		2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 8
	2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 9		2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 9
	2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 10		2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12
	3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11		3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.1. Technology-Oriented Applicability . . . . . . . . . . . . 12		3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14
	3.1.1. Applicability to Control Plane Operated Networks . . 12		3.1.1. Applicability to Control Plane Operated Networks . . 14
	3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 12		3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14
	3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 13		3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15
	3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 13		3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15
	3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 13		3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15
	3.1.6. Service Function Chaining . . . . . . . . . . . . . . 14		3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16
	3.2. High-Level Applicability . . . . . . . . . . . . . . . . 14
	3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 14		3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16
	3.2.2. Traffic Classification . . . . . . . . . . . . . . . 15		3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16
	3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 15		3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17
	4. Protocol Implications / Guidance for Solution Developers . . 16		3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 16		4. Protocol Implications / Guidance for Solution Developers . . 18
	6. Manageability Considerations . . . . . . . . . . . . . . . . 17		5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		6. Manageability Considerations . . . . . . . . . . . . . . . . 19
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
	10.1. Normative References . . . . . . . . . . . . . . . . . . 18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.2. Informative References . . . . . . . . . . . . . . . . . 19		10.1. Normative References . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		10.2. Informative References . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	The Path Computation Element (PCE) [RFC4655] was developed to offload		The Path Computation Element (PCE) [RFC4655] was developed to offload
	path computation function from routers in an MPLS traffic engineered		path computation function from routers in an MPLS traffic engineered
	network. Since then, the role and function of the PCE has grown to		network. Since then, the role and function of the PCE has grown to
	cover a number of other uses (such as GMPLS [RFC7025]) and to allow		cover a number of other uses (such as GMPLS [RFC7025]) and to allow
	delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use		delegated control [I-D.ietf-pce-stateful-pce] and PCE-initiated use
	of network resources [I-D.ietf-pce-pce-initiated-lsp].		of network resources [I-D.ietf-pce-pce-initiated-lsp].
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 18 ¶
	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 does not describe the use cases in detail		protocol. A PCE-based central controller can simplify the processing
	and does not define protocol extensions: that work is left for other		of distributed control plane by blending it with elements of SDN and
	documents.		without necessarily completely replacing it.
			This document does not describe use cases in detail and does not
			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
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 32 ¶
	| 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
			of controlling all of the network elements. Thus the failure of any
			one controller will not leave the network unmanageable and, in normal
			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 elements
	thus the failure of any one controller will not leave the network		thus the failure of any one controller will not leave the network
	unmanageable and, in normal circumstances, the load can be		unmanageable and, in normal circumstances, the load can be
	distributed across the controllers.		distributed across the controllers. In this model, the orchestrator
			(or any requester) must select a controller to consume its request.
	To achieve full redundancy and to be able to continue to provide full
	function in the event of the failure a controller, the controllers
	must synchronize with each other. This is nominally a simple task 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
	there are more than two controllers, the synchronization between
	controllers can become a hard problem.
	Synchronization issues are often off-loaded as "database
	synchronization" problems because distributed database packages have
	already had to address these challenges. In networking the problem
	may also be addressed by collecting the state from the network
	(effectively using the network as a database) using normal routing
	protocols such as OSPF, IS-IS, and BGP.
	--------------------------------------------		--------------------------------------------
	| Orchestrator / Service Manager / OSS / NMS |		| Orchestrator / Service Manager / OSS / NMS |
	--------------------------------------------		--------------------------------------------
	^ ^		^ ^
	| ___________________ |		| ___________________ |
	| | Synchronization | |		| | Synchronization | |
	v v v v		v v v v
	------------ ------------		------------ ------------
	| | ----- | |		| | ----- | |
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 30 ¶
	| |__:___ \___:_ \_:___ :		| |__:___ \___:_ \_:___ :
	| ....: | .....: | ..: | :		| ....: | .....: | ..: | :
	| : | : | : | :		| : | : | : | :
	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"
			that represents itself externally as a single controller as in
			Figure 3 but which is actually comprised of multiple controllers.
			The size of the cluster may be varied according to load in the manner
			of network functions virtualization (NFV) and the cluster is
			responsible for sharing load among the members of the cluster. This
			approach is shown in Figure 6.
			--------------------------------------------
			| Orchestrator / Service Manager / OSS / NMS |
			--------------------------------------------
			^
			|
			--------------------------+-------------------------
			| Controller ______________|_____________ |
			| Cluster | | |
			| | ___________________ | |
			| | | Synchronization | | |
			| v v v v |
			| ------------ ----- ------------ |
			| | PCE-based |<---| TED |--->| PCE-based | |
			| | Controller | ----- | Controller | |
			| | Instance | | Instance | |
			| ------------ ------------ |
			| ^ ^ |
			| |____________________________| |
			| | |
			--------------------------+-------------------------
			_____________|_____________
			| | | |
			v v v v
			---- ---- ---- ----
			| NE | | NE | | NE | | NE |
			---- ---- ---- ----
			Figure 6: Multiple Controllers Presented as a Cluster
			To achieve full redundancy and to be able to continue to provide full
			function in the event of the failure a controller, the controllers
			must synchronize with each other. This is nominally a simple task 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
			there are more than two controllers, the synchronization between
			controllers can become a hard problem.
			Synchronization issues are often off-loaded as "database
			synchronization" problems because distributed database packages have
			already had to address these challenges, or by using a shared
			database. In networking the problem may also be addressed by
			collecting the state from the network (effectively using the network
			as a database) using normal routing protocols such as OSPF, IS-IS,
			and BGP.
	2.1.3. Hierarchical Controllers		2.1.3. Hierarchical Controllers
	Figure 6 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 "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.
	skipping to change at page 11, line 38 ¶		skipping to change at page 13, line 38 ¶
	/ | | :: | | \		/ | | :: | | \
	| | | :: | | |		| | | :: | | |
	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 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 discussion of the applicability
	of a PCE-based controller and it is expected that separate documents		of a PCE-based controller and it is expected that separate documents
	skipping to change at page 12, line 37 ¶		skipping to change at page 14, line 37 ¶
	determines what LSPs are needed and where to place them. PCEP is		determines what LSPs are needed and where to place them. PCEP is
	used to instruct the head end of each LSP, and the head end signals		used to instruct the head end of each LSP, and the head end signals
	in the control plane to set up the LSP.		in the control plane to set up the LSP.
	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 management plane or "manual"
	configuration.		configuration.
	Static LSPs can be provisioned as 1-hop, micro-LSPs at each node		Static LSPs can be provisioned as explicit label instructions at each
	along the path of an end-to-end path LSP. Each router along the path		hop on the end-to-end path LSP. Each router along the path must be
	must be told what label forwarding instructions to program and what		told what label forwarding instructions to program and what resources
	resources to reserve. The PCE-based controller keeps a view of the		to reserve. The PCE-based controller keeps a view of the network and
	network and determines the paths of the end-to-end LSPs just as it		determines the paths of the end-to-end LSPs just as it does for the
	does for the use case described in Section 3.1.1, but the controller		use case described in Section 3.1.1, but the controller uses PCEP to
	uses PCEP to communicate with each router along the path of the end-		communicate with each router along the path of the end-to-end LSP.
	to-end LSP. In this case the PCE-based controller will take		In this case the PCE-based controller will take responsibility for
	responsibility for managing some part of the MPLS label space for		managing some part of the MPLS label space for each of the routers
	each of the routers that it controls, and may taker wider		that it controls, and may taker wider responsibility for partitioning
	responsibility for partitioning the label space for each router and		the label space for each router and allocating different parts for
	allocating different parts for different uses communicating the		different uses communicating the ranges to the router using PCEP.
	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 in Section 3.1.1 and
	Section 3.1.2 except, of course, to note that the PCE must also		Section 3.1.2 except, of course, to note that the PCE must also
	include the instructions about where the LSP branches, i.e., where		include the instructions about where the LSP branches, i.e., where
	packets must be copied.		packets must be copied.
	3.1.4. Transport SDN		3.1.4. Transport SDN
	skipping to change at page 18, line 42 ¶		skipping to change at page 20, line 42 ¶
	involved for opening the discussion. The individuals concerned are:		involved for opening the discussion. The individuals concerned are:
	King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li.		King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, Zhenbin Li.
	This document has benefited from the discussions within a small ad		This document has benefited from the discussions within a small ad
	hoc design team the members of which are listed as document		hoc design team the members of which are listed as document
	contributors.		contributors.
	Thanks to Michael Scharf and Andy Malis for a lively discussion of		Thanks to Michael Scharf and Andy Malis for a lively discussion of
	this document.		this document.
			Thanks to Phil Bedard and Aijun Wang for last call comments on this
			document.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation		[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
	Element (PCE)-Based Architecture", RFC 4655,		Element (PCE)-Based Architecture", RFC 4655,
	DOI 10.17487/RFC4655, August 2006,		DOI 10.17487/RFC4655, August 2006,
	<http://www.rfc-editor.org/info/rfc4655>.		<http://www.rfc-editor.org/info/rfc4655>.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-pce-pce-initiated-lsp]		[I-D.ietf-pce-pce-initiated-lsp]
	Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP		Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
	Extensions for PCE-initiated LSP Setup in a Stateful PCE		Extensions for PCE-initiated LSP Setup in a Stateful PCE
	Model", draft-ietf-pce-pce-initiated-lsp-09 (work in		Model", draft-ietf-pce-pce-initiated-lsp-09 (work in
	progress), March 2017.		progress), March 2017.
	[I-D.ietf-pce-pceps]		[I-D.ietf-pce-pceps]
	Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure		Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
	Transport for PCEP", draft-ietf-pce-pceps-12 (work in		Transport for PCEP", draft-ietf-pce-pceps-14 (work in
	progress), April 2017.		progress), May 2017.
	[I-D.ietf-pce-stateful-pce]		[I-D.ietf-pce-stateful-pce]
	Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP		Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
	Extensions for Stateful PCE", draft-ietf-pce-stateful-		Extensions for Stateful PCE", draft-ietf-pce-stateful-
	pce-18 (work in progress), December 2016.		pce-19 (work in progress), May 2017.
	[I-D.ietf-pce-wson-rwa-ext]		[I-D.ietf-pce-wson-rwa-ext]
	Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing		Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing
	and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06		and Wavelength Assignment", draft-ietf-pce-wson-rwa-ext-06
	(work in progress), December 2016.		(work in progress), December 2016.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and R. Shakir, "Segment Routing Architecture", draft-ietf-		and R. Shakir, "Segment Routing Architecture", draft-ietf-
	spring-segment-routing-11 (work in progress), February		spring-segment-routing-11 (work in progress), February
End of changes. 16 change blocks.
	67 lines changed or deleted		120 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/