< draft-ietf-pce-stateful-pce-07.txt		draft-ietf-pce-stateful-pce-08.txt >
	PCE Working Group E. Crabbe		PCE Working Group E. Crabbe
	Internet-Draft Google, Inc.		Internet-Draft Google, Inc.
	Intended status: Standards Track J. Medved		Intended status: Standards Track J. Medved
	Expires: April 11, 2014 Cisco Systems, Inc.		Expires: August 16, 2014 Cisco Systems, Inc.
	I. Minei		I. Minei
	Juniper Networks, Inc.		Google, Inc.
	R. Varga		R. Varga
	Pantheon Technologies SRO		Pantheon Technologies SRO
	October 8, 2013		February 12, 2014
	PCEP Extensions for Stateful PCE		PCEP Extensions for Stateful PCE
	draft-ietf-pce-stateful-pce-07		draft-ietf-pce-stateful-pce-08
	Abstract		Abstract
	The Path Computation Element Communication Protocol (PCEP) provides		The Path Computation Element Communication Protocol (PCEP) provides
	mechanisms for Path Computation Elements (PCEs) to perform path		mechanisms for Path Computation Elements (PCEs) to perform path
	computations in response to Path Computation Clients (PCCs) requests.		computations in response to Path Computation Clients (PCCs) requests.
	Although PCEP explicitly makes no assumptions regarding the		Although PCEP explicitly makes no assumptions regarding the
	information available to the PCE, it also makes no provisions for		information available to the PCE, it also makes no provisions for PCE
	synchronization or PCE control of timing and sequence of path		control of timing and sequence of path computations within and across
	computations within and across PCEP sessions. This document		PCEP sessions. This document describes a set of extensions to PCEP
	describes a set of extensions to PCEP to enable stateful control of		to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.
	MPLS-TE and GMPLS LSPs via PCEP.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	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
	skipping to change at page 2, line 4 ¶		skipping to change at page 1, line 48 ¶
	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 April 11, 2014.
			This Internet-Draft will expire on August 16, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 7		3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 5
	3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7		3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 6
	3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7		3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6
	3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 8		3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 7
	3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 9		4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 8
	5. Architectural Overview of Protocol Extensions . . . . . . . . 10		5. Architectural Overview of Protocol Extensions . . . . . . . . 9
	5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 10		5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9
	5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 11		5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Capability Advertisement . . . . . . . . . . . . . . . . . 12		5.3. Capability Advertisement . . . . . . . . . . . . . . . . . 10
	5.4. State Synchronization . . . . . . . . . . . . . . . . . . 12		5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11
	5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 15		5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 14
	5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 16		5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15
	5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16		5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15
	5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 18		5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 17
	5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18		5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17
	5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19		5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18
	5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 19		5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 18
	5.6.1. Passive Stateful PCE Path Computation		5.6.1. Passive Stateful PCE Path Computation
	Request/Response . . . . . . . . . . . . . . . . . . . 20		Request/Response . . . . . . . . . . . . . . . . . . . 19
	5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 21		5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 20
	5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 23		5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 22
	5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23		5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22
	6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23		6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22
	6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23		6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22
	6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 25		6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24
	6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 27		6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26
	7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 28		7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 28		7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 27
	7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 28		7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 27
	7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 30		7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 32		7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 29
			7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 31
	7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 34		7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 34
	7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 35		7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 35
	7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 36		7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 35
	7.4. Optional TLVs for the LSPA Object . . . . . . . . . . . . 36		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	7.4.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 37		8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 36
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 36
	8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 37
	8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 37
	8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37		8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37
	8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 38		8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 37
	8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 38		8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 38
	8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 39		8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 38
	8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 39		8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 39
	9. Manageability Considerations . . . . . . . . . . . . . . . . . 39		9. Manageability Considerations . . . . . . . . . . . . . . . . . 39
	9.1. Control Function and Policy . . . . . . . . . . . . . . . 40		9.1. Control Function and Policy . . . . . . . . . . . . . . . 39
	9.2. Information and Data Models . . . . . . . . . . . . . . . 41		9.2. Information and Data Models . . . . . . . . . . . . . . . 40
	9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 41		9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 40
	9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 41		9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 41
	9.5. Requirements on Other Protocols and Functional		9.5. Requirements on Other Protocols and Functional
	Components . . . . . . . . . . . . . . . . . . . . . . . . 41		Components . . . . . . . . . . . . . . . . . . . . . . . . 41
	9.6. Impact on Network Operation . . . . . . . . . . . . . . . 41		9.6. Impact on Network Operation . . . . . . . . . . . . . . . 41
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 42		10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 42		10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 41
	10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 42		10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 42
	10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 43		10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 42
	10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 43		10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 43
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 44		12.1. Normative References . . . . . . . . . . . . . . . . . . . 43
	12.2. Informative References . . . . . . . . . . . . . . . . . . 45		12.2. Informative References . . . . . . . . . . . . . . . . . . 44
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
	1. Introduction		1. Introduction
	[RFC5440] describes the Path Computation Element Protocol (PCEP).		[RFC5440] describes the Path Computation Element Protocol (PCEP).
	PCEP defines the communication between a Path Computation Client		PCEP defines the communication between a Path Computation Client
	(PCC) and a Path Computation Element (PCE), or between PCEs, enabling		(PCC) and a Path Computation Element (PCE), or between PCEs, enabling
	computation of Multiprotocol Label Switching (MPLS) for Traffic		computation of Multiprotocol Label Switching (MPLS) for Traffic
	Engineering Label Switched Path (TE LSP) characteristics. Extensions		Engineering Label Switched Path (TE LSP) characteristics. Extensions
	for support of Generalized MPLS (GMPLS) in PCEP are defined in		for support of Generalized MPLS (GMPLS) in PCEP are defined in
	skipping to change at page 5, line 29 ¶		skipping to change at page 4, line 29 ¶
	over LSPs to PCEs, and PCE control of timing and sequence of path		over LSPs to PCEs, and PCE control of timing and sequence of path
	computations within and across PCEP sessions.		computations within and across PCEP sessions.
	2. Terminology		2. Terminology
	This document uses the following terms defined in [RFC5440]: PCC,		This document uses the following terms defined in [RFC5440]: PCC,
	PCE, PCEP Peer, PCEP Speaker.		PCE, PCEP Peer, PCEP Speaker.
	This document uses the following terms defined in [RFC4655]: TED.		This document uses the following terms defined in [RFC4655]: TED.
	This document uses the following terms defined in [RFC4090]: MPLS TE
	Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup.
	The following terms are defined in this document:		The following terms are defined in this document:
	Stateful PCE: has access to not only the network state, but also to		Stateful PCE: has access to not only the network state, but also to
	the set of active paths and their reserved resources for its		the set of active paths and their reserved resources for its
	computations. A stateful PCE might also retain information		computations. A stateful PCE might also retain information
	regarding LSPs under construction in order to reduce churn and		regarding LSPs under construction in order to reduce churn and
	resource contention. The additional state allows the PCE to		resource contention. The additional state allows the PCE to
	compute constrained paths while considering individual LSPs and		compute constrained paths while considering individual LSPs and
	their interactions. Note that this requires reliable state		their interactions. Note that this requires reliable state
	synchronization mechanisms between the PCE and the network, PCE		synchronization mechanisms between the PCE and the network, PCE
	skipping to change at page 6, line 11 ¶		skipping to change at page 5, line 10 ¶
	which the PCE may issue recommendations to the network. For		which the PCE may issue recommendations to the network. For
	example, an active stateful PCE may utilize the Delegation		example, an active stateful PCE may utilize the Delegation
	mechanism to update LSP parameters in those PCCs that delegated		mechanism to update LSP parameters in those PCCs that delegated
	control over their LSPs to the PCE.		control over their LSPs to the PCE.
	Delegation: An operation to grant a PCE temporary rights to modify a		Delegation: An operation to grant a PCE temporary rights to modify a
	subset of LSP parameters on one or more PCC's LSPs. LSPs are		subset of LSP parameters on one or more PCC's LSPs. LSPs are
	delegated from a PCC to a PCE, and are referred to as delegated		delegated from a PCC to a PCE, and are referred to as delegated
	LSPs. The PCC who owns the PCE state for the LSP has the right to		LSPs. The PCC who owns the PCE state for the LSP has the right to
	delegate it. An LSP is owned by a single PCC at any given point		delegate it. An LSP is owned by a single PCC at any given point
	in time. For intra-domain LSPs, this PCC SHOULD be the PCC of the		in time. For intra-domain LSPs, this PCC SHOULD be the LSP head
	LSP head end.		end.
	Revocation: An operation performed by a PCC on a previously		Revocation: An operation performed by a PCC on a previously
	delegated LSP. Revocation revokes the rights granted to the PCE		delegated LSP. Revocation revokes the rights granted to the PCE
	in the delegation operation.		in the delegation operation.
	Redelegation Timeout Interval: when a PCEP session is terminated, a		Redelegation Timeout Interval: when a PCEP session is terminated, a
	PCC waits for this time period before revoking LSP delegation to a		PCC waits for this time period before revoking LSP delegation to a
	PCE and attempting to redelegate LSPs associated with the		PCE and attempting to redelegate LSPs associated with the
	terminated PCEP session to an alternate PCE. The Redelegation		terminated PCEP session to an alternate PCE. The Redelegation
	Timeout Interval is a PCC-local value that can be either operator-		Timeout Interval is a PCC-local value that can be either operator-
	configured or dynamically computed by the PCC based on local		configured or dynamically computed by the PCC based on local
	policy.		policy.
	State Timeout Interval: when a PCEP session is terminated, a PCC		State Timeout Interval: when a PCEP session is terminated, a PCC
	waits for this time period before flushing LSP state associated		waits for this time period before flushing LSP state associated
	with that PCEP session and reverting to operator-defined default		with that PCEP session and reverting to operator-defined default
	parameters. The State Timeout Interval is a PCC-local value that		parameters or behaviors. The State Timeout Interval is a PCC-
	can be either operator-configured or dynamically computed by the		local value that can be either operator-configured or dynamically
	PCC based on local policy.		computed by the PCC based on local policy.
	LSP State Report: an operation to send LSP state (Operational /		LSP State Report: an operation to send LSP state (Operational /
	Admin Status, LSP attributes configured and set by a PCE, etc.)		Admin Status, LSP attributes configured at the PCC and set by a
	from a PCC to a PCE.		PCE, etc.) from a PCC to a PCE.
	LSP Update Request: an operation where an Active Stateful PCE		LSP Update Request: an operation where an Active Stateful PCE
	requests a PCC to update one or more attributes of an LSP and to		requests a PCC to update one or more attributes of an LSP and to
	re-signal the LSP with updated attributes.		re-signal the LSP with updated attributes.
	LSP State Database: information about all LSPs and their attributes.		LSP State Database: information about all LSPs and their attributes.
	Within this document, PCE-PCE communications are described by having		Within this document, PCE-PCE communications are described by having
	the requesting PCE fill the role of a PCC. This provides a saving in		the requesting PCE fill the role of a PCC. This provides a saving in
	documentation without loss of function.		documentation without loss of function.
	skipping to change at page 8, line 51 ¶		skipping to change at page 7, line 48 ¶
	o Scale & Performance: configuration operations often require		o Scale & Performance: configuration operations often require
	processing of additional configuration portions beyond the state		processing of additional configuration portions beyond the state
	being directly acted upon, with corresponding cost in CPU cycles,		being directly acted upon, with corresponding cost in CPU cycles,
	negatively impacting both PCC stability LSP update rate capacity.		negatively impacting both PCC stability LSP update rate capacity.
	o Scale & Performance: configuration operations often have		o Scale & Performance: configuration operations often have
	transactional semantics which are typically heavyweight and		transactional semantics which are typically heavyweight and
	require additional CPU cycles, negatively impacting PCC update		require additional CPU cycles, negatively impacting PCC update
	rate capacity.		rate capacity.
	o Security: opening up a configuration channel to a PCE would allow		o Security: when a PCC opens a configuration channel allowing a PCE
	a malicious PCE to take over a PCC. The PCEP extensions described		to send configuration, a malicious PCE may take advantage of this
	in this document only allow a PCE control over a very limited set		ability to take over the PCC. In contrast, the PCEP extensions
	of LSP attributes.		described in this document only allow a PCE control over a very
			limited set of LSP attributes.
	o Interoperability: each vendor has a proprietary information model		o Interoperability: each vendor has a proprietary information model
	for configuring LSP state, which prevents interoperability of a		for configuring LSP state, which prevents interoperability of a
	PCE with PCCs from different vendors. The PCEP extensions		PCE with PCCs from different vendors. The PCEP extensions
	described in this document allow for a common information model		described in this document allow for a common information model
	for LSP state for all vendors.		for LSP state for all vendors.
	o Efficient State Synchronization: configuration channels may be		o Efficient State Synchronization: configuration channels may be
	heavyweight and unidirectional, therefore efficient state		heavyweight and unidirectional, therefore efficient state
	synchronization between a PCE and a PCE may be a problem.		synchronization between a PCC and a PCE may be a problem.
	3.2. Objectives		3.2. Objectives
	The objectives for the protocol extensions to support stateful PCE		The objectives for the protocol extensions to support stateful PCE
	described in this document are as follows:		described in this document are as follows:
	o Allow a single PCC to interact with a mix of stateless and		o Allow a single PCC to interact with a mix of stateless and
	stateful PCEs simultaneously using the same PCEP.		stateful PCEs simultaneously using the same PCEP.
	o Support efficient LSP state synchronization between the PCC and		o Support efficient LSP state synchronization between the PCC and
	skipping to change at page 10, line 40 ¶		skipping to change at page 9, line 36 ¶
	5. Architectural Overview of Protocol Extensions		5. Architectural Overview of Protocol Extensions
	5.1. LSP State Ownership		5.1. LSP State Ownership
	In the PCEP protocol (defined in [RFC5440]), LSP state and operation		In the PCEP protocol (defined in [RFC5440]), LSP state and operation
	are under the control of a PCC (a PCC may be an LSR or a management		are under the control of a PCC (a PCC may be an LSR or a management
	station). Attributes received from a PCE are subject to PCC's local		station). Attributes received from a PCE are subject to PCC's local
	policy. The PCEP protocol extensions described in this document do		policy. The PCEP protocol extensions described in this document do
	not change this behavior.		not change this behavior.
	An active stateful PCE may have control of a PCC's LSPs be delegated		An active stateful PCE may have control of a PCC's LSPs that were
	to it, but the LSP state ownership is retained by the PCC. In		delegated to it, but the LSP state ownership is retained by the PCC.
	particular, in addition to specifying values for LSP's attributes, an		In particular, in addition to specifying values for LSP's attributes,
	active stateful PCE also decides when to make LSP modifications.		an active stateful PCE also decides when to make LSP modifications.
	Retaining LSP state ownership on the PCC allows for:		Retaining LSP state ownership on the PCC allows for:
	o a PCC to interact with both stateless and stateful PCEs at the		o a PCC to interact with both stateless and stateful PCEs at the
	same time		same time
	o a stateful PCE to only modify a small subset of LSP parameters,		o a stateful PCE to only modify a small subset of LSP parameters,
	i.e. to set only a small subset of the overall LSP state; other		i.e. to set only a small subset of the overall LSP state; other
	parameters may be set by the operator through command line		parameters may be set by the operator through command line
	interface (CLI) commands		interface (CLI) commands
	skipping to change at page 12, line 25 ¶		skipping to change at page 11, line 19 ¶
	The presence of the Stateful PCE Capability TLV in PCC's OPEN Object		The presence of the Stateful PCE Capability TLV in PCC's OPEN Object
	indicates that the PCC is willing to send LSP State Reports whenever		indicates that the PCC is willing to send LSP State Reports whenever
	LSP parameters or operational status changes.		LSP parameters or operational status changes.
	The presence of the Stateful PCE Capability TLV in PCE's OPEN message		The presence of the Stateful PCE Capability TLV in PCE's OPEN message
	indicates that the PCE is interested in receiving LSP State Reports		indicates that the PCE is interested in receiving LSP State Reports
	whenever LSP parameters or operational status changes.		whenever LSP parameters or operational status changes.
	The PCEP protocol extensions for stateful PCEs MUST NOT be used if		The PCEP protocol extensions for stateful PCEs MUST NOT be used if
	one or both PCEP Speakers have not included the Stateful PCE		one or both PCEP Speakers have not included the Stateful PCE
	Capability TLV in their respective OPEN message. If the PCEP		Capability TLV in their respective OPEN message. If the PCEP Speaker
	Speakers support the extensions of this draft but did not advertise		on the PCC supports the extensions of this draft but did not
	this capability, then a PCErr with error-type 19 (Invalid Operation),		advertise this capability, then upon receipt of PCUpd message from
	error-value 2 (Attempted LSP Update Request if active stateful PCE		the PCE, it SHOULD generate a PCErr with error-type 19 (Invalid
	capability was not advertised)(see Section 8.4) will be generated and		Operation), error-value 2 (Attempted LSP Update Request if active
	the PCEP session will be terminated.		stateful PCE capability was not advertised)(see Section 8.4) and it
			will terminate the PCEP session. If the PCEP Speaker on the PCE
			supports the extensions of this draft but did not advertise this
			capability, then upon receipt of a PCRpt message from the PCC, it
			SHOULD generate a PCErr with error-type 19 (Invalid Operation),
			error-value 5 (Attempted LSP State Report if active stateful PCE
			capability was not advertised) (see Section 8.4) and it will
			terminate the PCEP session.
	LSP delegation and LSP update operations defined in this document MAY		LSP delegation and LSP update operations defined in this document MAY
	only be used if both PCEP Speakers set the LSP-UPDATE Flag in the		only be used if both PCEP Speakers set the LSP-UPDATE Flag in the
	"Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this		"Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this
	is not the case and LSP delegation or LSP update operations are		is not the case and LSP delegation or LSP update operations are
	attempted, then a PCErr with error-type 19 (Invalid Operation) and		attempted, then a PCErr with error-type 19 (Invalid Operation) and
	error-value 1 (Attempted LSP Update Request for a non-delegated		error-value 1 (Attempted LSP Update Request for a non-delegated
	LSP).(see Section 8.4) SHOULD be generated. Note that even if the		LSP).(see Section 8.4) SHOULD be generated. Note that even if the
	update capability has not been advertised, a PCE can still receive		update capability has not been advertised, a PCE can still receive
	LSP Status Reports from a PCC and build and maintain an up to date		LSP Status Reports from a PCC and build and maintain an up to date
	skipping to change at page 17, line 48 ¶		skipping to change at page 16, line 48 ¶
	Interval timer expires, LSP delegations to the PCE remain intact.		Interval timer expires, LSP delegations to the PCE remain intact.
	Likewise, when a PCC's PCEP session with a PCE terminates		Likewise, when a PCC's PCEP session with a PCE terminates
	unexpectedly, the PCC MUST wait for the State Timeout Interval before		unexpectedly, the PCC MUST wait for the State Timeout Interval before
	flushing any LSP state associated with that PCE. Note that the State		flushing any LSP state associated with that PCE. Note that the State
	Timeout Interval timer may expire before the PCC has redelegated the		Timeout Interval timer may expire before the PCC has redelegated the
	LSPs to another PCE, for example if a PCC is not connected to any		LSPs to another PCE, for example if a PCC is not connected to any
	active stateful PCE or if no connected active stateful PCE accepts		active stateful PCE or if no connected active stateful PCE accepts
	the delegation. In this case, the PCC SHALL flush any LSP state set		the delegation. In this case, the PCC SHALL flush any LSP state set
	by the PCE upon expiration of the State Timeout Interval and revert		by the PCE upon expiration of the State Timeout Interval and revert
	to operator-defined default parameters. This operation SHOULD be		to operator-defined default parameters or behaviors. This operation
	done in a make-before-break fashion.		SHOULD be done in a make-before-break fashion.
	The State Timeout Interval SHOULD be greater than or equal to the		The State Timeout Interval SHOULD be greater than or equal to the
	Redelegation Timeout Interval and MAY be set to infinity (meaning		Redelegation Timeout Interval and MAY be set to infinity (meaning
	that until the PCC specifically takes action to change the parameters		that until the PCC specifically takes action to change the parameters
	set by the PCE, they will remain intact).		set by the PCE, they will remain intact).
	5.5.3. Returning a Delegation		5.5.3. Returning a Delegation
	A PCE that no longer wishes to update an LSP's parameters SHOULD		A PCE that no longer wishes to update an LSP's parameters SHOULD
	return the LSP delegation back to the PCC by sending an empty LSP		return the LSP delegation back to the PCC by sending an empty LSP
	skipping to change at page 28, line 47 ¶		skipping to change at page 27, line 47 ¶
	Unassigned bits are considered reserved. They MUST be set to 0 on		Unassigned bits are considered reserved. They MUST be set to 0 on
	transmission and MUST be ignored on receipt.		transmission and MUST be ignored on receipt.
	Advertisement of the stateful PCE capability implies support of LSPs		Advertisement of the stateful PCE capability implies support of LSPs
	that are signaled via RSVP, as well as the objects, TLVs and		that are signaled via RSVP, as well as the objects, TLVs and
	procedures defined in this document.		procedures defined in this document.
	7.2. SRP Object		7.2. SRP Object
	The SRP (Stateful PCE Request Parameters) object MUST be carried		The SRP (Stateful PCE Request Parameters) object MUST be carried
	within PCUpd messages and MAY be carried within PCRpt, PCNtf and		within PCUpd messages and MAY be carried within PCRpt and PCErr
	PCErr messages. The SRP object is used to correlate between update		messages. The SRP object is used to correlate between update
	requests sent by the PCE and the error reports and state reports sent		requests sent by the PCE and the error reports and state reports sent
	by the PCC.		by the PCC.
	SRP Object-Class is [TBD].		SRP Object-Class is [TBD].
	SRP Object-Type is 1.		SRP Object-Type is 1.
	The format of the SRP object body is shown in Figure 10:		The format of the SRP object body is shown in Figure 10:
	0 1 2 3		0 1 2 3
	skipping to change at page 29, line 24 ¶		skipping to change at page 28, line 24 ¶
	| SRP-ID-number |		| SRP-ID-number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// Optional TLVs //		// Optional TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: The SRP Object format		Figure 10: The SRP Object format
	The SRP object body has a variable length and may contain additional		The SRP object body has a variable length and may contain additional
	TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the		TLVs.
	optional TLVs.
	Flags (32 bits): None defined yet.		Flags (32 bits): None defined yet.
	SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the		SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the
	current PCEP session uniquely identify the operation that the PCE has		current PCEP session uniquely identify the operation that the PCE has
	requested the PCC to perform on a given LSP. The SRP-ID-number is		requested the PCC to perform on a given LSP. The SRP-ID-number is
	incremented each time a new request is sent to the PCC, and may wrap		incremented each time a new request is sent to the PCC, and may wrap
	around.		around.
	The values 0x00000000 and 0xFFFFFFFF are reserved.		The values 0x00000000 and 0xFFFFFFFF are reserved.
	skipping to change at page 30, line 24 ¶		skipping to change at page 29, line 24 ¶
	LSP Object-Class is [TBD].		LSP Object-Class is [TBD].
	LSP Object-Type is 1.		LSP Object-Type is 1.
	The format of the LSP object body is shown in Figure 11:		The format of the LSP object body is shown in Figure 11:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PLSP-ID | Flags | O|A|R|S|D|		| PLSP-ID | Flag | O|A|R|S|D|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// TLVs //		// TLVs //
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: The LSP Object format		Figure 11: The LSP Object format
	PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC		PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC
	creates a unique PLSP-ID for each LSP that is constant for the life		creates a unique PLSP-ID for each LSP that is constant for the
	time of a PCEP session. The mapping of the Symbolic Path Name to		lifetime of a PCEP session. The PCC will advertise the same PLSP-ID
	PLSP-ID is communicated to the PCE by sending a PCRpt message		on all PCEP sessions it maintains at a given times. The mapping of
	containing the SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages		the Symbolic Path Name to PLSP-ID is communicated to the PCE by
	then address the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are		sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All
	reserved. Note that the PLSP-ID is a value that is constant for the		subsequent PCEP messages then address the LSP by the PLSP-ID. The
	life time of the PCEP session, during which time for an RSVP-signaled		values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a
	LSP there might be a different RSVP identifiers (LSP-id, tunnel-id)		value that is constant for the lifetime of the PCEP session, during
	allocated it.		which time for an RSVP-signaled LSP there might be a different RSVP
			identifiers (LSP-id, tunnel-id) allocated it.
	Flags (12 bits):		Flags (12 bits):
	D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1		D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1
	indicates that the PCC is delegating the LSP to the PCE. On a		indicates that the PCC is delegating the LSP to the PCE. On a
	PCUpd message, the D flag set to 1 indicates that the PCE is		PCUpd message, the D flag set to 1 indicates that the PCE is
	confirming the LSP Delegation. To keep an LSP delegated to the		confirming the LSP Delegation. To keep an LSP delegated to the
	PCE, the PCC must set the D flag to 1 on each PCRpt message for		PCE, the PCC must set the D flag to 1 on each PCRpt message for
	the duration of the delegation - the first PCRpt with the D flag		the duration of the delegation - the first PCRpt with the D flag
	set to 0 revokes the delegation. To keep the delegation, the PCE		set to 0 revokes the delegation. To keep the delegation, the PCE
	skipping to change at page 34, line 48 ¶		skipping to change at page 34, line 37 ¶
	operator in a PCC's configuration. If the operator does not specify		operator in a PCC's configuration. If the operator does not specify
	a unique symbolic name for a path, the PCC MUST auto-generate one.		a unique symbolic name for a path, the PCC MUST auto-generate one.
	The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report		The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report
	when during a given PCEP session an LSP is first reported to a PCE.		when during a given PCEP session an LSP is first reported to a PCE.
	A PCC sends to a PCE the first LSP State Report either during State		A PCC sends to a PCE the first LSP State Report either during State
	Synchronization, or when a new LSP is configured at the PCC. The		Synchronization, or when a new LSP is configured at the PCC. The
	symbolic path name MAY be included in subsequent LSP State Reports		symbolic path name MAY be included in subsequent LSP State Reports
	for the LSP.		for the LSP.
	The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object		The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in the LSP Object
	and the LSPA Object.
	The format of the SYMBOLIC-PATH-NAME TLV is shown in the following		The format of the SYMBOLIC-PATH-NAME TLV is shown in the following
	figure:		figure:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=[TBD] | Length (variable) |		| Type=[TBD] | Length (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	skipping to change at page 36, line 45 ¶		skipping to change at page 36, line 28 ¶
	+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object +		+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 16: RSVP-ERROR-SPEC TLV format		Figure 16: RSVP-ERROR-SPEC TLV format
	The type of the TLV is [TBD] and it has a variable length. The value		The type of the TLV is [TBD] and it has a variable length. The value
	contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the		contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the
	object header.		object header.
	7.4. Optional TLVs for the LSPA Object
	TLVs that may be included in the LSPA Object are described in the
	following sections and in separate technology-specific documents.
	7.4.1. Symbolic Path Name TLV
	See section Section 7.3.2.
	8. IANA Considerations		8. IANA Considerations
	This document requests IANA actions to allocate code points for the		This document requests IANA actions to allocate code points for the
	protocol elements defined in this document. Values shown here are		protocol elements defined in this document. Values shown here are
	suggested for use by IANA.		suggested for use by IANA.
	8.1. PCEP Messages		8.1. PCEP Messages
	This document defines the following new PCEP messages:		This document defines the following new PCEP messages:
	skipping to change at page 38, line 39 ¶		skipping to change at page 38, line 18 ¶
	Error-value=2: Attempted LSP Update Request if active		Error-value=2: Attempted LSP Update Request if active
	stateful PCE capability was not		stateful PCE capability was not
	advertised.		advertised.
	Error-value=3: Attempted LSP Update Request for an LSP		Error-value=3: Attempted LSP Update Request for an LSP
	identified by an unknown PLSP-ID.		identified by an unknown PLSP-ID.
	Error-value=4: A PCE indicates to a PCC that it has		Error-value=4: A PCE indicates to a PCC that it has
	exceeded the resource limit allocated		exceeded the resource limit allocated
	for its state, and thus it cannot		for its state, and thus it cannot
	accept and process its LSP State Report		accept and process its LSP State Report
	message.		message.
			Error-value=5: Attempted LSP State Report if active
			stateful PCE capability was not
			advertised.
	20 LSP State synchronization error.		20 LSP State synchronization error.
	Error-value=1: A PCE indicates to a PCC that it can		Error-value=1: A PCE indicates to a PCC that it can
	not process (an otherwise valid) LSP		not process (an otherwise valid) LSP
	State Report. The PCEP-ERROR Object is		State Report. The PCEP-ERROR Object is
	followed by the LSP Object that		followed by the LSP Object that
	identifies the LSP.		identifies the LSP.
	Error-value=5: A PCC indicates to a PCE that it can		Error-value=5: A PCC indicates to a PCE that it can
	not complete the state synchronization,		not complete the state synchronization,
	8.5. PCEP TLV Type Indicators		8.5. PCEP TLV Type Indicators
	skipping to change at page 44, line 19 ¶		skipping to change at page 44, line 4 ¶
	Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin		Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin
	Sampath, Calvin Ying and Xian Zhang for helpful comments and		Sampath, Calvin Ying and Xian Zhang for helpful comments and
	discussions.		discussions.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-pce-gmpls-pcep-extensions]		[I-D.ietf-pce-gmpls-pcep-extensions]
	Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for		Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
	GMPLS", draft-ietf-pce-gmpls-pcep-extensions-08 (work in		GMPLS", draft-ietf-pce-gmpls-pcep-extensions-09 (work in
	progress), July 2013.		progress), February 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.		Functional Specification", RFC 2205, September 1997.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		(GMPLS) Signaling Resource ReserVation Protocol-Traffic
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
	[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
	Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
	May 2005.
	[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,		[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
	"OSPF Protocol Extensions for Path Computation Element		"OSPF Protocol Extensions for Path Computation Element
	(PCE) Discovery", RFC 5088, January 2008.		(PCE) Discovery", RFC 5088, January 2008.
	[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,		[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
	"IS-IS Protocol Extensions for Path Computation Element		"IS-IS Protocol Extensions for Path Computation Element
	(PCE) Discovery", RFC 5089, January 2008.		(PCE) Discovery", RFC 5089, January 2008.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	skipping to change at page 45, line 26 ¶		skipping to change at page 45, line 7 ¶
	12.2. Informative References		12.2. Informative References
	[I-D.ietf-pce-stateful-pce-app]		[I-D.ietf-pce-stateful-pce-app]
	Zhang, X. and I. Minei, "Applicability of Stateful Path		Zhang, X. and I. Minei, "Applicability of Stateful Path
	Computation Element (PCE)",		Computation Element (PCE)",
	draft-ietf-pce-stateful-pce-app-01 (work in progress),		draft-ietf-pce-stateful-pce-app-01 (work in progress),
	September 2013.		September 2013.
	[I-D.minei-pce-stateful-sync-optimizations]		[I-D.minei-pce-stateful-sync-optimizations]
	Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X.,		Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X.,
	and D. Dhody, "Optimizations of State Synchronization		and D. Dhody, "Optimizations of Label Switched Path State
	Procedures for Stateful PCE",		Synchronization Procedures for a Stateful PCE",
	draft-minei-pce-stateful-sync-optimizations-00 (work in		draft-minei-pce-stateful-sync-optimizations-01 (work in
	progress), October 2013.		progress), December 2013.
	[I-D.sivabalan-pce-disco-stateful]		[I-D.sivabalan-pce-disco-stateful]
	Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions		Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
	for Stateful PCE Discovery",		for Stateful PCE Discovery",
	draft-sivabalan-pce-disco-stateful-02 (work in progress),		draft-sivabalan-pce-disco-stateful-03 (work in progress),
	July 2013.		January 2014.
	[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE		[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
	LSP Path Computation using Preemption", Global		LSP Path Computation using Preemption", Global
	Information Infrastructure Symposium, July 2007.		Information Infrastructure Symposium, July 2007.
	[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear		[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
	programming algorithm for balancing the max-min fairness		programming algorithm for balancing the max-min fairness
	and throughput objectives in traffic engineering", pre-		and throughput objectives in traffic engineering",
	print, 2011.		INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012.
	[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network		[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
	Recovery: Protection and Restoration of Optical, SONET-		Recovery: Protection and Restoration of Optical, SONET-
	SDH, IP, and MPLS", The Morgan Kaufmann Series in		SDH, IP, and MPLS", The Morgan Kaufmann Series in
	Networking, June 2004.		Networking, June 2004.
	[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, September 1999.		RFC 2702, September 1999.
	skipping to change at page 47, line 4 ¶		skipping to change at page 46, line 26 ¶
	Authors' Addresses		Authors' Addresses
	Edward Crabbe		Edward Crabbe
	Google, Inc.		Google, Inc.
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, CA 94043		Mountain View, CA 94043
	US		US
	Email: edc@google.com		Email: edc@google.com
	Jan Medved		Jan Medved
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Dr.		170 West Tasman Dr.
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: jmedved@cisco.com		Email: jmedved@cisco.com
	Ina Minei		Ina Minei
	Juniper Networks, Inc.		Google, Inc.
	1194 N. Mathilda Ave.		1600 Amphitheatre Parkway
	Sunnyvale, CA 94089		Mountain View, CA 94043
	US		US
	Email: ina@juniper.net		Email: inaminei@google.com
	Robert Varga		Robert Varga
	Pantheon Technologies SRO		Pantheon Technologies SRO
	Mlynske Nivy 56		Mlynske Nivy 56
	Bratislava 821 05		Bratislava 821 05
	Slovakia		Slovakia
	Email: robert.varga@pantheon.sk		Email: robert.varga@pantheon.sk
End of changes. 40 change blocks.
	134 lines changed or deleted		127 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/