< draft-ietf-pce-stateful-pce-08.txt		draft-ietf-pce-stateful-pce-09.txt >
	PCE Working Group E. Crabbe		PCE Working Group E. Crabbe
	Internet-Draft Google, Inc.		Internet-Draft I. Minei
	Intended status: Standards Track J. Medved		Intended status: Standards Track Google, Inc.
	Expires: August 16, 2014 Cisco Systems, Inc.		Expires: December 24, 2014 J. Medved
	I. Minei		Cisco Systems, Inc.
	Google, Inc.
	R. Varga		R. Varga
	Pantheon Technologies SRO		Pantheon Technologies SRO
	February 12, 2014		June 22, 2014
	PCEP Extensions for Stateful PCE		PCEP Extensions for Stateful PCE
	draft-ietf-pce-stateful-pce-08		draft-ietf-pce-stateful-pce-09
	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 PCE		information available to the PCE, it also makes no provisions for PCE
	control of timing and sequence of path computations within and across		control of timing and sequence of path computations within and across
	PCEP sessions. This document describes a set of extensions to PCEP		PCEP sessions. This document describes a set of extensions to PCEP
	to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.		to enable stateful control of 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
	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 August 16, 2014.		This Internet-Draft will expire on December 24, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 5		3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5
	3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 6		3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5
	3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6		3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6
	3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 7		3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7
	3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 8
	4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 8		4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8
	5. Architectural Overview of Protocol Extensions . . . . . . . . 9		5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9
	5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9		5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9
	5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9
	5.3. Capability Advertisement . . . . . . . . . . . . . . . . . 10		5.3. Capability Advertisement . . . . . . . . . . . . . . . . 10
	5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11		5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11
	5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 14		5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 14
	5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15		5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15
	5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15		5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15
	5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 17		5.5.3. Returning a Delegation . . . . . . . . . . . . . . . 17
	5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17		5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17
	5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18		5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18
	5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 18		5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . 18
	5.6.1. Passive Stateful PCE Path Computation		5.6.1. Passive Stateful PCE Path Computation
	Request/Response . . . . . . . . . . . . . . . . . . . 19		Request/Response . . . . . . . . . . . . . . . . . . 18
	5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 20		5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . 20
	5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 22		5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . 22
	5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22		5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22
	6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22		6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22
	6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22		6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22
	6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24		6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24
	6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26		6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26
			6.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 26
	7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 26		6.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 27
	7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 27		7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 28
	7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 27		7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 28
	7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 27		7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 28
	7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 29		7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . 29
	7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 31		7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 30
	7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 34		7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . 32
	7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 35		7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . 35
	7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 35		7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . 36
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 36
	8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 36		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 36		8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 37
	8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37		8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 37
	8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 37		8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 38
	8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 38		8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 38
	8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 38		8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 39
	8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 39		8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 39
	9. Manageability Considerations . . . . . . . . . . . . . . . . . 39		8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . 40
	9.1. Control Function and Policy . . . . . . . . . . . . . . . 39		9. Manageability Considerations . . . . . . . . . . . . . . . . 40
	9.2. Information and Data Models . . . . . . . . . . . . . . . 40		9.1. Control Function and Policy . . . . . . . . . . . . . . . 40
	9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 40		9.2. Information and Data Models . . . . . . . . . . . . . . . 41
	9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 41		9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 41
	9.5. Requirements on Other Protocols and Functional		9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 42
	Components . . . . . . . . . . . . . . . . . . . . . . . . 41		9.5. Requirements on Other Protocols and Functional Components 42
	9.6. Impact on Network Operation . . . . . . . . . . . . . . . 41		9.6. Impact on Network Operation . . . . . . . . . . . . . . . 42
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 41		10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 41		10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . 42
	10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 42		10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . 43
	10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 42		10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . 43
	10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 43		10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . 44
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 43		12.1. Normative References . . . . . . . . . . . . . . . . . . 44
	12.2. Informative References . . . . . . . . . . . . . . . . . . 44		12.2. Informative References . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	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
	[I-D.ietf-pce-gmpls-pcep-extensions]		[I-D.ietf-pce-gmpls-pcep-extensions]
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 15 ¶
	LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to		LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to
	update LSP attributes on one or more LSPs; the PCE becomes the		update LSP attributes on one or more LSPs; the PCE becomes the
	authoritative source of the LSP's attributes as long as the		authoritative source of the LSP's attributes as long as the
	delegation is in effect (See Section 5.5); the PCC may withdraw		delegation is in effect (See Section 5.5); the PCC may withdraw
	the delegation or the PCE may give up the delegation at any time.		the delegation or the PCE may give up the delegation at any time.
	[I-D.sivabalan-pce-disco-stateful] defines the extensions needed to		[I-D.sivabalan-pce-disco-stateful] defines the extensions needed to
	support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or		support autodiscovery of stateful PCEs when using OSPF ([RFC5088]) or
	IS-IS ([RFC5089]) for PCE discovery.		IS-IS ([RFC5089]) for PCE discovery.
	5. Architectural Overview of Protocol Extensions		5. 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 that were		An active stateful PCE may have control of a PCC's LSPs that were
	skipping to change at page 10, line 40 ¶		skipping to change at page 10, line 26 ¶
	messages as shown in the following table.		messages as shown in the following table.
	+----------------------------------------+--------------------------+		+----------------------------------------+--------------------------+
	| Function | Message |		| Function | Message |
	+----------------------------------------+--------------------------+		+----------------------------------------+--------------------------+
	| Capability Advertisement (E-C,C-E) | Open |		| Capability Advertisement (E-C,C-E) | Open |
	| State Synchronization (C-E) | PCRpt |		| State Synchronization (C-E) | PCRpt |
	| LSP State Report (C-E) | PCRpt |		| LSP State Report (C-E) | PCRpt |
	| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |		| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
	| LSP Update Request (E-C) | PCUpd |		| LSP Update Request (E-C) | PCUpd |
	| ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS |		| ISIS stateful capability advertisement | ISIS PCE-CAP-FLAGS sub- |
	| | sub-TLV |		| | TLV |
	| OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, |		| OSPF stateful capability advertisement | OSPF RI LSA, PCE TLV, |
	| | PCE-CAP-FLAGS sub-TLV |		| | PCE-CAP-FLAGS sub-TLV |
	+----------------------------------------+--------------------------+		+----------------------------------------+--------------------------+
	Table 1: New Function to Message Mapping		Table 1: New Function to Message Mapping
	5.3. Capability Advertisement		5.3. Capability Advertisement
	During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)		During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
	advertise their support of stateful PCEP extensions. A PCEP Speaker		advertise their support of stateful PCEP extensions. A PCEP Speaker
	skipping to change at page 12, line 14 ¶		skipping to change at page 11, line 50 ¶
	state of its LSPs state, then sends the snapshot to a PCE in a		state of its LSPs state, then sends the snapshot to a PCE in a
	sequence of LSP State Reports. Each LSP State Report sent during		sequence of LSP State Reports. Each LSP State Report sent during
	State Synchronization has the SYNC Flag in the LSP Object set to 1.		State Synchronization has the SYNC Flag in the LSP Object set to 1.
	The set of LSPs for which state is synchronized with a PCE is		The set of LSPs for which state is synchronized with a PCE is
	determined by advertised stateful PCEP capabilities and PCC's local		determined by advertised stateful PCEP capabilities and PCC's local
	configuration (see more details in Section 9.1).		configuration (see more details in Section 9.1).
	The end of synchronization marker is a PCRpt message with the SYNC		The end of synchronization marker is a PCRpt message with the SYNC
	Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved		Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved
	value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV		value 0. The LSP Object does not include the SYMBOLIC-PATH-NAME TLV
	in this case. If the PCC has no state to synchronize, it will only		in this case, and it will include an empty ERO in its path. If the
	send the end of synchronization marker.		PCC has no state to synchronize, it will only send the end of
			synchronization marker.
	A PCE SHOULD NOT send PCUpd messages to a PCC before State		A PCE SHOULD NOT send PCUpd messages to a PCC before State
	Synchronization is complete. A PCC SHOULD NOT send PCReq messages to		Synchronization is complete. A PCC SHOULD NOT send PCReq messages to
	a PCE before State Synchronization is complete. This is to allow the		a PCE before State Synchronization is complete. This is to allow the
	PCE to get the best possible view of the network before it starts		PCE to get the best possible view of the network before it starts
	computing new paths.		computing new paths.
	Either the PCE or the PCC MAY terminate the session using the PCEP		Either the PCE or the PCC MAY terminate the session using the PCEP
	session termination procedures during the synchronization phase. If		session termination procedures during the synchronization phase. If
	the session is terminated, the PCE MUST clean up state it received		the session is terminated, the PCE MUST clean up state it received
	skipping to change at page 19, line 4 ¶		skipping to change at page 18, line 41 ¶
	PCE state indefinetely. Note also that flushing the state should be		PCE state indefinetely. Note also that flushing the state should be
	implemented using make-before-break to avoid traffic loss.		implemented using make-before-break to avoid traffic loss.
	If there is a standby PCE, the Redelegation Timeout may be set to 0		If there is a standby PCE, the Redelegation Timeout may be set to 0
	through policy on the PCC, causing the LSPs to be redelegated		through policy on the PCC, causing the LSPs to be redelegated
	immediately to the PCC, which can delegate them immediately to the		immediately to the PCC, which can delegate them immediately to the
	standby PCE. Assuming the State Timeout Interval is larger than the		standby PCE. Assuming the State Timeout Interval is larger than the
	Redelegation Timeout, the LSP state will be kept intact.		Redelegation Timeout, the LSP state will be kept intact.
	5.6. LSP Operations		5.6. LSP Operations
	5.6.1. Passive Stateful PCE Path Computation Request/Response
			5.6.1. Passive Stateful PCE Path Computation Request/Response
	+-+-+ +-+-+		+-+-+ +-+-+
	|PCC| |PCE|		|PCC| |PCE|
	+-+-+ +-+-+		+-+-+ +-+-+
	| |		| |
	1) Path computation |----- PCReq message --->|		1) Path computation |----- PCReq message --->|
	request sent to | |2) Path computation		request sent to | |2) Path computation
	PCE | | request received,		PCE | | request received,
	| | path computed		| | path computed
	| |		| |
	|<---- PCRep message ----|3) Computed paths		|<---- PCRep message ----|3) Computed paths
	skipping to change at page 19, line 35 ¶		skipping to change at page 19, line 33 ¶
	6) Repeat for each |----- PCRpt message --->|		6) Repeat for each |----- PCRpt message --->|
	LSP status change| |		LSP status change| |
	| |		| |
	Figure 7: Passive Stateful PCE Path Computation Request/Response		Figure 7: Passive Stateful PCE Path Computation Request/Response
	Once a PCC has successfully established a PCEP session with a passive		Once a PCC has successfully established a PCEP session with a passive
	stateful PCE and the PCC's LSP state is synchronized with the PCE		stateful PCE and the PCC's LSP state is synchronized with the PCE
	(i.e. the PCE knows about all PCC's existing LSPs), if an event is		(i.e. the PCE knows about all PCC's existing LSPs), if an event is
	triggered that requires the computation of a set of paths, the PCC		triggered that requires the computation of a set of paths, the PCC
	sends a path computation request to the PCE ([RFC5440], Section		sends a path computation request to the PCE ([RFC5440],
	4.2.3).		Section 4.2.3). The PCReq message MAY contain the LSP Object to
			identify the LSP for which the path computation is requested.
	Upon receiving a path computation request from a PCC, the PCE		Upon receiving a path computation request from a PCC, the PCE
	triggers a path computation and returns either a positive or a		triggers a path computation and returns either a positive or a
	negative reply to the PCC ([RFC5440], Section 4.2.4).		negative reply to the PCC ([RFC5440], Section 4.2.4).
	Upon receiving a positive path computation reply, the PCC receives a		Upon receiving a positive path computation reply, the PCC receives a
	set of computed paths and starts to setup the LSPs. For each LSP, it		set of computed paths and starts to setup the LSPs. For each LSP, it
	sends an LSP State Report carried on a PCRpt message to the PCE,		sends an LSP State Report carried on a PCRpt message to the PCE,
	indicating that the LSP's status is 'Pending'.		indicating that the LSP's status is "Going-up".
	Once an LSP is up, the PCC sends an LSP State Report carried on a		Once an LSP is up, the PCC sends an LSP State Report carried on a
	PCRpt message to the PCE, indicating that the LSP's status is 'Up'.		PCRpt message to the PCE, indicating that the LSP's status is 'Up'.
	If the LSP could not be set up, the PCC sends an LSP State Report		If the LSP could not be set up, the PCC sends an LSP State Report
	indicating that the LSP is "Down' and stating the cause of the		indicating that the LSP is "Down' and stating the cause of the
	failure. Note that due to timing constraints, the LSP status may		failure. Note that due to timing constraints, the LSP status may
	change from 'Pending' to 'Up' (or 'Down') before the PCC has had a		change from 'Going-up' to 'Up' (or 'Down') before the PCC has had a
	chance to send an LSP State Report indicating that the status is		chance to send an LSP State Report indicating that the status is
	'Pending'. In such cases, the PCC may choose to only send the PCRpt		'Going-up'. In such cases, the PCC may choose to only send the PCRpt
	indicating the latest status ('Up' or 'Down').		indicating the latest status ('Up' or 'Down').
	Upon receiving a negative reply from a PCE, a PCC may decide to		Upon receiving a negative reply from a PCE, a PCC may decide to
	resend a modified request or take any other appropriate action. For		resend a modified request or take any other appropriate action. For
	each requested LSP, it also sends an LSP State Report carried on a		each requested LSP, it also sends an LSP State Report carried on a
	PCRpt message to the PCE, indicating that the LSP's status is 'Down'.		PCRpt message to the PCE, indicating that the LSP's status is 'Down'.
	There is no direct correlation between PCRep and PCRpt messages. For		There is no direct correlation between PCRep and PCRpt messages. For
	a given LSP, multiple LSP State Reports will follow a single PCRep		a given LSP, multiple LSP State Reports will follow a single PCRep
	message, as a PCC notifies a PCE of the LSP's state changes.		message, as a PCC notifies a PCE of the LSP's state changes.
	skipping to change at page 20, line 43 ¶		skipping to change at page 20, line 42 ¶
	1) LSP State |-- PCRpt, Delegate=1 -->|		1) LSP State |-- PCRpt, Delegate=1 -->|
	Synchronization | . |		Synchronization | . |
	or add new LSP | . |2) PCE decides to		or add new LSP | . |2) PCE decides to
	| . | update the LSP		| . | update the LSP
	| |		| |
	|<---- PCUpd message ----|3) PCUpd message sent		|<---- PCUpd message ----|3) PCUpd message sent
	| | to PCC		| | to PCC
	| |		| |
	| |		| |
	4) LSP Status Report|---- PCRpt message ---->|		4) LSP Status Report|---- PCRpt message ---->|
	sent(->Pending) | . |		sent(->Going-up) | . |
	| . |		| . |
	| . |		| . |
	5) LSP Status Report|---- PCRpt message ---->|		5) LSP Status Report|---- PCRpt message ---->|
	sent (->Up|Down) | |		sent (->Up|Down) | |
	| |		| |
	Figure 8: Active Stateful PCE		Figure 8: Active Stateful PCE
	Once a PCC has successfully established a PCEP session with an active		Once a PCC has successfully established a PCEP session with an active
	stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e.		stateful PCE, the PCC's LSP state is synchronized with the PCE (i.e.
	skipping to change at page 21, line 23 ¶		skipping to change at page 21, line 23 ¶
	specify the set of constraints and attributes for the LSP's path.		specify the set of constraints and attributes for the LSP's path.
	Each LSP Update Request has a unique identifier, the SRP-ID-number,		Each LSP Update Request has a unique identifier, the SRP-ID-number,
	carried in the SRP (Stateful PCE Request Parameters) Object described		carried in the SRP (Stateful PCE Request Parameters) Object described
	in Section 7.2. The SRP-ID-number is used to correlate errors and		in Section 7.2. The SRP-ID-number is used to correlate errors and
	state reports to LSP Update Requests. A single PCUpd message MAY		state reports to LSP Update Requests. A single PCUpd message MAY
	contain multiple LSP Update Requests.		contain multiple LSP Update Requests.
	Upon receiving a PCUpd message the PCC starts to setup LSPs specified		Upon receiving a PCUpd message the PCC starts to setup LSPs specified
	in LSP Update Requests carried in the message. For each LSP, it		in LSP Update Requests carried in the message. For each LSP, it
	sends an LSP State Report carried on a PCRpt message to the PCE,		sends an LSP State Report carried on a PCRpt message to the PCE,
	indicating that the LSP's status is 'Pending'. If the PCC decides		indicating that the LSP's status is 'Going-up'. If the PCC decides
	that the LSP parameters proposed in the PCUpd message are		that the LSP parameters proposed in the PCUpd message are
	unacceptable, it MUST report this error by including the LSP-ERROR-		unacceptable, it MUST report this error by including the LSP-ERROR-
	CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable		CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable
	parameters" in the LSP object in the PCRpt message to the PCE. Based		parameters" in the LSP object in the PCRpt message to the PCE. Based
	on local policy, it MAY react further to this error by revoking the		on local policy, it MAY react further to this error by revoking the
	delegation. If the PCC receives a PCUpd message for an LSP object		delegation. If the PCC receives a PCUpd message for an LSP object
	identified with a PLSP-ID that does not exist on the PCC, it MUST		identified with a PLSP-ID that does not exist on the PCC, it MUST
	generate a PCErr with error-type 19 (Invalid Operation), error-value		generate a PCErr with error-type 19 (Invalid Operation), error-value
	3, (Attempted LSP Update Request for an LSP identified by an unknown		3, (Attempted LSP Update Request for an LSP identified by an unknown
	PSP-ID) (see Section 8.4).		PSP-ID) (see Section 8.4).
	skipping to change at page 23, line 28 ¶		skipping to change at page 23, line 28 ¶
	<attribute-list> is defined in [RFC5440] and extended by PCEP extensions.		<attribute-list> is defined in [RFC5440] and extended by PCEP extensions.
	The SRP object (see Section 7.2) is optional. If the PCRpt message		The SRP object (see Section 7.2) is optional. If the PCRpt message
	is not in response to a PCupd message, the SRP object MAY be omitted.		is not in response to a PCupd message, the SRP object MAY be omitted.
	When the PCC does not include the SRP object, the PCE treats this as		When the PCC does not include the SRP object, the PCE treats this as
	an SRP object with an SRP-ID-number equal to the reserved value		an SRP object with an SRP-ID-number equal to the reserved value
	0x00000000. The reserved value 0x00000000 indicates that the state		0x00000000. The reserved value 0x00000000 indicates that the state
	reported is not as a result of processing a PCUpd message.		reported is not as a result of processing a PCUpd message.
	If the PCRpt message is in response to a PCUpd message, the SRP		If the PCRpt message is in response to a PCUpd message, the SRP
	object SHOULD be included and the value of the SRP-ID-number in the		object MUST be included and the value of the SRP-ID-number in the SRP
	SRP Object MUST be the same as that sent in the PCUpd message that		Object MUST be the same as that sent in the PCUpd message that
	triggered the state that is reported. If the PCC compressed several		triggered the state that is reported. If the PCC compressed several
	PCUpd messages for the same LSP by only processing the latest one,		PCUpd messages for the same LSP by only processing the latest one,
	then it should use the SRP-ID-number of that request. No state		then it should use the SRP-ID-number of that request. No state
	compression is allowed for state reporting, e.g. PCRpt messages MUST		compression is allowed for state reporting, e.g. PCRpt messages MUST
	NOT be pruned from the PCC's egress queue even if subsequent		NOT be pruned from the PCC's egress queue even if subsequent
	operations on the same LSP have been completed before the PCRpt		operations on the same LSP have been completed before the PCRpt
	message has been sent to the TCP stack. The PCC MUST explicitly		message has been sent to the TCP stack. The PCC MUST explicitly
	report state changes (including removal) for paths it manages.		report state changes (including removal) for paths it manages.
	The LSP object (see Section 7.3) is mandatory, and it MUST be		The LSP object (see Section 7.3) is mandatory, and it MUST be
	skipping to change at page 24, line 23 ¶		skipping to change at page 24, line 23 ¶
	A Path Computation LSP Update Request message (also referred to as		A Path Computation LSP Update Request message (also referred to as
	PCUpd message) is a PCEP message sent by a PCE to a PCC to update		PCUpd message) is a PCEP message sent by a PCE to a PCC to update
	attributes of an LSP. A PCUpd message can carry more than one LSP		attributes of an LSP. A PCUpd message can carry more than one LSP
	Update Request. The Message-Type field of the PCEP common header for		Update Request. The Message-Type field of the PCEP common header for
	the PCUpd message is set to [TBD].		the PCUpd message is set to [TBD].
	The format of a PCUpd message is as follows:		The format of a PCUpd message is as follows:
	<PCUpd Message> ::= <Common Header>		<PCUpd Message> ::= <Common Header>
	<udpate-request-list>		<update-request-list>
	Where:		Where:
	<update-request-list> ::= <update-request>[<update-request-list>]		<update-request-list> ::= <update-request>[<update-request-list>]
	<update-request> ::= <SRP>		<update-request> ::= <SRP>
	<LSP>		<LSP>
	<path>		<path>
	Where:		Where:
	<path>::= <ERO><attribute-list>		<path>::= <ERO><attribute-list>
	skipping to change at page 25, line 22 ¶		skipping to change at page 25, line 22 ¶
	messages for each, identified by the LSP-IDENTIFIERS TLV. When the		messages for each, identified by the LSP-IDENTIFIERS TLV. When the
	old path is torn down after the head end switches over the traffic,		old path is torn down after the head end switches over the traffic,
	this event MUST be reported by sending a PCRpt message with the LSP-		this event MUST be reported by sending a PCRpt message with the LSP-
	IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number		IDENTIFIERS-TLV of the old path and the R bit set. The SRP-ID-number
	that the PCE associates with this PCRpt MUST be 0x00000000. Thus, a		that the PCE associates with this PCRpt MUST be 0x00000000. Thus, a
	make-before-break operation will typically result in at least two		make-before-break operation will typically result in at least two
	PCRpt messages, one for the new path and one for the removal of the		PCRpt messages, one for the new path and one for the removal of the
	old path (more messages may be possible if intermediate states are		old path (more messages may be possible if intermediate states are
	reported).		reported).
			If the path setup fails due to an RSVP signaling error, the error is
			reported to the PCE. The PCC will not attempt to resignal the path
			until it is prompted again by the PCE with a subsequent PCUpd
			message.
	A PCC MUST respond with an LSP State Report to each LSP Update		A PCC MUST respond with an LSP State Report to each LSP Update
	Request it processed to indicate the resulting state of the LSP in		Request it processed to indicate the resulting state of the LSP in
	the network (even if this processing did not result in changing the		the network (even if this processing did not result in changing the
	state of the LSP). The SRP-ID-number included in the PCRpt MUST		state of the LSP). The SRP-ID-number included in the PCRpt MUST
	match that in the PCUpd. A PCC MAY respond with multiple LSP State		match that in the PCUpd. A PCC MAY respond with multiple LSP State
	Reports to report LSP setup progress of a single LSP. In that case,		Reports to report LSP setup progress of a single LSP. In that case,
	the SRP-ID-number MUST be included for the first message, for		the SRP-ID-number MUST be included for the first message, for
	subsequent messages the reserved value 0x00000000 SHOULD be used.		subsequent messages the reserved value 0x00000000 SHOULD be used.
	Note that a PCC MUST process all LSP Update Requests - for example,		Note that a PCC MUST process all LSP Update Requests - for example,
	skipping to change at page 26, line 41 ¶		skipping to change at page 26, line 46 ¶
	<error>::=[<request-id-list> | <stateful-request-id-list>] <<<< new		<error>::=[<request-id-list> | <stateful-request-id-list>] <<<< new
	<error-obj-list>		<error-obj-list>
	<request-id-list>::=<RP>[<request-id-list>]		<request-id-list>::=<RP>[<request-id-list>]
	<stateful-request-id-list>::=<SRP>[<stateful-request-id-list>] <<< new		<stateful-request-id-list>::=<SRP>[<stateful-request-id-list>] <<< new
	<error-list>::=<error>[<error-list>]		<error-list>::=<error>[<error-list>]
			6.4. The PCReq Message
			A PCC MAY include the LSP object in the PCReq message (see
			Section 7.3) if the stateful PCE capability has been negotiated on a
			PCEP session between the PCC and a PCE.
			The definition of the PCReq message from [RFC5440] is extended to
			optionally include the LSP object after the END-POINTS object. The
			encoding from [RFC5440] will become:
			<PCReq Message>::= <Common Header>
			[<svec-list>]
			<request-list>
			Where:
			<svec-list>::=<SVEC>[<svec-list>]
			<request-list>::=<request>[<request-list>]
			<request>::= <RP>
			<END-POINTS>
			[<LSP>] <--- New Object
			[<LSPA>]
			[<BANDWIDTH>]
			[<metric-list>]
			[<RRO>[<BANDWIDTH>]]
			[<IRO>]
			[<LOAD-BALANCING>]
			6.5. The PCRep Message
			A PCE MAY include the LSP object in the PCRep message (see
			(Section 7.3) if the stateful PCE capability has been negotiated on a
			PCEP session between the PCC and the PCE and the LSP object was
			included in the corresponding PCReq message from the PCC.
			The definition of the PCRep message from [RFC5440] is extended to
			optionally include the LSP object after the RP object. The encoding
			from [RFC5440] will become:
			<PCRep Message> ::= <Common Header>
			<response-list>
			Where:
			<response-list>::=<response>[<response-list>]
			<response>::=<RP>
			[<LSP>] <--- New Object
			[<NO-PATH>]
			[<attribute-list>]
			[<path-list>]
	7. Object Formats		7. Object Formats
	The PCEP objects defined in this document are compliant with the PCEP		The PCEP objects defined in this document are compliant with the PCEP
	object format defined in [RFC5440]. The P flag and the I flag of the		object format defined in [RFC5440]. The P flag and the I flag of the
	PCEP objects defined in this document MUST always be set to 0 on		PCEP objects defined in this document MUST always be set to 0 on
	transmission and MUST be ignored on receipt since these flags are		transmission and MUST be ignored on receipt since these flags are
	exclusively related to path computation requests.		exclusively related to path computation requests.
	7.1. OPEN Object		7.1. OPEN Object
	skipping to change at page 28, line 9 ¶		skipping to change at page 29, line 19 ¶
	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
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags |		| Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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.		TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the
			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 28, line 49 ¶		skipping to change at page 30, line 12 ¶
	be more than one SRP-id-number unacknowledged at a given time. The		be more than one SRP-id-number unacknowledged at a given time. The
	value of the SRP-ID-number is echoed back by the PCC in PCErr and		value of the SRP-ID-number is echoed back by the PCC in PCErr and
	PCRpt messages to allow for correlation between requests made by the		PCRpt messages to allow for correlation between requests made by the
	PCE and errors or state reports generated by the PCC. If the error		PCE and errors or state reports generated by the PCC. If the error
	or report were not as a result of a PCE operation (for example in the		or report were not as a result of a PCE operation (for example in the
	case of a link down event), the reserved value of 0x00000000 is used		case of a link down event), the reserved value of 0x00000000 is used
	for the SRP-ID-number. The absence of the SRP object is equivalent		for the SRP-ID-number. The absence of the SRP object is equivalent
	to an SRP object with the reserved value of 0x00000000. An SRP-ID-		to an SRP object with the reserved value of 0x00000000. An SRP-ID-
	number is considered unacknowledged and cannot be reused until a		number is considered unacknowledged and cannot be reused until a
	PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the		PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the
	same LSP. A PCRpt with state "Pending" is not considered as an		same LSP. In case of SRP-ID wrapping the last SRP-ID before the
	acknowledgement.		wrapping MUST be explicitly acknowledged, to avoid a situation where
			SRP-IDs remain unacknowledged after the wrap. This means that the
			PCC may need to issue two PCUpd messages on detecting a wrap.
	7.3. LSP Object		7.3. LSP Object
	The LSP object MUST be present within PCRpt and PCUpd messages. The		The LSP object MUST be present within PCRpt and PCUpd messages. The
	LSP object contains a set of fields used to specify the target LSP,		LSP object MAY be carried within PCReq and PCRep messages if the
	the operation to be performed on the LSP, and LSP Delegation. It		stateful PCE capability has been negotiated on the session. The LSP
	also contains a flag indicating to a PCE that the LSP state		object contains a set of fields used to specify the target LSP, the
			operation to be performed on the LSP, and LSP Delegation. It also
			contains a flag indicating to a PCE that the LSP state
	synchronization is in progress. This document focuses on LSPs that		synchronization is in progress. This document focuses on LSPs that
	are signaled with RSVP, many of the TLVs used with the LSP object		are signaled with RSVP, many of the TLVs used with the LSP object
	mirror RSVP state.		mirror RSVP state.
	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:
	skipping to change at page 31, line 30 ¶		skipping to change at page 33, line 8 ¶
	a make-before-break scenario, the PCC MUST send a separate PCRpt for		a make-before-break scenario, the PCC MUST send a separate PCRpt for
	the old and for the reoptimized paths, and explicitly report removal		the old and for the reoptimized paths, and explicitly report removal
	of any of these paths using the R bit in the LSP object.		of any of these paths using the R bit in the LSP object.
	The format of the IPV4-LSP-IDENTIFIERS TLV is shown in the following		The format of the IPV4-LSP-IDENTIFIERS 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=12 |		| Type=[TBD] | Length=16 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Tunnel Sender Address |		| IPv4 Tunnel Sender Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP ID | Tunnel ID |		| LSP ID | Tunnel ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Extended Tunnel ID |		| Extended Tunnel ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Tunnel Endpoint Address |		| IPv4 Tunnel Endpoint Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 33, line 8 ¶		skipping to change at page 34, line 8 ¶
	IPv4 Tunnel Endpoint Address: contains the egress node's IPv4		IPv4 Tunnel Endpoint Address: contains the egress node's IPv4
	address, as defined in [RFC3209], Section 4.6.1.1 for the		address, as defined in [RFC3209], Section 4.6.1.1 for the
	LSP_TUNNEL_IPv4 Sender Template Object.		LSP_TUNNEL_IPv4 Sender Template Object.
	The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l following		The format of the IPV6-LSP-IDENTIFIERS TLV is shown in l 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=36 |		| Type=[TBD] | Length=52 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| IPv6 tunnel sender address |		| IPv6 tunnel sender address |
	+ (16 octets) +		+ (16 octets) +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LSP ID | Tunnel ID |		| LSP ID | Tunnel ID |
	skipping to change at page 34, line 37 ¶		skipping to change at page 35, line 34 ¶
	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 the LSP Object		The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object
			and the SRP 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 35, line 37 ¶		skipping to change at page 36, line 37 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 15: LSP-ERROR-CODE TLV format		Figure 15: LSP-ERROR-CODE TLV format
	The type of the TLV is [TBD] and it has a fixed length of 4 octets.		The type of the TLV is [TBD] and it has a fixed length of 4 octets.
	The value contains an error code that indicates the cause of the		The value contains an error code that indicates the cause of the
	failure.		failure.
	The following LSP Error Codes are defined:		The following LSP Error Codes are defined:
	Value Meaning		Value Meaning
	1 Unknown reason		1 Unknown reason
	2 Limit reached for PCE-controlled LSPs		2 Limit reached for PCE-controlled LSPs
	3 Too many pending LSP update requests		3 Too many pending LSP update requests
	4 Unacceptable parameters		4 Unacceptable parameters
	5 Internal error		5 Internal error
	6 LSP administratively brought down		6 LSP administratively brought down
	7 LSP preempted		7 LSP preempted
	8 RSVP signaling error		8 RSVP signaling error
	7.3.4. RSVP Error Spec TLV		7.3.4. RSVP Error Spec TLV
	The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object		The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object
	to carry RSVP error information. It includes the RSVP ERROR_SPEC or		to carry RSVP error information. It includes the RSVP ERROR_SPEC or
	USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned		USER_ERROR_SPEC Object ([RFC2205] and [RFC5284]) which were returned
	to the PCC from a downstream node. If the set up of an LSP fails at		to the PCC from a downstream node. If the set up of an LSP fails at
	a downstream node which returned an ERROR_SPEC to the PCC, the PCC		a downstream node which returned an ERROR_SPEC to the PCC, the PCC
	SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with		SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with
	LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV		LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV
	skipping to change at page 36, line 38 ¶		skipping to change at page 37, line 38 ¶
	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:
	Value Meaning Reference		Value Meaning Reference
	10 Report This document		10 Report This document
	11 Update This document		11 Update This document
	8.2. PCEP Objects		8.2. PCEP Objects
	This document defines the following new PCEP Object-classes and		This document defines the following new PCEP Object-classes and
	Object-values:		Object-values:
	Object-Class Value Name Reference		Object-Class Value Name Reference
	32 LSP This document		32 LSP This document
	Object-Type		Object-Type
	1		1
	33 SRP This document		33 SRP This document
	Object-Type		Object-Type
	1		1
	8.3. LSP Object		8.3. LSP Object
	This document requests that a registry is created to manage the Flags		This document requests that a registry is created to manage the Flags
	field of the LSP object. New values are to be assigned by Standards		field of the LSP object. New values are to be assigned by Standards
	Action [RFC5226]. Each bit should be tracked with the following		Action [RFC5226]. Each bit should be tracked with the following
	qualities:		qualities:
	o Bit number (counting from bit 0 as the most significant bit)		o Bit number (counting from bit 0 as the most significant bit)
	o Capability description		o Capability description
	o Defining RFC		o Defining RFC
	The following values are defined in this document:		The following values are defined in this document:
	Bit Description Reference		Bit Description Reference
	25-27 Operational (3 bits) This document		0-4 Reserved This document
	28 Administrative This document		5-7 Operational (3 bits) This document
	29 Remove This document		8 Administrative This document
	30 SYNC This document		9 Remove This document
	31 Delegate This document		10 SYNC This document
			11 Delegate This document
	8.4. PCEP-Error Object		8.4. PCEP-Error Object
	This document defines new Error-Type and Error-Value for the		This document defines new Error-Type and Error-Value for the
	following new error conditions:		following new error conditions:
	Error-Type Meaning		Error-Type Meaning
	6 Mandatory Object missing		6 Mandatory Object missing
	Error-value=8: LSP Object missing		Error-value=8: LSP Object missing
	Error-value=9: ERO Object missing		Error-value=9: ERO Object missing
	Error-value=10: SRP Object missing		Error-value=10: SRP Object missing
	Error-value=11: LSP-IDENTIFIERS TLV missing		Error-value=11: LSP-IDENTIFIERS TLV missing
	19 Invalid Operation		19 Invalid Operation
	Error-value=1: Attempted LSP Update Request for a non-		Error-value=1: Attempted LSP Update Request for a non-
	delegated LSP. The PCEP-ERROR Object		delegated LSP. The PCEP-ERROR Object
	is followed by the LSP Object that		is followed by the LSP Object that
	identifies the LSP.		identifies the LSP.
	Error-value=2: Attempted LSP Update Request if active		Error-value=2: Attempted LSP Update Request if active
	skipping to change at page 38, line 22 ¶		skipping to change at page 39, line 22 ¶
	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		Error-value=5: Attempted LSP State Report if active
	stateful PCE capability was not		stateful PCE capability was not
	advertised.		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
	This document defines the following new PCEP TLVs:		This document defines the following new PCEP TLVs:
	Value Meaning Reference		Value Meaning Reference
	16 STATEFUL-PCE-CAPABILITY This document		16 STATEFUL-PCE-CAPABILITY This document
	17 SYMBOLIC-PATH-NAME This document		17 SYMBOLIC-PATH-NAME This document
	18 IPV4-LSP-IDENTIFIERS This document		18 IPV4-LSP-IDENTIFIERS This document
	19 IPV6-LSP-IDENTIFIERS This document		19 IPV6-LSP-IDENTIFIERS This document
	20 LSP-ERROR-CODE This document		20 LSP-ERROR-CODE This document
	21 RSVP-ERROR-SPEC This document		21 RSVP-ERROR-SPEC This document
	8.6. STATEFUL-PCE-CAPABILITY TLV		8.6. STATEFUL-PCE-CAPABILITY TLV
	This document requests that a registry is created to manage the Flags		This document requests that a registry is created to manage the Flags
	field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New		field in the STATEFUL-PCE-CAPABILITY TLV in the OPEN object. New
	values are to be assigned by Standards Action [RFC5226]. Each bit		values are to be assigned by Standards Action [RFC5226]. Each bit
	should be tracked with the following qualities:		should be tracked with the following qualities:
	o Bit number (counting from bit 0 as the most significant bit)		o Bit number (counting from bit 0 as the most significant bit)
	o Capability description		o Capability description
	o Defining RFC		o Defining RFC
	The following values are defined in this document:		The following values are defined in this document:
	Bit Description Reference		Bit Description Reference
	31 LSP-UPDATE-CAPABILITY This document		31 LSP-UPDATE-CAPABILITY This document
	8.7. LSP-ERROR-CODE TLV		8.7. LSP-ERROR-CODE TLV
	This document requests that a registry is created to manage the value		This document requests that a registry is created to manage the value
	of the LSP error code field in this TLV. This field specifies the		of the LSP error code field in this TLV. This field specifies the
	reason for failure to update the LSP.		reason for failure to update the LSP.
	Value Meaning		Value Meaning
	1 Unknown reason		1 Unknown reason
	2 Limit reached for PCE-controlled LSPs		2 Limit reached for PCE-controlled LSPs
	3 Too many pending LSP update requests		3 Too many pending LSP update requests
	4 Unacceptable parameters		4 Unacceptable parameters
	5 Internal error		5 Internal error
	6 LSP administratively brought down		6 LSP administratively brought down
	7 LSP preempted		7 LSP preempted
	8 RSVP signaling error		8 RSVP signaling error
	9. Manageability Considerations		9. Manageability Considerations
	All manageability requirements and considerations listed in [RFC5440]		All manageability requirements and considerations listed in [RFC5440]
	apply to PCEP protocol extensions defined in this document. In		apply to PCEP protocol extensions defined in this document. In
	addition, requirements and considerations listed in this section		addition, requirements and considerations listed in this section
	apply.		apply.
	9.1. Control Function and Policy		9.1. Control Function and Policy
	skipping to change at page 40, line 48 ¶		skipping to change at page 41, line 48 ¶
	9.2. Information and Data Models		9.2. Information and Data Models
	PCEP session configuration and information in the PCEP MIB module		PCEP session configuration and information in the PCEP MIB module
	SHOULD be extended to include advertised stateful capabilities,		SHOULD be extended to include advertised stateful capabilities,
	synchronization status, and delegation status (at the PCC list PCEs		synchronization status, and delegation status (at the PCC list PCEs
	with delegated LSPs).		with delegated LSPs).
	9.3. Liveness Detection and Monitoring		9.3. Liveness Detection and Monitoring
	PCEP protocol extensions defined in this document do not require any		PCEP protocol extensions defined in this document do not require any
	new mechanisms beyond those already defined in [RFC5440], Section		new mechanisms beyond those already defined in [RFC5440],
	8.3.		Section 8.3.
	9.4. Verifying Correct Operation		9.4. Verifying Correct Operation
	Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP		Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP
	protocol extensions defined in this document. In addition to		protocol extensions defined in this document. In addition to
	monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP		monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP
	implementation SHOULD provide the following parameters:		implementation SHOULD provide the following parameters:
	o Total number of LSP updates		o Total number of LSP updates
	skipping to change at page 44, line 38 ¶		skipping to change at page 45, line 36 ¶
	(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,
	May 2008.		May 2008.
	[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",		[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",
	RFC 5284, August 2008.		RFC 5284, August 2008.
	[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element		[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
	(PCE) Communication Protocol (PCEP)", RFC 5440,		(PCE) Communication Protocol (PCEP)", RFC 5440, March
	March 2009.		2009.
	[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax		[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
	Used to Form Encoding Rules in Various Routing Protocol		Used to Form Encoding Rules in Various Routing Protocol
	Specifications", RFC 5511, April 2009.		Specifications", RFC 5511, April 2009.
	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 a Stateful Path
	Computation Element (PCE)",		Computation Element (PCE)", draft-ietf-pce-stateful-pce-
	draft-ietf-pce-stateful-pce-app-01 (work in progress),		app-02 (work in progress), June 2014.
	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 Label Switched Path State		and D. Dhody, "Optimizations of Label Switched Path State
	Synchronization Procedures for a Stateful PCE",		Synchronization Procedures for a Stateful PCE", draft-
	draft-minei-pce-stateful-sync-optimizations-01 (work in		minei-pce-stateful-sync-optimizations-02 (work in
	progress), December 2013.		progress), March 2014.
	[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-
	draft-sivabalan-pce-disco-stateful-03 (work in progress),		stateful-03 (work in progress), January 2014.
	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
	Information Infrastructure Symposium, July 2007.		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",		and throughput objectives in traffic engineering",
	INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012.		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.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031, January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,		[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
	Christian, B., and W. Lai, "Applicability Statement for		Christian, B., and W. Lai, "Applicability Statement for
	Traffic Engineering with MPLS", RFC 3346, August 2002.		Traffic Engineering with MPLS", RFC 3346, August 2002.
	[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering		[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
	(TE) Extensions to OSPF Version 2", RFC 3630,		(TE) Extensions to OSPF Version 2", RFC 3630, September
	September 2003.		2003.
	[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, August 2006.		Element (PCE)-Based Architecture", RFC 4655, August 2006.
	[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)		[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
	Communication Protocol Generic Requirements", RFC 4657,		Communication Protocol Generic Requirements", RFC 4657,
	September 2006.		September 2006.
	[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic		[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
	Engineering", RFC 5305, October 2008.		Engineering", RFC 5305, October 2008.
	skipping to change at page 46, line 27 ¶		skipping to change at page 47, line 27 ¶
	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
			Ina Minei
			Google, Inc.
			1600 Amphitheatre Parkway
			Mountain View, CA 94043
			US
			Email: inaminei@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
	Google, Inc.
	1600 Amphitheatre Parkway
	Mountain View, CA 94043
	US
	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. 53 change blocks.
	166 lines changed or deleted		233 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/