draft-ietf-pce-segment-routing-00.txt		draft-ietf-pce-segment-routing-01.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: April 29, 2015 Cisco Systems, Inc.		Expires: September 10, 2015 Cisco Systems, Inc.
	E. Crabbe
	Google, Inc.
	R. Raszuk		R. Raszuk
	NTT I3		Mirantis Inc.
	V. Lopez		V. Lopez
	Telefonica I+D		Telefonica I+D
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	October 26, 2014		W. Henderickx
			Alcatel Lucent
			E. Crabbe
			March 9, 2015
	PCEP Extensions for Segment Routing		PCEP Extensions for Segment Routing
	draft-ietf-pce-segment-routing-00.txt		draft-ietf-pce-segment-routing-01.txt
	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 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 29, 2015.		This Internet-Draft will expire on September 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 3, line 8 ¶		skipping to change at page 3, line 8 ¶
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 14		9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 14
	9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 14		9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 14
	9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 15		9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 15
	9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 15		9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 15
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	12.1. Normative References . . . . . . . . . . . . . . . . . . 15		12.1. Normative References . . . . . . . . . . . . . . . . . . 16
	12.2. Informative References . . . . . . . . . . . . . . . . . 17		12.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	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
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	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 described 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.sivabalan-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
	IGP: Interior Gateway Protocol		IGP: Interior Gateway Protocol
	IS-IS: Intermediate System to Intermediate System		IS-IS: Intermediate System to Intermediate System
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 32 ¶
	subobject, a new TLV, and new PCEP error codes.		subobject, a new TLV, and new PCEP error codes.
	o Specifies how two PCEP speakers can establish a PCEP session that		o Specifies how two PCEP speakers can establish a PCEP session that
	can carry information about SR-TE paths.		can carry information about SR-TE paths.
	o Specifies processing rules of ERO subobject.		o Specifies processing rules of ERO subobject.
	o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV		o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV
	for SR-TE LSP.		for SR-TE LSP.
	The extensions specified in this document are applicable to the		The extensions specified in this document complement the existing
	stateless PCE model defined in [RFC5440], as well as for the active		PCEP specifications to support SR-TE path. As such, the PCEP
	stateful and passive stateful PCE models defined in		messages (e.g., Path Computation Request, Path Computation Reply,
	[I-D.ietf-pce-stateful-pce].		Path Computation Report, Path Computation Update, Path Computation
			Initiate, etc.,) MUST be formatted according to [RFC5440],
			[I-D.ietf-pce-stateful-pce], [I-D.ietf-pce-pce-initiated-lsp], and
			any other applicable PCEP specifications.
	4. SR-Specific PCEP Message Extensions		4. SR-Specific PCEP Message Extensions
	As defined in [RFC5440], a PCEP message consists of a common header		As defined in [RFC5440], a PCEP message consists of a common header
	followed by a variable length body made up of mandatory and/or		followed by a variable length body made up of mandatory and/or
	optional objects. This document does not require any changes in the		optional objects. This document does not require any changes in the
	format of PCReq and PCRep messages specified in [RFC5440], PCInitiate		format of PCReq and PCRep messages specified in [RFC5440], PCInitiate
	message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and		message specified in [I-D.ietf-pce-pce-initiated-lsp], and PCRpt and
	PCUpd messages specified in [I-D.ietf-pce-stateful-pce]. However,		PCUpd messages specified in [I-D.ietf-pce-stateful-pce]. However,
	PCEP messages pertaining to SR-TE LSP MUST include PATH-SETUP-TYPE		PCEP messages pertaining to SR-TE LSP MUST include PATH-SETUP-TYPE
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 19 ¶
	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 is
	processed.		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.sivabalan-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.
	5.3. ERO Object		5.3. ERO Object
	An SR-TE path consists of one or more SID(s) where each SID MAY be		An SR-TE path consists of one or more SID(s) where each SID MAY be
	associated with the identifier that represents the node or adjacency		associated with the identifier that represents the node or adjacency
	corresponding to the SID. This identifier is referred to as the		corresponding to the SID. This identifier is referred to as the
	'Node or Adjacency Identifier' (NAI). As described later, a NAI can		'Node or Adjacency Identifier' (NAI). As described later, a NAI can
	be represented in various formats (e.g., IPv4 address, IPv6 address,		be represented in various formats (e.g., IPv4 address, IPv6 address,
	etc). Furthermore, a NAI is used only for troubleshooting purposes,		etc). Furthermore, a NAI is used for troubleshooting purposes and,
	and MUST NOT be used to replace or modify any fields in a data packet		if necessary, to derive SID value as described below.
	header.
	The ERO object specified in [RFC5440] is used to carry SR-TE path		The ERO object specified in [RFC5440] is used to carry SR-TE path
	information. In order to carry SID and/or NAI, this document defines		information. In order to carry SID and/or NAI, this document defines
	a new ERO subobject referred to as "SR-ERO subobject" whose format is		a new ERO subobject referred to as "SR-ERO subobject" whose format is
	specified in the following section. An ERO object carrying an SR-TE		specified in the following section. An ERO object carrying an SR-TE
	path consists of one or more ERO subobject(s), and MUST carry only		path consists of one or more ERO subobject(s), and MUST carry only
	SR-ERO subobject. Note that an SR-ERO subobject does not need to		SR-ERO subobject. Note that an SR-ERO subobject does not need to
	have both SID and NAI. However, at least one of them MUST be		have both SID and NAI. However, at least one of them MUST be
	present.		present.
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 33 ¶
	A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,		A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,
	PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP		PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP
	message and MUST send a PCE error message with Error-Type=3 ("Unknown		message and MUST send a PCE error message with Error-Type=3 ("Unknown
	Object") and Error-Value=2 ("Unrecognized object Type") or Error-		Object") and Error-Value=2 ("Unrecognized object Type") or Error-
	Type=4 ("Not supported object") and Error-Value=2 ("Not supported		Type=4 ("Not supported object") and Error-Value=2 ("Not supported
	object Type"), defined in [RFC5440].		object Type"), defined in [RFC5440].
	When the SID represents an MPLS label (i.e. the M bit is set), its		When the SID represents an MPLS label (i.e. the M bit is set), its
	value (20 most significant bits) MUST be larger than 15, unless it is		value (20 most significant bits) MUST be larger than 15, unless it is
	special purpose label, such as an Entropy Label Indicator (ELI) or an		special purpose label, such as an Entropy Label Indicator (ELI). If
	Entropy Label (EL). If a PCEP speaker receives a label ERO subobject		a PCEP speaker receives a label ERO subobject with an invalid value,
	with an invalid value, it MUST send the PCE error message with Error-		it MUST send the PCE error message with Error-Type = 10 ("Reception
	Type = 10 ("Reception of an invalid object") and Error Value = TBD		of an invalid object") and Error Value = TBD ("Bad label value"). If
	("Bad label value"). If both M and C bits of an ERO subobject are		both M and C bits of an ERO subobject are set, and if a PCEP speaker
	set, and if a PCEP speaker finds erroneous setting in one or more of		finds erroneous setting in one or more of TC, S, and TTL fields, it
	TC, S, and TTL fields, it MUST send a PCE error with Error-Type = 10		MUST send a PCE error with Error-Type = 10 ("Reception of an invalid
	("Reception of an invalid object") and Error-Value = TBD ("Bad label		object") and Error-Value = TBD ("Bad label format").
	format").
	If a PCC receives a stack of SR-ERO subobjects, and the number of		If a PCC receives a stack of SR-ERO subobjects, and the number of
	stack exceeds the maximum number of SIDs that the PCC can impose on		stack exceeds the maximum number of SIDs that the PCC can impose on
	the packet, it MAY send a PCE error with Error-Type = 10 ("Reception		the packet, it MAY send a PCE error with Error-Type = 10 ("Reception
	of an invalid object") and Error-Value = TBD ("Unsupported number of		of an invalid object") and Error-Value = TBD ("Unsupported number of
	Segment ERO subobjects").		Segment ERO subobjects").
	When a PCEP speaker detects that all subobjects of ERO are not		When a PCEP speaker detects that all subobjects of ERO are not
	identical, and if it cannot handle such ERO, it MUST send PCE error		identical, and if it does not handle such ERO, it MUST send PCE error
	with Error-Type = 10 ("Reception of an invalid object") and Error-		with Error-Type = 10 ("Reception of an invalid object") and Error-
	Value = TBD ("Non-identical ERO subobjects").		Value = TBD ("Non-identical ERO subobjects").
	If a PCEP speaker receives an SR-ERO subobject in which both SID and		If a PCEP speaker receives an SR-ERO subobject in which both SID and
	NAI are absent, it MUST consider the entire ERO object invalid and		NAI are absent, it MUST consider the entire ERO object invalid and
	send a PCE error with Error-Type = 10 ("Reception of an invalid		send a PCE error with Error-Type = 10 ("Reception of an invalid
	object") and Error-Value = TBD ("Both SID and NAI are absent in ERO		object") and Error-Value = TBD ("Both SID and NAI are absent in ERO
	subobject").		subobject").
	5.4. RRO Object		5.4. RRO Object
	A PCC can record SR-TE LSP and report the LSP to a PCE via RRO. An		A PCC can record SR-TE LSP and report the LSP to a PCE via RRO. An
	RRO object contains one or more subobjects called "SR-RRO subobjects"		RRO object contains one or more subobjects called "SR-RRO subobjects"
	whose format is shown below:		whose format is shown below:
	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 | ST | Flags |F|S|		| Type | Length | ST | Flags |F|S|C|M|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SID |		| SID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// NAI (variable) //		// NAI (variable) //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: SR-RRO Subobject format		Figure 6: SR-RRO Subobject format
	The format of SR-RRO subobject is the same as that of SR-ERO		The format of SR-RRO subobject is the same as that of SR-ERO
	subobject without L, C, and M flags. The F and S flags are used with		subobject without L flag.
	the same meaning.
	A PCC MUST assume that SR-RRO subobjects are organized such that the		A PCC MUST assume that SR-RRO subobjects are organized such that the
	first subobject relative to the beginning of RRO contains the		first subobject relative to the beginning of RRO contains the
	information about the topmost label, and the last subobject contains		information about the topmost label, and the last subobject contains
	information about the bottommost label of the SR-TE LSP.		information about the bottommost label of the SR-TE LSP.
	5.4.1. RRO Processing		5.4.1. RRO Processing
	Processing rules of SR-RRO subobject are identical to those of SR-ERO		Processing rules of SR-RRO subobject are identical to those of SR-ERO
	subobject.		subobject.
	If a PCEP speaker receives an SR-RRO subobject in which both SID and		If a PCEP speaker receives an SR-RRO subobject in which both SID and
	NAI are absent, it MUST consider the entire RRO object invalid and		NAI are absent, it MUST consider the entire RRO object invalid and
	send a PCE error with Error-Type = 10 ("Reception of an invalid		send a PCE error with Error-Type = 10 ("Reception of an invalid
	object") and Error-Value = TBD ("Both SID and NAI are absent in RRO		object") and Error-Value = TBD ("Both SID and NAI are absent in RRO
	subobject").		subobject").
			If a PCE detects that all subobjects of RRO are not identical, and if
			it does not handle such RRO, it MUST send PCE error with Error-Type =
			10 ("Reception of an invalid object") and Error-Value = TBD ("Non-
			identical RRO subobjects").
	6. Backward Compatibility		6. Backward Compatibility
	A PCEP speaker that does not support the SR PCEP capability cannot		A PCEP speaker that does not support the SR PCEP capability cannot
	recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a		recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a
	PCEP error with Error-Type = 4 (Not supported object) and Error-Value		PCEP error with Error-Type = 4 (Not supported object) and Error-Value
	= 2 (Not supported object Type) as per [RFC5440].		= 2 (Not supported object Type) as per [RFC5440].
	7. Management Considerations		7. Management Considerations
	7.1. Policy		7.1. Policy
	skipping to change at page 15, line 14 ¶		skipping to change at page 15, line 14 ¶
	Error-value=2: Bad label value.		Error-value=2: Bad label value.
	Error-value=3: Unsupported number of Segment ERO		Error-value=3: Unsupported number of Segment ERO
	subobjects.		subobjects.
	Error-value=4: Bad label format.		Error-value=4: Bad label format.
	Error-value=5: Non-identical ERO subobjects.		Error-value=5: Non-identical ERO subobjects.
	Error-value=6: Both SID and NAI are absent in ERO		Error-value=6: Both SID and NAI are absent in ERO
	subobject.		subobject.
	Error-value=7: Both SID and NAI are absent in RRO		Error-value=7: Both SID and NAI are absent in RRO
	subobject.		subobject.
			Error-value=8: Non-identical RRO subobjects.
	9.3. PCEP TLV Type Indicators		9.3. 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
	-------- ------------------------------------ -----------------		-------- ------------------------------------ -----------------
	26 SR-PCE-CAPABILITY This document		26 SR-PCE-CAPABILITY This document
	9.4. New Path Setup Type		9.4. New Path Setup Type
	skipping to change at page 15, line 43 ¶		skipping to change at page 15, line 44 ¶
	technique.		technique.
	10. Contributors		10. Contributors
	The following people contributed to this document:		The following people contributed to this document:
	- Lakshmi Sharma (Cisco Systems)		- Lakshmi Sharma (Cisco Systems)
	11. Acknowledgements		11. Acknowledgements
	We like to thank Ina Minei, George Swallow, and Marek Zavodsky for		We like to thank Ina Minei, George Swallow, Marek Zavodsky and Tomas
	the valuable comments.		Janciga for the valuable comments.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.filsfils-rtgwg-segment-routing]		[I-D.filsfils-rtgwg-segment-routing]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,		Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
	Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,		Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
	"Segment Routing Architecture", draft-filsfils-rtgwg-		"Segment Routing Architecture", draft-filsfils-rtgwg-
	segment-routing-01 (work in progress), October 2013.		segment-routing-01 (work in progress), October 2013.
	[I-D.ietf-isis-segment-routing-extensions]		[I-D.ietf-isis-segment-routing-extensions]
	skipping to change at page 16, line 24 ¶		skipping to change at page 16, line 25 ¶
	Litkowski, S., and J. Tantsura, "IS-IS Extensions for		Litkowski, S., and J. Tantsura, "IS-IS Extensions for
	Segment Routing", draft-ietf-isis-segment-routing-		Segment Routing", draft-ietf-isis-segment-routing-
	extensions-00 (work in progress), April 2014.		extensions-00 (work in progress), April 2014.
	[I-D.ietf-ospf-segment-routing-extensions]		[I-D.ietf-ospf-segment-routing-extensions]
	Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,		Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
	Shakir, R., Henderickx, W., and J. Tantsura, "OSPF		Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
	Extensions for Segment Routing", draft-ietf-ospf-segment-		Extensions for Segment Routing", draft-ietf-ospf-segment-
	routing-extensions-00 (work in progress), June 2014.		routing-extensions-00 (work in progress), June 2014.
			[I-D.ietf-pce-lsp-setup-type]
			Sivabalan, S., Medved, J., Minei, I., Crabbe, E., and R.
			Varga, "Conveying path setup type in PCEP messages",
			draft-ietf-pce-lsp-setup-type-00 (work in progress),
			October 2014.
	[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-01 (work in		Model", draft-ietf-pce-pce-initiated-lsp-01 (work in
	progress), June 2014.		progress), June 2014.
	[I-D.ietf-pce-pcep-mib]		[I-D.ietf-pce-pcep-mib]
	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.sivabalan-pce-lsp-setup-type]
	Sivabalan, S., Medved, J., Minei, I., Varga, R., and E.
	Crabbe, "LSP setup method in PCEP messages", draft-
	sivabalan-pce-lsp-setup-type-00 (work in progress),
	October 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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, March		(PCE) Communication Protocol (PCEP)", RFC 5440, March
	2009.		2009.
	[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching		[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
	(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic		(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
	Class" Field", RFC 5462, February 2009.		Class" Field", RFC 5462, February 2009.
	skipping to change at page 18, line 12 ¶		skipping to change at page 18, line 12 ¶
	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
	Google, Inc.
	1600 Amphitheatre Parkway
	Mountain View, CA 94043
	US
	Email: edward.crabbe@gmail.com
	Robert Raszuk		Robert Raszuk
	NTT I3		Mirantis Inc.
	101 S. Ellsworth Ave		100-615 National Ave.
	San Mateo, CA 94401		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		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: jeff.tantsura@ericsson.com		Email: jeff.tantsura@ericsson.com
			Wim Henderickx
			Alcatel Lucent
			Copernicuslaan 50
			Antwerp 2018, CA 95134
			BELGIUM
			Email: wim.henderickx@alcatel-lucent.com
			Edward Crabbe
End of changes. 24 change blocks.
	51 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/