< draft-ietf-pce-segment-routing-07.txt		draft-ietf-pce-segment-routing-08.txt >
	Network Working Group S. Sivabalan		Network Working Group S. Sivabalan
	Internet-Draft J. Medved		Internet-Draft J. Medved
	Intended status: Standards Track C. Filsfils		Intended status: Standards Track C. Filsfils
	Expires: September 22, 2016 Cisco Systems, Inc.		Expires: April 7, 2017 Cisco Systems, Inc.
	E. Crabbe		E. Crabbe
			Oracle
	R. Raszuk		R. Raszuk
	Mirantis Inc.		Mirantis Inc.
	V. Lopez		V. Lopez
	Telefonica I+D		Telefonica I+D
	J. Tantsura		J. Tantsura
	Ericsson		Individual
	W. Henderickx		W. Henderickx
	Alcatel Lucent		Nokia
	J. Hardwick		J. Hardwick
	Metaswitch Networks		Metaswitch Networks
	March 21, 2016		October 4, 2016
	PCEP Extensions for Segment Routing		PCEP Extensions for Segment Routing
	draft-ietf-pce-segment-routing-07.txt		draft-ietf-pce-segment-routing-08
	Abstract		Abstract
	Segment Routing (SR) enables any head-end node to select any path		Segment Routing (SR) enables any head-end node to select any path
	without relying on a hop-by-hop signaling technique (e.g., LDP or		without relying on a hop-by-hop signaling technique (e.g., LDP or
	RSVP-TE). It depends only on "segments" that are advertised by Link-		RSVP-TE). It depends only on "segments" that are advertised by Link-
	State Interior Gateway Protocols (IGPs). A Segment Routed Path can		State Interior Gateway Protocols (IGPs). A Segment Routed Path can
	be derived from a variety of mechanisms, including an IGP Shortest		be derived from a variety of mechanisms, including an IGP Shortest
	Path Tree (SPT), explicit configuration, or a Path Computation		Path Tree (SPT), explicit configuration, or a Path Computation
	Element (PCE). This document specifies extensions to the Path		Element (PCE). This document specifies extensions to the Path
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	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 September 22, 2016.		This Internet-Draft will expire on April 7, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5		3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5
	4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 7		4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 7
	5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7		5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7		5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7
	5.1.1. The SR PCE Capability TLV . . . . . . . . . . . . . . 7		5.1.1. The SR PCE Capability TLV . . . . . . . . . . . . . . 7
	5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8		5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9
	5.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 8		5.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 9
	5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9		5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9
	5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 11		5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 11
	5.3.3. ERO Processing . . . . . . . . . . . . . . . . . . . 12		5.3.3. ERO Processing . . . . . . . . . . . . . . . . . . . 13
	5.4. RRO Object . . . . . . . . . . . . . . . . . . . . . . . 13		5.4. RRO Object . . . . . . . . . . . . . . . . . . . . . . . 14
	5.4.1. RRO Processing . . . . . . . . . . . . . . . . . . . 14		5.4.1. RRO Processing . . . . . . . . . . . . . . . . . . . 14
	5.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 14		5.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 15
	6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15		6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15
	7. Management Considerations . . . . . . . . . . . . . . . . . . 15		7. Management Considerations . . . . . . . . . . . . . . . . . . 15
	7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 15		7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 15		7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16		9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16
	9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16		9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16
	9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 17		9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 17
	9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17		9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17
	9.5. New Metric Type . . . . . . . . . . . . . . . . . . . . . 17		9.5. New Metric Type . . . . . . . . . . . . . . . . . . . . . 17
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	12.1. Normative References . . . . . . . . . . . . . . . . . . 18		12.1. Normative References . . . . . . . . . . . . . . . . . . 18
	12.2. Informative References . . . . . . . . . . . . . . . . . 19		12.2. Informative References . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	SR technology leverages the source routing and tunneling paradigms.		SR technology leverages the source routing and tunneling paradigms.
	A source node can choose a path without relying on hop-by-hop		A source node can choose a path without relying on hop-by-hop
	signaling protocols such as LDP or RSVP-TE. Each path is specified		signaling protocols such as LDP or RSVP-TE. Each path is specified
	as a set of "segments" advertised by link-state routing protocols		as a set of "segments" advertised by link-state routing protocols
	(IS-IS or OSPF). [I-D.filsfils-rtgwg-segment-routing] provides an		(IS-IS or OSPF). [I-D.filsfils-rtgwg-segment-routing] provides an
	introduction to SR architecture. The corresponding IS-IS and OSPF		introduction to SR architecture. The corresponding IS-IS and OSPF
	extensions are specified in		extensions are specified in
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 41 ¶
	by a link-state routing protocols, e.g. an IGP prefix or an IGP		by a link-state routing protocols, e.g. an IGP prefix or an IGP
	adjacency. Several types of segments are defined. A Node segment		adjacency. Several types of segments are defined. A Node segment
	represents an ECMP-aware shortest-path computed by IGP to a specific		represents an ECMP-aware shortest-path computed by IGP to a specific
	node, and is always global within SR/IGP domain. An Adjacency		node, and is always global within SR/IGP domain. An Adjacency
	Segment represents unidirectional adjacency. An Adjacency Segment is		Segment represents unidirectional adjacency. An Adjacency Segment is
	local to the node which advertises it. Both Node segments and		local to the node which advertises it. Both Node segments and
	Adjacency segments can be used for SR Traffic Engineering (SR-TE).		Adjacency segments can be used for SR Traffic Engineering (SR-TE).
	The SR architecture can be applied to the MPLS forwarding plane		The SR architecture can be applied to the MPLS forwarding plane
	without any change, in which case an SR path corresponds to an MPLS		without any change, in which case an SR path corresponds to an MPLS
	Label Switching Path (LSP). This document is relevant to only MPLS		Label Switching Path (LSP). This document is relevant to MPLS
	forwarding plane, and assumes that a 32-bit Segment Identifier (SID)		forwarding plane only and assumes that a 32-bit Segment Identifier
	represents an absolute value of MPLS label entry. In this document,		(SID) represents an absolute value of MPLS label entry. In this
	"Node-SID" and "Adjacency-SID" denote Node Segment Identifier and		document, "Node-SID" and "Adjacency-SID" denote Node Segment
	Adjacency Segment Identifier respectively.		Identifier and Adjacency Segment Identifier respectively.
	A Segment Routed path (SR path) can be derived from an IGP Shortest		A Segment Routed path (SR path) can be derived from an IGP Shortest
	Path Tree (SPT). SR-TE paths may not follow IGP SPT. Such paths may		Path Tree (SPT). SR-TE paths may not follow IGP SPT. Such paths may
	be chosen by a suitable network planning tool and provisioned on the		be chosen by a suitable network planning tool and provisioned on the
	source node of the SR-TE path.		ingress node of the SR-TE path.
	[RFC5440] describes Path Computation Element Protocol (PCEP) for		[RFC5440] describes 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
	Computation Element (PCE) or between one a pair of PCEs. A PCE or a		Computation Element (PCE) or between one a pair of PCEs. A PCE or a
	PCC operating as a PCE (in hierarchical PCE environment) computes		PCC operating as a PCE (in hierarchical PCE environment) computes
	paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on		paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on
	various constraints and optimization criteria.		various constraints and optimization criteria.
	[I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a		[I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a
	stateful PCE to compute and recommend network paths in compliance		stateful PCE to compute and recommend network paths in compliance
	with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs.		with [RFC4657] and defines objects and TLVs for MPLS-TE LSPs.
	Stateful PCEP extensions provide synchronization of LSP state between		Stateful PCEP extensions provide synchronization of LSP state between
	a PCC and a PCE or between a pair of PCEs, delegation of LSP control,		a PCC and a PCE or between a pair of PCEs, delegation of LSP control,
	reporting of LSP state from a PCC to a PCE, controlling the setup and		reporting of LSP state from a PCC to a PCE, controlling the setup and
	path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions		path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions
	are intended for an operational model in which LSPs are configured on		are intended for an operational model in which LSPs are configured on
	the PCC, and control over them is delegated to the PCE.		the PCC, and control over them is delegated to the PCE.
	A mechanism to dynamically initiate LSPs on a PCC based on the		A mechanism to dynamically initiate LSPs on a PCC based on the
	requests from a stateful PCE or a controller using stateful PCE is		requests from a stateful PCE or a controller using stateful PCE is
	specified in [I-D.ietf-pce-pce-initiated-lsp]. Such mechanism is		specified in [I-D.ietf-pce-pce-initiated-lsp]. Such mechanism is
	useful in Software Driven Networks (SDN) applications, such as demand		useful in Software Driven Networks (SDN) applications, such as on
	engineering, or bandwidth calendaring.		demand engineering, or bandwidth calendaring.
	It is possible to use a stateful PCE for computing one or more SR-TE		It is possible to use a stateful PCE for computing one or more SR-TE
	paths taking into account various constraints and objective		paths taking into account various constraints and objective
	functions. Once a path is chosen, the stateful PCE can initiate an		functions. Once a path is chosen, the stateful PCE can initiate an
	SR-TE path on a PCC using PCEP extensions specified in		SR-TE path on a PCC using PCEP extensions specified in
	[I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP		[I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP
	extensions described in this document. Additionally, using		extensions specified in this document. Additionally, using
	procedures described in this document, a PCC can request an SR path		procedures described in this document, a PCC can request an SR path
	from either stateful or a stateless PCE. This specification relies		from either stateful or a stateless PCE. This specification relies
	on the PATH-SETUP-TYPE TLV and procedures specified in		on the PATH-SETUP-TYPE TLV and procedures specified in
	[I-D.ietf-pce-lsp-setup-type].		[I-D.ietf-pce-lsp-setup-type].
	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
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	node/adjacency represented by the SID. SR-capable PCEP speakers		node/adjacency represented by the SID. SR-capable PCEP speakers
	should be able to generate and/or process such ERO subobject. An ERO		should be able to generate and/or process such ERO subobject. An ERO
	containing SR-ERO subobjects can be included in the PCEP Path		containing SR-ERO subobjects can be included in the PCEP Path
	Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP		Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP
	Initiate Request message (PCInitiate) defined in		Initiate Request message (PCInitiate) defined in
	[I-D.ietf-pce-pce-initiated-lsp], as well as in the PCEP LSP Update		[I-D.ietf-pce-pce-initiated-lsp], as well as in the PCEP LSP Update
	Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in		Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in
	defined in [I-D.ietf-pce-stateful-pce].		defined in [I-D.ietf-pce-stateful-pce].
	When a PCEP session between a PCC and a PCE is established, both PCEP		When a PCEP session between a PCC and a PCE is established, both PCEP
	speakers exchange information to indicate their ability to support		speakers exchange their capabilites to indicate their ability to
	SR-specific functionality. Furthermore, an LSP initially established		support SR-specific functionality. Furthermore, an LSP initially
	via RSVP-TE signaling can be updated with SR-TE path. This		established via RSVP-TE signaling can be updated with SR-TE path.
	capability is useful when a network is migrated from RSVP-TE to SR-TE		This capability is useful when a network is migrated from RSVP-TE to
	technology. Similarly, an LSP initially created with SR-TE path can		SR-TE technology. Similarly, an LSP initially created with SR-TE
	updated to signal the LSP using RSVP-TE if necessary.		signaling can be updated using RSVP-TE if necessary.
	A PCC MAY include an RRO object containing the recorded LSP in PCReq		A PCC MAY include an RRO object containing the recorded LSP in PCReq
	and PCRpt messages as specified in [RFC5440] and		and PCRpt messages as specified in [RFC5440] and
	[I-D.ietf-pce-stateful-pce] respectively. This document defines a		[I-D.ietf-pce-stateful-pce] respectively. This document defines a
	new RRO subobject for SR networks. Methods used by a PCC to record		new RRO subobject for SR networks. Methods used by a PCC to record
	SR-TE LSP are outside the scope of this document.		SR-TE LSP are outside the scope of this document.
	In summary, this document:		In summary, this document:
	o Defines a new PCEP capability, new ERO subobject, new RRO		o Defines a new PCEP capability, new ERO subobject, new RRO
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 36 ¶
	The SR-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN		The SR-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN
	Object to exchange SR capability of PCEP speakers. The format of the		Object to exchange SR capability of PCEP speakers. The format of the
	SR-PCE-CAPABILITY TLV is shown in the following figure:		SR-PCE-CAPABILITY TLV is shown in the following 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=4 |		| Type=TBD | Length=4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved | Flags | MSD |		| Reserved | Flags |L| MSD |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: SR-PCE-CAPABILITY TLV format		Figure 1: SR-PCE-CAPABILITY TLV format
	The code point for the TLV type is to be defined by IANA. The TLV		The code point for the TLV type is to be defined by IANA. The TLV
	length is 4 octets.		length is 4 octets.
	The 32-bit value is formatted as follows. The "Maximum SID Depth" (1		The 32-bit value is formatted as follows. The "Maximum SID Depth" (1
	octet) field (MSD) specifies the maximum number of SIDs that a PCC is		octet) field (MSD) specifies the maximum number of SIDs (MPLS label
	capable of imposing on a packet. The "Flags" (1 octet) and		stack depth in context of this document) that a PCC is capable of
	"Reserved" (2 octets) fields are currently unused, and MUST be set to		imposing on a packet. The "Reserved" (2 octets) field is unused, and
	zero on transmission and ignored on reception.		MUST be set to zero on transmission and ignored on reception. The
			"Flags" field is 1 octect long, and this document defines the
			following flag:
			o L-flag: A PCC sets this flag to 1 to indicate that it does not
			impose any limit on MSD.
	5.1.1.1. Exchanging SR Capability		5.1.1.1. Exchanging SR Capability
	By including the SR-PCE-CAPABILITY TLV in the OPEN message destined		By including the SR-PCE-CAPABILITY TLV in the OPEN message destined
	to a PCE, a PCC indicates that it is capable of supporting the head-		to a PCE, a PCC indicates that it is capable of supporting the head-
	end functions for SR-TE LSP. By including the TLV in the OPEN		end functions for SR-TE LSP. By including the TLV in the OPEN
	message destined to a PCC, a PCE indicates that it is capable of		message destined to a PCC, a PCE indicates that it is capable of
	computing SR-TE paths.		computing SR-TE paths.
	The number of SIDs that can be imposed on a packet depends on PCC's		The number of SIDs that can be imposed on a packet depends on PCC's
	data plane's capability. An MSD value of zero means that a PCC does		data plane's capability. An MSD value MUST be non-zero otherwise the
	not impose any default limitation on the number of SIDs included in		receiver of the SR-PCE-CAPABILITY TLV MUST assume that the sender is
	any SR-TE path coming from PCE. Once an SR-capable PCEP session is		not capable of imposing a MSD of any depth and hence is not SR-TE
	established with a non-zero MSD value, the corresponding PCE MUST NOT		capable.
	send SR-TE paths with SIDs exceeding that MSD value. If a PCC needs
	to modify the MSD value, the PCEP session MUST be closed and re-		Note that the MSD value exchanged via SR-PCE-CAPABILITY TLV indicates
	established with the new MSD value. If a PCEP session is established		the SID/label imposition limit for the PCC node. However, if a PCE
	with a non-zero MSD value, and the PCC receives an SR-TE path		learns MSD value of a PCC node via different means, e.g routing
	containing more SIDs than specified in the MSD value, the PCC MUST		protocols, as specified in: [I-D.tantsura-isis-segment-routing-msd];
	send a PCErr message with Error-Type 10 (Reception of an invalid		[I-D.tantsura-ospf-segment-routing-msd];
	object) and Error-Value 3 (Unsupported number of Segment ERO). If a		[I-D.tantsura-idr-bgp-ls-segment-routing-msd], then it ignores the
	PCEP session is established with an MSD value of zero, then the PCC		MSD value in the SR-PCE-CAPABILITY TLV. Furthermore, whenever a PCE
	MAY specify an MSD for each path computation request that it sends to		learns MSD for a link via different means, it MUST use that value for
	the PCE.		that link regardless of the MSD value exchanged via SR-PCE-CAPABILITY
			TLV.
			Once an SR-capable PCEP session is established with a non-zero MSD
			value, the corresponding PCE MUST NOT send SR-TE paths with number of
			SIDs exceeding that MSD value. If a PCC needs to modify the MSD
			value, the PCEP session MUST be closed and re-established with the
			new MSD value. If a PCEP session is established with a non-zero MSD
			value, and the PCC receives an SR-TE path containing more SIDs than
			specified in the MSD value, the PCC MUST send a PCErr message with
			Error-Type 10 (Reception of an invalid object) and Error-Value 3
			(Unsupported number of Segment ERO). If a PCEP session is
			established with an MSD value of zero, then the PCC MAY specify an
			MSD for each path computation request that it sends to the PCE.
	The SR Capability TLV is meaningful only in the OPEN message sent		The SR Capability TLV is meaningful only in the OPEN message sent
	from a PCC to a PCE. As such, a PCE does not need to set MSD value		from a PCC to a PCE. As such, a PCE does not need to set MSD value
	in outbound message to a PCC. Similarly, a PCC ignores any MSD value		in outbound message to a PCC. Similarly, a PCC ignores any MSD value
	received from a PCE. If a PCE receives multiple SR-PCE-CAPABILITY		received from a PCE. If a PCE receives multiple SR-PCE-CAPABILITY
	TLVs in an OPEN message, it processes only the first TLV is		TLVs in an OPEN message, it processes only the first TLV received.
	processed.
	5.2. The RP/SRP Object		5.2. The RP/SRP Object
	In order to setup an SR-TE LSP using SR, RP or SRP object MUST PATH-		In order to setup an SR-TE LSP using SR, RP or SRP object MUST PATH-
	SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This		SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This
	document defines a new Path Setup Type (PST) for SR as follows:		document defines a new Path Setup Type (PST) for SR as follows:
	o PST = 1: Path is setup using Segment Routing Traffic Engineering		o PST = 1: Path is setup using Segment Routing Traffic Engineering
	technique.		technique.
	skipping to change at page 18, line 48 ¶		skipping to change at page 19, line 16 ¶
	Koushik, K., Stephan, E., Zhao, Q., King, D., and J.		Koushik, K., Stephan, E., Zhao, Q., King, D., and J.
	Hardwick, "PCE communication protocol (PCEP) Management		Hardwick, "PCE communication protocol (PCEP) Management
	Information Base", draft-ietf-pce-pcep-mib-04 (work in		Information Base", draft-ietf-pce-pcep-mib-04 (work in
	progress), February 2013.		progress), February 2013.
	[I-D.ietf-pce-stateful-pce]		[I-D.ietf-pce-stateful-pce]
	Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP		Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
	Extensions for Stateful PCE", draft-ietf-pce-stateful-		Extensions for Stateful PCE", draft-ietf-pce-stateful-
	pce-05 (work in progress), July 2013.		pce-05 (work in progress), July 2013.
			[I-D.tantsura-idr-bgp-ls-segment-routing-msd]
			Tantsura, J., Mirsky, G., Sivabalan, S., and U. Chunduri,
			"Signaling Maximum SID Depth using Border Gateway Protocol
			Link-State", draft-tantsura-idr-bgp-ls-segment-routing-
			msd-01 (work in progress), July 2016.
			[I-D.tantsura-isis-segment-routing-msd]
			Tantsura, J. and U. Chunduri, "Signaling MSD (Maximum SID
			Depth) using IS-IS", draft-tantsura-isis-segment-routing-
			msd-01 (work in progress), July 2016.
			[I-D.tantsura-ospf-segment-routing-msd]
			Tantsura, J. and U. Chunduri, "Signaling MSD (Maximum SID
			Depth) using OSPF", draft-tantsura-ospf-segment-routing-
			msd-01 (work in progress), September 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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-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,
	<http://www.rfc-editor.org/info/rfc5440>.		<http://www.rfc-editor.org/info/rfc5440>.
	skipping to change at page 20, line 19 ¶		skipping to change at page 21, line 4 ¶
	Email: jmedved@cisco.com		Email: jmedved@cisco.com
	Clarence Filsfils		Clarence Filsfils
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Pegasus Parc		Pegasus Parc
	De kleetlaan 6a, DIEGEM BRABANT 1831		De kleetlaan 6a, DIEGEM BRABANT 1831
	BELGIUM		BELGIUM
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	Edward Crabbe		Edward Crabbe
			Oracle
			1501 4th Ave, suite 1800
			Seattle, WA 98101
			USA
			Email: edward.crabbe@oracle.com
	Robert Raszuk		Robert Raszuk
	Mirantis Inc.		Mirantis Inc.
	100-615 National Ave.		100-615 National Ave.
	Mountain View, CA 94043		Mountain View, CA 94043
	US		US
	Email: robert@raszuk.net		Email: robert@raszuk.net
	Victor Lopez		Victor Lopez
	Telefonica I+D		Telefonica I+D
	Don Ramon de la Cruz 82-84		Don Ramon de la Cruz 82-84
	Madrid 28045		Madrid 28045
	Spain		Spain
	Email: vlopez@tid.es		Email: vlopez@tid.es
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Individual
	300 Holger Way		444 San Antonio Rd, 10A
	San Jose, CA 95134		Palo Alto, CA 94306
	USA		USA
	Email: jeff.tantsura@ericsson.com		Email: jefftant.ietf@gmail.com
	Wim Henderickx		Wim Henderickx
	Alcatel Lucent		Nokia
	Copernicuslaan 50		Copernicuslaan 50
	Antwerp 2018, CA 95134		Antwerp 2018, CA 95134
	BELGIUM		BELGIUM
	Email: wim.henderickx@alcatel-lucent.com		Email: wim.henderickx@alcatel-lucent.com
	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: jon.hardwick@metaswitch.com
End of changes. 30 change blocks.
	62 lines changed or deleted		100 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/