< draft-ietf-pce-lsp-setup-type-05.txt		draft-ietf-pce-lsp-setup-type-06.txt >
	PCE Working Group S. Sivabalan		PCE Working Group S. Sivabalan
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track J. Tantsura		Intended status: Standards Track J. Tantsura
	Expires: May 3, 2018 Individual		Expires: May 24, 2018 Individual
	I. Minei		I. Minei
	Google, Inc.		Google, Inc.
	R. Varga		R. Varga
	Pantheon Technologies SRO		Pantheon Technologies SRO
	J. Hardwick		J. Hardwick
	Metaswitch Networks		Metaswitch Networks
	October 30, 2017		November 20, 2017
	Conveying path setup type in PCEP messages		Conveying path setup type in PCEP messages
	draft-ietf-pce-lsp-setup-type-05		draft-ietf-pce-lsp-setup-type-06
	Abstract		Abstract
	A Path Computation Element can compute traffic engineering paths (TE		A Path Computation Element can compute traffic engineering paths (TE
	paths) through a network that are subject to various constraints.		paths) through a network that are subject to various constraints.
	Currently, TE paths are label switched paths (LSPs) which are set up		Currently, TE paths are label switched paths (LSPs) which are set up
	using the RSVP-TE signaling protocol. However, other TE path setup		using the RSVP-TE signaling protocol. However, other TE path setup
	methods are possible within the PCE architecture. This document		methods are possible within the PCE architecture. This document
	proposes an extension to PCEP to allow support for different path		proposes an extension to PCEP to allow support for different path
	setup methods over a given PCEP session.		setup methods over a given PCEP session.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 https://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 May 3, 2018.		This Internet-Draft will expire on May 24, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 3		3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
	4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6.2. New Path Setup Type Registry . . . . . . . . . . . . . . 6		7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 7
	6.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 6		7.2. New Path Setup Type Registry . . . . . . . . . . . . . . 8
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6		7.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. Normative References . . . . . . . . . . . . . . . . . . . . 6		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
			10.1. Normative References . . . . . . . . . . . . . . . . . . 9
			10.2. Informative References . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	[RFC5440] describes the Path Computation Element Protocol (PCEP) for		[RFC5440] describes the Path Computation Element Protocol (PCEP) for
	communication between a Path Computation Client (PCC) and a Path		communication between a Path Computation Client (PCC) and a Path
	Control Element (PCE) or between one a pair of PCEs. A PCC requests		Computation Element (PCE), or between a PCE and a PCE. A PCC
	a path subject to various constraints and optimization criteria from		requests a path subject to various constraints and optimization
	a PCE. The PCE responds to the PCC with a hop-by-hop path in an		criteria from a PCE. The PCE responds to the PCC with a hop-by-hop
	Explicit Route Object (ERO). The PCC uses the ERO to set up the path		path in an Explicit Route Object (ERO). The PCC uses the ERO to set
	in the network.		up the path in the network.
	[I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a		[RFC8231] specifies extensions to PCEP that allow a PCC to delegate
	PCC to delegate its LSPs to a PCE. The PCE can then update the state		its LSPs to a PCE. The PCE can then update the state of LSPs
	of LSPs delegated to it. In particular, the PCE may modify the path		delegated to it. In particular, the PCE may modify the path of an
	of an LSP by sending a new ERO. The PCC uses this ERO to re-route		LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP
	the LSP in a make-before-break fashion.		in a make-before-break fashion. [I-D.ietf-pce-pce-initiated-lsp]
	[I-D.ietf-pce-pce-initiated-lsp] specifies a mechanism allowing a PCE		specifies a mechanism allowing a PCE to dynamically instantiate an
	to dynamically instantiate an LSP on a PCC by sending the ERO and		LSP on a PCC by sending the ERO and characteristics of the LSP. The
	characteristics of the LSP. The PCC signals the LSP using the ERO		PCC creates the LSP using the ERO and other attributes sent by the
	and other attributes sent by the PCE.		PCE.
	So far, the PCEP protocol and its extensions implicitly assume that		So far, PCEP and its extensions have assumed that the TE paths are
	the TE paths are label switched, and are established via the RSVP-TE		label switched and are established via the RSVP-TE protocol.
	protocol. However, other methods of LSP setup are not precluded.		However, other methods of LSP setup are possible in the PCE
	When a new path setup method (other than RSVP-TE) is introduced for		architecture (see [RFC4655] and [RFC4657]). This document introduces
	setting up a path, a new capability TLV pertaining to the new path		a TLV called "PATH-SETUP-TYPE-CAPABILITY" which allows a PCEP speaker
	setup method MAY be advertised when the PCEP session is established.		to announce the path setup types it supports when the PCEP session is
	Such capability TLV MUST be defined in the specification of the new		established. When a new path setup type (other than RSVP-TE) is
	path setup type. When multiple path setup methods are deployed in a		introduced for setting up a path, a path setup type code and,
	network, a given PCEP session may have to simultaneously support more		optionally, a sub-TLV pertaining to the new path setup type will be
	than one path setup types. In this case, the intended path setup		defined by the document that specifies the new path setup type.
	method needs to be either explicitly indicated or implied in the
	appropriate PCEP messages (when necessary) so that both the PCC and		When multiple path setup types are deployed in a network, a given
	the PCE can take the necessary steps to set up the path. This		PCEP session may have to simultaneously support more than one path
	document introduces a generic TLV called "PATH-SETUP-TYPE TLV" and		setup type. In this case, the intended path setup type needs to be
	specifies the base procedures to facilitate such operational model.		either explicitly indicated or implied in the appropriate PCEP
			messages (when necessary) so that both the PCC and the PCE can take
			the necessary steps to set up the path. This document introduces a
			generic TLV called "PATH-SETUP-TYPE TLV" and specifies the base
			procedures to facilitate this operational model.
	2. Terminology		2. Terminology
	The following terminologies are used in this document:		The following terminologies are used in this document:
	ERO: Explicit Route Object.		ERO: Explicit Route Object.
	LSR: Label Switching Router.		LSR: Label Switching Router.
	PCC: Path Computation Client.		PCC: Path Computation Client.
	PCE: Path Computation Element		PCE: Path Computation Element.
	PCEP: Path Computation Element Protocol.		PCEP: Path Computation Element Protocol.
			PST: Path Setup Type.
	TLV: Type, Length, and Value.		TLV: Type, Length, and Value.
	3. Path Setup Type TLV		3. Path Setup Type Capability TLV
			A PCEP speaker indicates which PSTs it supports during the PCEP
			Initialization phase, as follows. When the PCEP session is created,
			it sends an Open message with an OPEN object containing the PATH-
			SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type (TBD1) | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Reserved | PST length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// List of PSTs (variable) //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// Optional sub-TLVs (variable) //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV
			The TLV type is TBD1 (to be assigned by IANA). Its reserved field
			MUST be set to zero. The other fields in the TLV are as follows.
			PST length: The length of the list of supported PSTs, in octets,
			excluding padding.
			List of PSTs: A list of the PSTs that the PCEP speaker supports.
			Each PST is a single octet in length. Duplicate entries in this
			list MUST be ignored. The PCEP speaker MUST pad the list with
			zeros so that it is a muliple of four octets in length.
			Optional sub-TLVs: A list of sub-TLVs associated with the supported
			PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined
			in ([RFC5440]). That is, each sub-TLV MUST be padded to a four
			byte alignment, and the length field of each sub-TLV MUST NOT
			include the padding bytes. This document does not define any sub-
			TLVs.
			This document defines the following PST value:
			o PST = 0: Path is setup using the RSVP-TE signaling protocol.
			The overall TLV length MUST be equal to the size of the appended sub-
			TLVs plus the PST length (rounded up to the nearest multiple of four)
			plus four bytes for the reserved field and PST length field. The PST
			length field MUST be greater than zero. If a PCEP speaker receives a
			PATH-SETUP-TYPE-CAPABILITY TLV which violates these rules, then the
			PCEP speaker MUST send a PCErr message with Error-Type = 10
			(Reception of an invalid object) and Error-Value = 11 (Malformed
			object) and MUST close the PCEP session. The PCEP speaker MAY
			include the malformed OPEN object in the PCErr message as well.
			If a PCEP speaker receives an OPEN object with more than one PATH-
			SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first
			instance of this TLV.
			The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN
			object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a
			single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. It is
			RECOMMENDED that a PCEP speaker omits the PATH-SETUP-TYPE-CAPABILITY
			TLV if the only PST it supports is RSVP-TE. If a PCEP speaker
			supports other PSTs besides RSVP-TE, then it SHOULD include the PATH-
			SETUP-TYPE-CAPABILITY TLV in its OPEN object.
			If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
			TLV, it MUST ignore the TLV in accordance with ([RFC5440]). If a
			PCEP speaker recognizes the TLV but does not support the TLV, it MUST
			send a PCErr message with Error-Type = 2 (Capability not supported)
			and MUST close the PCEP session.
			4. Path Setup Type TLV
	When a PCEP session is used to set up TE paths using different		When a PCEP session is used to set up TE paths using different
	methods, the corresponding PCE and PCC must be aware of the path		methods, the corresponding PCE and PCC must be aware of the path
	setup method used. That means, a PCE must be able to specify paths		setup method used. That means, a PCE must be able to specify paths
	in the correct format and a PCC must be able take control and take		in the correct format and a PCC must be able take control plane and
	forwarding plane actions appropriate to the path setup type.		forwarding plane actions appropriate to the PST.
	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 | Length |		| Type (28) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | PST |		| Reserved | PST |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: PATH-SETUP-TYPE TLV		Figure 2: PATH-SETUP-TYPE TLV
	PATH-SETUP-TYPE TLV is an optional TLV associated with the RP		PATH-SETUP-TYPE TLV is an optional TLV associated with the RP
	([RFC5440]) and the SRP ([I-D.ietf-pce-stateful-pce]) objects. Its		([RFC5440]) and the SRP ([RFC8231]) objects. Its format is shown in
	format is shown in the above figure. The type of the TLV is to be		the above figure. The TLV type is 28. Its reserved field MUST be
	defined by IANA. The one octet value contains the Path Setup Type		set to zero. The one octet value contains the PST as defined for the
	(PST). This document specifies the following PST value:		PATH-SETUP-TYPE-CAPABILITY TLV.
	o PST = 0: Path is setup via RSVP-TE signaling protocol(default).
	The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH-		The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP-
	SETUP-TYPE TLV with an PST value of 0. It is recommended to omit the		TYPE TLV with a PST value of 0 (RSVP-TE). It is RECOMMENDED that a
	TLV in the default case. If the RP or SRP object contains more than		PCEP speaker omits the TLV if the PST is RSVP-TE. If the RP or SRP
	one PATH-SETUP-TYPE TLVs, only the first TLV MUST be processed and		object contains more than one PATH-SETUP-TYPE TLV, only the first TLV
	the rest MUST be ignored.		MUST be processed and the rest MUST be ignored.
	If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST		If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST
	ignore the TLV in accordance with ([RFC5440]). If a PCEP speaker		ignore the TLV in accordance with ([RFC5440]). If a PCEP speaker
	recognizes the TLV but does not support the TLV, it MUST send PCErr		recognizes the TLV but does not support the TLV, it MUST send PCErr
	with Error-Type = 2 (Capability not supported).		with Error-Type = 2 (Capability not supported).
	4. Operation		5. Operation
	When requesting a path from a PCE using a PCReq message ([RFC5440]),		During the PCEP Initialization phase, if a PCEP speaker receives a
	a PCC MAY include the PATH-SETUP-TYPE TLV in the RP object. If the		PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST infer that the
	PCE is capable of expressing the path in a format appropriate to the		peer suports only the PSTs listed in the TLV. If the PCEP speaker
	setup method used, it MUST use the appropriate ERO format in the		and its peer have no PSTs in common, then the PCEP speaker MUST send
	PCRep message. If the path setup type cannot be inferred from the		a PCErr message with Error-Type = 21 (Invalid traffic engineering
	ERO or any other object or TLV in the PCRep message, PATH-SETUP-TYPE		path setup type) and Error-Value = 2 (Mismatched path setup type) and
	TLV may be included in the RP object of the PCRep message.		close the PCEP session.
	Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE
	does not support the intended path setup type it MUST send PCErr with
	Error-Type = TBD (Traffic engineering path setup error) (recommended
	value is 21) and Error-Value = 1 (Unsupported path setup type) and
	close the PCEP session. If the path setup types corresponding to the
	PCReq and PCRep messages do not match, the PCC MUST send a PCErr with
	Error-Type = 21 (Traffic engineering path setup error) and Error-
	Value = 2 (Mismatched path setup type) and close the PCEP session.
	In the case of stateful PCE, if the path setup type cannot be		If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
	unambiguously inferred from ERO or any other object or TLV, PATH-		speaker MUST infer that the peer supports path setup using at least
	SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages. If PATH-		RSVP-TE. The PCEP speaker MAY also infer that the peer supports
	SETUP-TYPE TLV is used in PCRpt message, the SRP object MUST be		other path setup types, but the means of inference are outside the
	present even in cases when the SRP-ID-number is the reserved value of		scope of this document.
	0x00000000. Regardless of whether PATH-SETUP-TYPE TLV is used or
	not, if a PCRpt message is triggered due to a PCUpd message (in this
	case SRP-ID-number is not equal to 0x00000000), the path setup types
	corresponding to the PCRpt and PCUpd messages should match.
	Otherwise, the PCE MUST send PCErr with Error-Type = 21 (Traffic
	engineering path setup error) and Error-Value = 2 (Mismatched path
	setup type) and close the connection.
	In the case of PCE initiated LSPs, a PCE MAY include PATH-SETUP-TYPE		When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST
	TLV in PCInitiate message if the message does not have any other		include the PATH-SETUP-TYPE TLV in the RP object, unless the intended
	means of indicating path setup type. If a PCC does not support the		PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.
	path setup type associated with the PCInitiate message, the PCC MUST		If the PCE is capable of expressing the path in a format appropriate
	send PCErr with Error-Type = 21 (Traffic engineering path setup		to the intended PST, it MUST use the appropriate ERO format in the
	error) and Error-Value = 1 (Unsupported path setup type) and close		PCRep message.
	the PCEP session. Similarly, as mentioned above, if the path setup
	type cannot be unambiguously inferred from ERO or any other object or
	TLV, the PATH-SETUP-TYPE TLV MAY be included in PCRpt messages
	triggered by PCInitiate message. Regardless of whether PATH-SETUP-
	TYPE TLV is used or not, if a PCRpt message is triggered by a
	PCInitiate message, the path setup types corresponding to the PCRpt
	and the PCInitiate messages should match. Otherwise, the PCE MUST
	send PCErr message with Error-Type = 21 (Traffic engineering path
	setup error) and Error-Value = 2 (Mismatched path setup type).
	5. Security Considerations		When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST
			include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is
			RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the
			PCE does not support the intended PST, it MUST send a PCErr message
			with Error-Type = 21 (Invalid traffic engineering path setup type)
			and Error-Value = 1 (Unsupported path setup type) and close the PCEP
			session. If the PSTs corresponding to the PCReq and PCRep messages
			do not match, the PCC MUST send a PCErr message with Error-Type = 21
			(Invalid traffic engineering path setup type) and Error-Value = 2
			(Mismatched path setup type) and close the PCEP session.
	No additional security measure is required.		When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate
			message ([I-D.ietf-pce-pce-initiated-lsp]) to a PCC, it MUST include
			the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is
			RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the
			PCC does not support the PST associated with the PCUpd or PCInitiate
			message, it MUST send a PCErr message with Error-Type = 21 (Invalid
			traffic engineering path setup type) and Error-Value = 1 (Unsupported
			path setup type) and close the PCEP session.
	6. IANA Considerations		When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it
			MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the
			PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.
			The PCC MUST include the SRP object in the PCRpt message if the PST
			is not RSVP-TE, even when the SRP-ID-number is the reserved value of
			0x00000000. If the PCRpt message is triggered by a PCUpd or
			PCInitiate message, then the PST that the PCC indicates in the PCRpt
			MUST match the PST that the stateful PCE intended in the PCUpd or
			PCInitiate. If it does not, then the PCE MUST send a PCErr message
			with Error-Type = 21 (Invalid traffic engineering path setup type)
			and Error-Value = 2 (Mismatched path setup type) and close the PCEP
			session.
	6.1. PCEP TLV Type Indicators		6. Security Considerations
	IANA is requested to allocate a new code point in the PCEP TLV Type		The security considerations described in [RFC5440] and
	Indicators registry, as follows:		[I-D.ietf-pce-pce-initiated-lsp] are applicable to this
			specification. No additional security measure is required.
	Value Description Reference		7. IANA Considerations
	TBD (recommended 28) PATH-SETUP-TYPE This document		7.1. PCEP TLV Type Indicators
	6.2. New Path Setup Type Registry		IANA is requested to confirm the early allocation of the following
			code point in the PCEP TLV Type Indicators registry.
			Value Description Reference
			28 PATH-SETUP-TYPE This document
			IANA is requested to allocate a new code point for the following TLV
			in the PCEP TLV Type Indicators registry.
			Value Description Reference
			TBD1 PATH-SETUP-TYPE-CAPABILITY This document
			Note to IANA: The above TLV type was not part of the early code point
			allocation that was done for this draft. It was added to the draft
			after the early code point allocation had taken place. Please assign
			a code point from the indicated registry and replace each instance of
			"TBD1" in this document with the allocated code point.
			7.2. New Path Setup Type Registry
	IANA is requested to create a new sub-registry within the "Path		IANA is requested to create a new sub-registry within the "Path
	Computation Element Protocol (PCEP) Numbers" registry called "PATH-		Computation Element Protocol (PCEP) Numbers" registry called "PCEP
	SETUP-TYPE TLV PST Field". The allocation policy for this new		Path Setup Types". The allocation policy for this new registry
	registry should be by IETF Consensus. The new registry should		should be by IETF Consensus. The new registry should contain the
	contain the following value:		following value:
	Value Description Reference		Value Description Reference
	0 Traffic engineering path is This document		0 Path is setup using the RSVP- This document
	setup using RSVP signaling		TE signaling protocol.
	protocol
	6.3. PCEP-Error Object		7.3. PCEP-Error Object
	IANA is requested to allocate code-points in the PCEP-ERROR Object		IANA is requested to confirm the early allocation of the following
	Error Types and Values registry for a new error-type and the		code-points in the PCEP-ERROR Object Error Types and Values registry.
	following new error-values:
			Error-Type Meaning
			10 Reception of an invalid object
			Error-value=11: Malformed object
	Error-Type Meaning		Error-Type Meaning
	21 Invalid traffic engineering path setup type		21 Invalid traffic engineering path setup type
	Error-value=0: Unassigned		Error-value=0: Unassigned
	Error-value=1: Unsupported path setup type		Error-value=1: Unsupported path setup type
	Error-value=2: Mismatched path setup type		Error-value=2: Mismatched path setup type
	7. Contributors		Note to IANA: the early allocation for Error-Type=10, Error-value=11
			was originally done by draft-ietf-pce-segment-routing. However, we
			have since moved its definition into this document. Therefore,
			please update the reference for this Error-value in the indicated
			registry to point to RFC.ietf-pce-lsp-setup-type.
			8. Contributors
	The following people contributed to this document:		The following people contributed to this document:
	- Jan Medved		- Jan Medved
	- Edward Crabbe		- Edward Crabbe
	8. Acknowledgements		9. Acknowledgements
	We like to thank Marek Zavodsky for valuable comments.		We like to thank Marek Zavodsky for valuable comments.
	9. Normative References		10. References
			10.1. Normative References
	[I-D.ietf-pce-pce-initiated-lsp]		[I-D.ietf-pce-pce-initiated-lsp]
	Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP		Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
	Extensions for PCE-initiated LSP Setup in a Stateful PCE		Extensions for PCE-initiated LSP Setup in a Stateful PCE
	Model", draft-ietf-pce-pce-initiated-lsp-09 (work in		Model", draft-ietf-pce-pce-initiated-lsp-11 (work in
	progress), March 2017.		progress), October 2017.
	[I-D.ietf-pce-stateful-pce]
	Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
	Extensions for Stateful PCE", draft-ietf-pce-stateful-
	pce-18 (work in progress), December 2016.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation		[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,		Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009,		DOI 10.17487/RFC5440, March 2009, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5440>.		editor.org/info/rfc5440>.
	Authors' Addresses		[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
			Computation Element Communication Protocol (PCEP)
			Extensions for Stateful PCE", RFC 8231,
			DOI 10.17487/RFC8231, September 2017, <https://www.rfc-
			editor.org/info/rfc8231>.
			10.2. Informative References
			[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
			Element (PCE)-Based Architecture", RFC 4655,
			DOI 10.17487/RFC4655, August 2006, <https://www.rfc-
			editor.org/info/rfc4655>.
			[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
			Element (PCE) Communication Protocol Generic
			Requirements", RFC 4657, DOI 10.17487/RFC4657, September
			2006, <https://www.rfc-editor.org/info/rfc4657>.
			Authors' Addresses
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	2000 Innovation Drive		2000 Innovation Drive
	Kanata, Ontario K2K 3E8		Kanata, Ontario K2K 3E8
	Canada		Canada
	Email: msiva@cisco.com		Email: msiva@cisco.com
	Jeff Tantsura		Jeff Tantsura
	Individual		Individual
	skipping to change at page 7, line 49 ¶		skipping to change at page 10, line 31 ¶
	USA		USA
	Email: inaminei@google.com		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: nite@hq.sk
	Jon Hardwick		Jon Hardwick
	Metaswitch Networks		Metaswitch Networks
	100 Church Street		100 Church Street
	Enfield, Middlesex		Enfield, Middlesex
	UK		UK
	Email: jon.hardwick@metaswitch.com		Email: jonathan.hardwick@metaswitch.com
End of changes. 44 change blocks.
	142 lines changed or deleted		272 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/