< draft-ietf-spring-segment-routing-04.txt		draft-ietf-spring-segment-routing-05.txt >
	Network Working Group C. Filsfils, Ed.		Network Working Group C. Filsfils, Ed.
	Internet-Draft S. Previdi, Ed.		Internet-Draft S. Previdi, Ed.
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: February 1, 2016 B. Decraene		Expires: March 23, 2016 B. Decraene
	S. Litkowski		S. Litkowski
	Orange		Orange
	R. Shakir		R. Shakir
	Individual		Individual
	July 31, 2015		September 20, 2015
	Segment Routing Architecture		Segment Routing Architecture
	draft-ietf-spring-segment-routing-04		draft-ietf-spring-segment-routing-05
	Abstract		Abstract
	Segment Routing (SR) leverages the source routing paradigm. A node		Segment Routing (SR) leverages the source routing paradigm. A node
	steers a packet through an ordered list of instructions, called		steers a packet through an ordered list of instructions, called
	segments. A segment can represent any instruction, topological or		segments. A segment can represent any instruction, topological or
	service-based. A segment can have a local semantic to an SR node or		service-based. A segment can have a local semantic to an SR node or
	global within an SR domain. SR allows to enforce a flow through any		global within an SR domain. SR allows to enforce a flow through any
	topological path and service chain while maintaining per-flow state		topological path and service chain while maintaining per-flow state
	only at the ingress node to the SR domain.		only at the ingress node to the SR domain.
	Segment Routing can be directly applied to the MPLS architecture with		Segment Routing can be directly applied to the MPLS architecture with
	no change on the forwarding plane. A segment is encoded as an MPLS		no change on the forwarding plane. A segment is encoded as an MPLS
	label. An ordered list of segments is encoded as a stack of labels.		label. An ordered list of segments is encoded as a stack of labels.
	The segment to process is on the top of the stack. Upon completion		The segment to process is on the top of the stack. Upon completion
	of a segment, the related label is popped from the stack.		of a segment, the related label is popped from the stack.
	Segment Routing can be applied to the IPv6 architecture, with a new		Segment Routing can be applied to the IPv6 architecture, with a new
	type of routing extension header. A segment is encoded as an IPv6		type of routing header. A segment is encoded as an IPv6 address. An
	address. An ordered list of segments is encoded as an ordered list		ordered list of segments is encoded as an ordered list of IPv6
	of IPv6 addresses in the routing extension header. The segment to		addresses in the routing header. The active segment is indicated by
	process is indicated by a pointer in the routing extension header.		the Destination Address of the packet. The next active segment is
	Upon completion of a segment, the pointer is incremented.		indicated by a pointer in the new routing header.
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [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 February 1, 2016.		This Internet-Draft will expire on March 23, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 5		1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7		3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7
	3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . . 7		3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 7
	3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . . 7		3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7
	3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . . 9		3.2.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 7
	3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . . 9		3.2.2. MPLS Dataplane . . . . . . . . . . . . . . . . . . . 8
	3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . . 12		3.2.3. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . 9
	3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . . 13		3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 10
	3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . . 14		3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 10
	3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 14		3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 13
	3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . . 14		3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 14
	3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . . 15		3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 15
	3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 15		3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 16
	4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . . 16		3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 16
	5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17		3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 17
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17		5. IGP Mirroring Context Segment . . . . . . . . . . . . . . . 18
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	10.2. Informative References . . . . . . . . . . . . . . . . . . 18		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
			11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
			11.1. Normative References . . . . . . . . . . . . . . . . . . 20
			11.2. Informative References . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	With Segment Routing (SR), a node steers a packet through an ordered		With Segment Routing (SR), a node steers a packet through an ordered
	list of instructions, called segments. A segment can represent any		list of instructions, called segments. A segment can represent any
	instruction, topological or service-based. A segment can have a		instruction, topological or service-based. A segment can have a
	local semantic to an SR node or global within an SR domain. SR		local semantic to an SR node or global within an SR domain. SR
	allows to enforce a flow through any path and service chain while		allows to enforce a flow through any path and service chain while
	maintaining per-flow state only at the ingress node of the SR domain.		maintaining per-flow state only at the ingress node of the SR domain.
	skipping to change at page 4, line 34 ¶		skipping to change at page 3, line 44 ¶
	o an IGP segment,		o an IGP segment,
	o a BGP Peering segments,		o a BGP Peering segments,
	o an LDP LSP segment,		o an LDP LSP segment,
	o an RSVP-TE LSP segment,		o an RSVP-TE LSP segment,
	o a BGP LSP segment.		o a BGP LSP segment.
	The first two (IGP and BGP Peering segments) types of segments		The first two (IGP and BGP Peering segments) types of segments are
	defined in this document. The use of the last three types of		defined in this document. The use of the last three types of
	segments is illustrated in [I-D.ietf-spring-segment-routing-mpls].		segments is illustrated in [I-D.ietf-spring-segment-routing-mpls].
	Segment Routing can be applied to the IPv6 architecture (RFC2460),		Segment Routing can be applied to the IPv6 architecture (RFC2460),
	with a new type of routing extension header. A segment is encoded as		with a new type of routing header. A segment is encoded as an IPv6
	an IPv6 address. An ordered list of segments is encoded as an		address. An ordered list of segments is encoded as an ordered list
	ordered list of IPv6 addresses in the routing extension header. The		of IPv6 addresses in the routing header. The active segment is
	active segment is indicated by a pointer in the routing extension		indicated by the Destination Address of the packet. Upon completion
	header. Upon completion of a segment, the pointer is incremented. A		of a segment, a pointer in the new routing header is incremented and
	segment can be inserted in the list and the pointer is updated		indicates the next segment.
	accordingly.
	Numerous use-cases illustrate the benefits of source routing either		Numerous use-cases illustrate the benefits of source routing either
	for FRR, OAM or Traffic Engineering reasons.		for FRR, OAM or Traffic Engineering reasons.
	This document defines a set of instructions (called segments) that		This document defines a set of instructions (called segments) that
	are required to fulfill the described use-cases. These segments can		are required to fulfill the described use-cases. These segments can
	either be used in isolation (one single segment defines the source		either be used in isolation (one single segment defines the source
	route of the packet) or in combination (these segments are part of an		route of the packet) or in combination (these segments are part of an
	ordered list of segments that define the source route of the packet).		ordered list of segments that define the source route of the packet).
	1.1. Companion Documents		1.1. Companion Documents
	This document defines the SR architecture, its routing model, the		This document defines the SR architecture, its routing model, the
	IGP-based segments, the BGP-based segments and the service segments.		IGP-based segments, the BGP-based segments and the service segments.
	Use cases are described in [I-D.ietf-spring-problem-statement],		Use cases are described in [I-D.ietf-spring-problem-statement],
	[I-D.filsfils-spring-segment-routing-central-epe],		[I-D.filsfils-spring-segment-routing-central-epe],
	[I-D.filsfils-spring-segment-routing-msdc],		[I-D.filsfils-spring-segment-routing-msdc],
			[I-D.filsfils-spring-large-scale-interconnect],
	[I-D.ietf-spring-ipv6-use-cases],		[I-D.ietf-spring-ipv6-use-cases],
	[I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase]		[I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase]
	and [I-D.kumar-spring-sr-oam-requirement].		and [I-D.ietf-spring-sr-oam-requirement].
	Segment Routing for MPLS dataplane is documented in		Segment Routing for MPLS dataplane is documented in
	[I-D.ietf-spring-segment-routing-mpls].		[I-D.ietf-spring-segment-routing-mpls].
	Segment Routing for IPv6 dataplane is documented in		Segment Routing for IPv6 dataplane is documented in
	[I-D.previdi-6man-segment-routing-header].		[I-D.previdi-6man-segment-routing-header].
	IGP protocol extensions for Segment Routing are described in		IGP protocol extensions for Segment Routing are described in
	[I-D.ietf-isis-segment-routing-extensions],		[I-D.ietf-isis-segment-routing-extensions],
	[I-D.ietf-ospf-segment-routing-extensions] and		[I-D.ietf-ospf-segment-routing-extensions] and
	[I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this		[I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this
	document as "IGP SR extensions documents".		document as "IGP SR extensions documents".
	The FRR solution for SR is documented in		The FRR solution for SR is documented in
	[I-D.francois-spring-segment-routing-ti-lfa].		[I-D.francois-rtgwg-segment-routing-ti-lfa].
	The PCEP protocol extensions for Segment Routing are defined in		The PCEP protocol extensions for Segment Routing are defined in
	[I-D.ietf-pce-segment-routing].		[I-D.ietf-pce-segment-routing].
	The interaction between SR/MPLS with other MPLS Signaling planes is		The interaction between SR/MPLS with other MPLS Signaling planes is
	documented in [I-D.filsfils-spring-segment-routing-ldp-interop].		documented in [I-D.filsfils-spring-segment-routing-ldp-interop].
	2. Terminology		2. Terminology
	Segment: an instruction a node executes on the incoming packet (e.g.:		Segment: an instruction a node executes on the incoming packet (e.g.:
	forward packet according to shortest path to destination, or, forward		forward packet according to shortest path to destination, or, forward
	packet through a specific interface, or, deliver the packet to a		packet through a specific interface, or, deliver the packet to a
	given application/service instance).		given application/service instance).
	SID: a Segment Identifier		SID: a Segment Identifier. Examples of SIDs are: a MPLS label, an
			index value in a MPLS label space, an IPv6 address. Other types of
			SIDs can be defined in the future.
	Segment List: ordered list of SID's encoding the topological and		Segment List: ordered list of SID's encoding the topological and
	service source route of the packet. It is a stack of labels in the		service source route of the packet. It is a stack of labels in the
	MPLS architecture. It is an ordered list of IPv6 addresses in the		MPLS architecture. It is an ordered list of IPv6 addresses in the
	IPv6 architecture.		IPv6 architecture.
	Active segment: the segment that MUST be used by the receiving router		Active segment: the segment that MUST be used by the receiving router
	to process the packet. It is identified by a pointer in the IPv6		to process the packet. In the MPLS dataplane is the top label. In
	architecture. It is the top label in the MPLS architecture.		the IPv6 dataplane is the destination address of a packet having the
			Segment Routing Header as defined in
			[I-D.previdi-6man-segment-routing-header].
	PUSH: the insertion of a segment at the head of the Segment list.		PUSH: the insertion of a segment at the head of the Segment list.
	NEXT: the active segment is completed, the next segment becomes		NEXT: the active segment is completed, the next segment becomes
	active.		active.
	CONTINUE: the active segment is not completed and hence remains		CONTINUE: the active segment is not completed and hence remains
	active. The CONTINUE instruction is implemented as the SWAP		active. The CONTINUE instruction is implemented as the SWAP
	instruction in the MPLS dataplane.		instruction in the MPLS dataplane. In IPv6, this is the plain IPv6
			forwarding action of a regular IPv6 packet according to its
			Destination Address.
	SR Global Block (SRGB): local property of an SR node. In the MPLS		SR Global Block (SRGB): local property of an SR node. In the MPLS
	architecture, SRGB is the set of local labels reserved for global		architecture, SRGB is the set of local labels reserved for global
	segments. In the IPv6 architecture, it is the set of locally		segments. Using the same SRGB on all nodes within the SR domain ease
	relevant IPv6 addresses. Using the same SRGB on all nodes within the		operations and troubleshooting and is expected to be a deployment
	SR domain ease operations and troubleshooting and is expected to be a		guideline. In the IPv6 architecture, the equivalent of the SRGB is
	deployment guideline.		in fact the set of addresses used as global segments. Since there
			are no restrictions on which IPv6 address can be used, the concept of
			the SRGB includes all IPv6 global address space used within the SR
			domain.
	Global Segment: the related instruction is supported by all the SR-		Global Segment: the related instruction is supported by all the SR-
	capable nodes in the domain. In the MPLS architecture, a Global		capable nodes in the domain. In the MPLS architecture, a Global
	Segment has a globally-unique index. The related local label at a		Segment has a globally-unique index. The related local label at a
	given node N is found by adding the globally-unique index to the SRGB		given node N is found by adding the globally-unique index to the SRGB
	of node N. In the IPv6 architecture, a global segment is a globally-		of node N. In the IPv6 architecture, a global segment is a globally-
	unique IPv6 address.		unique IPv6 address.
	Local Segment: the related instruction is supported only by the node		Local Segment: the related instruction is supported only by the node
	originating it. In the MPLS architecture, this is a local label		originating it. In the MPLS architecture, this is a local label
	outside the SRGB. In the IPv6 architecture, this is a link-local		outside the SRGB. In the IPv6 architecture, this can be any IPv6
	address.		address whose reachability is not advertised in any routing protocol
			(hence, the segment is known only by the local node).
	IGP Segment: the generic name for a segment attached to a piece of		IGP Segment: the generic name for a segment attached to a piece of
	information advertised by a link-state IGP, e.g. an IGP prefix or an		information advertised by a link-state IGP, e.g. an IGP prefix or an
	IGP adjacency.		IGP adjacency.
	IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP		IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP
	segment attached to an IGP prefix. An IGP-Prefix Segment is always		segment attached to an IGP prefix. An IGP-Prefix Segment is global
	global within the SR/IGP domain and identifies an instruction to		(unless explicitly advertised otherwise) within the SR IGP instance/
	forward the packet over the ECMP-aware shortest-path computed by the		topology and identifies an instruction to forward the packet along
	IGP to the related prefix. The Prefix-SID is the SID of the IGP-		the path computed using the algorithm field, in the topology and the
	Prefix Segment.		IGP instance where it is advertised. The Prefix-SID is the SID of
			the IGP-Prefix Segment.
	IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which		IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which
	does not identify a specific router, but a set of routers. The terms		does not identify a specific router, but a set of routers. The terms
	"Anycast Segment" or "Anycast-SID" are often used as an abbreviation.		"Anycast Segment" or "Anycast-SID" are often used as an abbreviation.
	IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to		IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to
	an unidirectional adjacency or a set of unidirectional adjacencies.		an unidirectional adjacency or a set of unidirectional adjacencies.
	By default, an IGP-Adjacency Segment is local (unless explicitly		By default, an IGP-Adjacency Segment is local (unless explicitly
	advertised otherwise) to the node that advertises it.		advertised otherwise) to the node that advertises it.
	skipping to change at page 7, line 27 ¶		skipping to change at page 6, line 50 ¶
	implicitly via a set of abstract constraints (latency, affinity,		implicitly via a set of abstract constraints (latency, affinity,
	SRLG, ...). In the latter case, a constraint-based path computation		SRLG, ...). In the latter case, a constraint-based path computation
	is used to determine the list of segments associated with the tunnel.		is used to determine the list of segments associated with the tunnel.
	The computation can be local or delegated to a PCE server. An SR		The computation can be local or delegated to a PCE server. An SR
	tunnel can be configured by the operator, provisioned via netconf or		tunnel can be configured by the operator, provisioned via netconf or
	provisioned via PCEP. An SR tunnel can be used for traffic-		provisioned via PCEP. An SR tunnel can be used for traffic-
	engineering, OAM or FRR reasons.		engineering, OAM or FRR reasons.
	Segment List Depth: the number of segments of an SR tunnel. The		Segment List Depth: the number of segments of an SR tunnel. The
	entity instantiating an SR Tunnel at a node N should be able to		entity instantiating an SR Tunnel at a node N should be able to
	discover the depth insertion capability of the node N. The PCEP		discover the depth insertion capability of the node N. The PCEP
	discovery capability is described in [I-D.ietf-pce-segment-routing].		discovery capability is described in [I-D.ietf-pce-segment-routing].
	3. Link-State IGP Segments		3. Link-State IGP Segments
	Within a link-state IGP domain, an SR-capable IGP node advertises		Within a link-state IGP domain, an SR-capable IGP node advertises
	segments for its attached prefixes and adjacencies. These segments		segments for its attached prefixes and adjacencies. These segments
	are called IGP segments or IGP SIDs. They play a key role in Segment		are called IGP segments or IGP SIDs. They play a key role in Segment
	Routing and use-cases as they enable the expression of any		Routing and use-cases as they enable the expression of any
	topological path throughout the IGP domain. Such a topological path		topological path throughout the IGP domain. Such a topological path
	is either expressed as a single IGP segment or a list of multiple IGP		is either expressed as a single IGP segment or a list of multiple IGP
	skipping to change at page 7, line 49 ¶		skipping to change at page 7, line 24 ¶
	3.1. IGP Segment, IGP SID		3.1. IGP Segment, IGP SID
	The terms "IGP Segment" and "IGP SID" are the generic names for a		The terms "IGP Segment" and "IGP SID" are the generic names for a
	segment attached to a piece of information advertised by a link-state		segment attached to a piece of information advertised by a link-state
	IGP, e.g. an IGP prefix or an IGP adjacency.		IGP, e.g. an IGP prefix or an IGP adjacency.
	3.2. IGP-Prefix Segment, Prefix-SID		3.2. IGP-Prefix Segment, Prefix-SID
	An IGP-Prefix Segment is an IGP segment attached to an IGP prefix.		An IGP-Prefix Segment is an IGP segment attached to an IGP prefix.
	An IGP-Prefix Segment is always global within the SR/IGP domain and		An IGP-Prefix Segment is global (unless explicitly advertised
	identifies the ECMP-aware shortest-path computed by the IGP to the		otherwise) within the SR/IGP domain.
	related prefix. The Prefix-SID is the SID of the IGP-Prefix Segment.
			The required IGP protocol extensions are defined in IGP SR extensions
			documents.
			3.2.1. Prefix-SID Algorithm
			The IGP protocol extensions for Segment Routing define the Prefix-SID
			advertisement which includes a set of flags and the algorithm field.
			The algorithm field has the purpose of associating a given Prefix-SID
			to a routing algorithm.
			In the context of an instance and a topology, multiple Prefix-SID's
			MAY be allocated to the same IGP Prefix as long as the algorithm
			value is different in each one.
			Multiple instances and topologies are defined in IS-IS and OSPF in:
			[RFC5120], [RFC6822], [RFC6549] and [RFC4915].
			Initially, two "algorithms" have been defined:
			o "Shortest Path": this algorithm is the default behavior. The
			packet is forwarded along the well known ECMP-aware SPF algorithm
			however it is explicitly allowed for a midpoint to implement
			another forwarding based on local policy.. The "Shortest Path"
			algorithm is in fact the default and current behavior of most of
			the networks where local policies may override the SPF decision.
			o "Strict Shortest Path": This algorithm mandates that the packet is
			forwarded according to ECMP-aware SPF algorithm and instruct any
			router in the path to ignore any possible local policy overriding
			SPF decision. The SID advertised with "Strict Shortest Path"
			algorithm ensures that the path the packet is going to take is the
			expected, and not altered, SPF path.
			An IGP-Prefix Segment identifies the path, to the related prefix,
			along the path computed as per the algorithm field.
	A packet injected anywhere within the SR/IGP domain with an active		A packet injected anywhere within the SR/IGP domain with an active
	Prefix-SID will be forwarded along the shortest-path to that prefix.		Prefix-SID will be forwarded along path computed by the algorithm
			expressed in the algorithm field.
	The IGP signaling extension for IGP-Prefix segment includes a set of		The ingress node of an SR domain validates that the path to a prefix,
	flags. The encoding details of the Prefix-SID and its flags are		advertised with a given algorithm, includes nodes all supporting the
	described in IGP SR extensions documents.		advertised algorithm. In other words, when computing paths for a
			given algorithm, the transit nodes MUST compute the algorithm X on
			the IGP topology, regardless of the support of the algorithm X by the
			nodes in that topology. As a consequence, if a node on the path does
			not support algorithm X, the IGP-Prefix segment will be interrupted
			and will drop packet on that node. It's the responsibility of the
			ingress node using a segment to check that all downstream nodes
			support the algorithm of the segment.
	The IGP signaling extension for IGP-Prefix segment includes the		Details of the two defined algorithms are defined in
	P-Flag. A Node N advertising a Prefix-SID SID-R for its attached		[I-D.ietf-isis-segment-routing-extensions],
	prefix R resets the P-Flag to allow its connected neighbors to		[I-D.ietf-ospf-segment-routing-extensions] and
	perform the NEXT operation while processing SID-R. This behavior is		[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
	equivalent to Penultimate Hop Popping in MPLS. When set, the
	neighbors of N must perform the CONTINUE operation while processing
	SID-R.
	While SR allows to attach a local segment to an IGP prefix (using the		3.2.2. MPLS Dataplane
	L-Flag), we specifically assume that when the terms "IGP-Prefix
	Segment" and "Prefix-SID" are used, the segment is global (the SID is
	allocated from the SRGB). This is consistent with all the described
	use-cases that require global segments attached to IGP prefixes.
	A single Prefix-SID is allocated to an IGP Prefix in a topology.		When SR is used over the MPLS dataplane:
	In the context of multiple topologies, multiple Prefix-SID's MAY be		o the IGP signaling extension for IGP-Prefix segment includes the
	allocated to the same IGP Prefix (e.g.: using the "algorithm" field		P-Flag. A Node N advertising a Prefix-SID SID-R for its attached
	in the IGP advertisement as described in IGP SR extensions		prefix R resets the P-Flag to allow its connected neighbors to
	documents). However, each prefix-SID MUST be associated with only		perform the NEXT operation while processing SID-R. This behavior
	one topology. In other words: a prefix, within a topology, MUST have		is equivalent to Penultimate Hop Popping in MPLS. When set, the
	only a single Prefix-SID.		neighbors of N must perform the CONTINUE operation while
			processing SID-R.
	A Prefix-SID is allocated from the SRGB according to a process		o A Prefix-SID is allocated in the form of an index in the SRGB (or
	similar to IP address allocation. Typically the Prefix-SID is		as a local MPLS label) according to a process similar to IP
	allocated by policy by the operator (or NMS) and the SID very rarely		address allocation. Typically the Prefix-SID is allocated by
	changes.		policy by the operator (or NMS) and the SID very rarely changes.
	The allocation process MUST NOT allocate the same Prefix-SID to		o While SR allows to attach a local segment to an IGP prefix (using
	different IP prefixes.		the L-Flag), we specifically assume that when the terms "IGP-
			Prefix Segment" and "Prefix-SID" are used, the segment is global
			(the SID is allocated from the SRGB or as an index). This is
			consistent with all the described use-cases that require global
			segments attached to IGP prefixes.
	If a node learns a Prefix-SID having a value that falls outside the		o The allocation process MUST NOT allocate the same Prefix-SID to
	locally configured SRGB range, then the node MUST NOT use the Prefix-		different IP prefixes.
	SID and SHOULD issue an error log warning for misconfiguration.
	The required IGP protocol extensions are defined in IGP SR extensions		o If a node learns a Prefix-SID having a value that falls outside
	documents.		the locally configured SRGB range, then the node MUST NOT use the
			Prefix-SID and SHOULD issue an error log warning for
			misconfiguration.
			o A node N attaching a Prefix-SID SID-R to its attached prefix R
			MUST maintain the following FIB entry:
	A node N attaching a Prefix-SID SID-R to its attached prefix R MUST
	maintain the following FIB entry:
	Incoming Active Segment: SID-R		Incoming Active Segment: SID-R
	Ingress Operation: NEXT		Ingress Operation: NEXT
	Egress interface: NULL		Egress interface: NULL
	A remote node M MUST maintain the following FIB entry for any learned		o A remote node M MUST maintain the following FIB entry for any
	Prefix-SID SID-R attached to IP prefix R:		learned Prefix-SID SID-R attached to IP prefix R:
	Incoming Active Segment: SID-R
	Ingress Operation:		Incoming Active Segment: SID-R
	If the next-hop of R is the originator of R		Ingress Operation:
	and instructed to remove the active segment: NEXT		If the next-hop of R is the originator of R
	Else: CONTINUE		and instructed to remove the active segment: NEXT
	Egress interface: the interface towards the next-hop along		Else: CONTINUE
	the shortest-path to prefix R.		Egress interface: the interface towards the next-hop along the
			path computed using the algorithm advertised with
			the SID toward prefix R.
			3.2.3. IPv6 Dataplane
			When SR is used over the IPv6 dataplane:
			o The Prefix-SID is the prefix itself. No additional identifier is
			needed for Segment Routing over IPv6.
			o Any address belonging to any of the node's prefixes can be used as
			Prefix-SIDs.
			o An operator may want to explicitly indicate which of the node's
			prefixes can be used as Prefix-SIDs through the setting of a flag
			(e.g.: using the IGP prefix attribute defined in
			[I-D.ietf-isis-prefix-attributes]) in the routing protocol used
			for advertising the prefix.
			o A global SID is instantiated through any globally advertised IPv6
			address.
			o A local SID is instantiated through a local IPv6 prefix not being
			advertised and therefore known only by the local node.
			A node N advertising an IPv6 address R usable as a segment identifier
			MUST maintain the following FIB entry:
			Incoming Active Segment: R
			Ingress Operation: NEXT
			Egress interface: NULL
			Regardless Segment Routing, any remote IPv6 node will maintain a
			plain IPv6 FIB entry for any prefix, no matter if they represent a
			segment or not.
	3.3. IGP-Node Segment, Node-SID		3.3. IGP-Node Segment, Node-SID
	An IGP-Node Segment is a an IGP-Prefix Segment which identifies a		An IGP Node Segment is a an IGP Prefix Segment which identifies a
	specific router (e.g. a loopback). The N flag is set. The terms		specific router (e.g. a loopback). The terms "Node Segment" or
	"Node Segment" or "Node-SID" are often used as an abbreviation.		"Node-SID" are often used as an abbreviation. The IGP SR extensions
			define a flag that identifies Node-SIDs.
	A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere		A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere
	in the network, it enforces the ECMP-aware shortest-path forwarding		in the network, it enforces the ECMP-aware shortest-path forwarding
	of the packet towards the related node.		of the packet towards the related node.
	An IGP-Node-SID MUST NOT be associated with a prefix that is owned or		An IGP Node-SID MUST NOT be associated with a prefix that is owned by
	advertised by more than one router within the same routing domain.		more than one router within the same routing domain.
	3.4. IGP-Anycast Segment, Anycast SID		3.4. IGP-Anycast Segment, Anycast SID
	An IGP-Anycast Segment is an IGP-prefix segment which does not		An IGP-Anycast Segment is an IGP-prefix segment which does not
	identify a specific router, but a set of routers. The terms "Anycast		identify a specific router, but a set of routers. The terms "Anycast
	Segment" or "Anycast-SID" are often used as an abbreviation.		Segment" or "Anycast-SID" are often used as an abbreviation.
	An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware		An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware
	shortest-path forwarding towards the closest node of the anycast set.		shortest-path forwarding towards the closest node of the anycast set.
	This is useful to express macro-engineering policies or protection		This is useful to express macro-engineering policies or protection
	skipping to change at page 12, line 23 ¶		skipping to change at page 13, line 28 ¶
	An IGP-Adjacency Segment is an IGP segment attached to a		An IGP-Adjacency Segment is an IGP segment attached to a
	unidirectional adjacency or a set of unidirectional adjacencies. By		unidirectional adjacency or a set of unidirectional adjacencies. By
	default, an IGP-Adjacency Segment is local to the node which		default, an IGP-Adjacency Segment is local to the node which
	advertises it. However, an Adjacency Segment can be global if		advertises it. However, an Adjacency Segment can be global if
	advertised by the IGP as such. The SID of the IGP-Adjacency Segment		advertised by the IGP as such. The SID of the IGP-Adjacency Segment
	is called the Adj-SID.		is called the Adj-SID.
	The adjacency is formed by the local node (i.e., the node advertising		The adjacency is formed by the local node (i.e., the node advertising
	the adjacency in the IGP) and the remote node (i.e., the other end of		the adjacency in the IGP) and the remote node (i.e., the other end of
	the adjacency). The local node MUST be an IGP node. The remote node		the adjacency). The local node MUST be an IGP node. The remote node
	MAY be an adjacent IGP neighbor) or a non-adjacent neighbor (e.g.: a		MAY be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a
	Forwarding Adjacency, [RFC4206]).		Forwarding Adjacency, [RFC4206]).
	A packet injected anywhere within the SR domain with a segment list		A packet injected anywhere within the SR domain with a segment list
	{SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID		{SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID
	attached by node N to its adjacency over link L, will be forwarded		attached by node N to its adjacency over link L, will be forwarded
	along the shortest-path to N and then be switched by N, without any		along the shortest-path to N and then be switched by N, without any
	IP shortest-path consideration, towards link L. If the Adj-SID		IP shortest-path consideration, towards link L. If the Adj-SID
	identifies a set of adjacencies, then the node N load- balances the		identifies a set of adjacencies, then the node N load- balances the
	traffic among the various members of the set.		traffic among the various members of the set.
	Similarly, when using a global Adj-SID, a packet injected anywhere		Similarly, when using a global Adj-SID, a packet injected anywhere
	within the SR domain with a segment list {SNL}, where SNL is a global		within the SR domain with a segment list {SNL}, where SNL is a global
	Adj-SID attached by node N to its adjacency over link L, will be		Adj-SID attached by node N to its adjacency over link L, will be
	forwarded along the shortest-path to N and then be switched by N,		forwarded along the shortest-path to N and then be switched by N,
	without any IP shortest-path consideration, towards link L. If the		without any IP shortest-path consideration, towards link L. If the
	Adj-SID identifies a set of adjacencies, then the node N load-		Adj-SID identifies a set of adjacencies, then the node N load-
	balances the traffic among the various members of the set. The use		balances the traffic among the various members of the set. The use
	of global Adj-SID allows to reduce the size of the segment list when		of global Adj-SID allows to reduce the size of the segment list when
	expressing a path at the cost of additional state (i.e.: the global		expressing a path at the cost of additional state (i.e.: the global
	Adj-SID will be inserted by all routers within the area in their		Adj-SID will be inserted by all routers within the area in their
	forwarding table).		forwarding table).
	An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the		An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the
	packet from a node towards a defined interface or set of interfaces.		packet from a node towards a defined interface or set of interfaces.
	This is key to theoretically prove that any path can be expressed as		This is key to theoretically prove that any path can be expressed as
	a list of segments.		a list of segments.
	The encodings of the Adj-SID include the B-flag. When set, the Adj-		The encodings of the Adj-SID include the B-flag. When set, the Adj-
	SID benefits from a local protection.		SID refers to an adjacency that is eligible for protection (e.g.:
			using IPFRR or MPLS-FRR).
	The encodings of the Adj-SID include the L-flag. When set, the Adj-		The encodings of the Adj-SID include the L-flag. When set, the Adj-
	SID has local significance. By default the L-flag is set.		SID has local significance. By default the L-flag is set.
	A node SHOULD allocate one Adj-SIDs for each of its adjacencies.		A node SHOULD allocate one Adj-SIDs for each of its adjacencies.
	A node MAY allocate multiple Adj-SIDs to the same adjacency. An		A node MAY allocate multiple Adj-SIDs to the same adjacency. An
	example is where the adjacency is established over a bundle		example is where the adjacency is established over a bundle
	interface. Each bundle member MAY have its own Adj-SID.		interface. Each bundle member MAY have its own Adj-SID.
	skipping to change at page 13, line 37 ¶		skipping to change at page 14, line 46 ¶
	regardless its IGP/SPF cost. In other words, the use of Adjacency		regardless its IGP/SPF cost. In other words, the use of Adjacency
	Segments overrides the routing decision made by SPF algorithm.		Segments overrides the routing decision made by SPF algorithm.
	3.5.1. Parallel Adjacencies		3.5.1. Parallel Adjacencies
	Adj-SIDs can be used in order to represent a set of parallel		Adj-SIDs can be used in order to represent a set of parallel
	interfaces between two adjacent routers.		interfaces between two adjacent routers.
	A node MUST install a FIB entry for any locally originated Adjacency		A node MUST install a FIB entry for any locally originated Adjacency
	Segment (Adj-SID) of value W attached to a set of link B with:		Segment (Adj-SID) of value W attached to a set of link B with:
	Incoming Active Segment: W		Incoming Active Segment: W
	Ingress Operation: NEXT		Ingress Operation: NEXT
	Egress interface: loadbalance between any data-link within set B		Egress interface: loadbalance between any data-link within set B
	When parallel adjacencies are used and associated to the same Adj-		When parallel adjacencies are used and associated to the same Adj-
	SID, and in order to optimize the load balancing function, a "weight"		SID, and in order to optimize the load balancing function, a "weight"
	factor can be associated to the Adj-SID advertised with each		factor can be associated to the Adj-SID advertised with each
	adjacency. The weight tells the ingress (or a SDN/orchestration		adjacency. The weight tells the ingress (or a SDN/orchestration
	system) about the loadbalancing factor over the parallel adjacencies.		system) about the loadbalancing factor over the parallel adjacencies.
	As shown in Figure 1, A and B are connected through two parallel		As shown in Figure 1, A and B are connected through two parallel
	adjacencies		adjacencies
	link-1
	+--------+		link-1
	| |		+--------+
	S---A B---C		| |
	| |		S---A B---C
	+--------+		| |
	link-2		+--------+
			link-2
	Figure 1: Parallel Links and Adj-SIDs		Figure 1: Parallel Links and Adj-SIDs
	Node A advertises following Adj-SIDs and weights:		Node A advertises following Adj-SIDs and weights:
	o Link-1: Adj-SID 1000, weight: 1		o Link-1: Adj-SID 1000, weight: 1
	o Link-2: Adj-SID 1000, weight: 2		o Link-2: Adj-SID 1000, weight: 2
	Node S receives the advertisements of the parallel adjacencies and		Node S receives the advertisements of the parallel adjacencies and
	skipping to change at page 15, line 14 ¶		skipping to change at page 16, line 24 ¶
	The segment allocation and SRGB Maintenance rules are the same as		The segment allocation and SRGB Maintenance rules are the same as
	those defined for Prefix-SID.		those defined for Prefix-SID.
	3.6.2. Tunnel Headend		3.6.2. Tunnel Headend
	The segment allocation and SRGB Maintenance rules are the same as		The segment allocation and SRGB Maintenance rules are the same as
	those defined for Adj-SID. A tunnel attached to a head-end H acts as		those defined for Adj-SID. A tunnel attached to a head-end H acts as
	an adjacency attached to H.		an adjacency attached to H.
	Note: an alternative would consist in representing tunnels as		Note: an alternative consists of representing tunnels as forwarding-
	forwarding-adjacencies ( [RFC4206]). In such case, the tunnel is		adjacencies ( [RFC4206]). In such case, the tunnel is presented to
	presented to the routing area as a routing adjacency and will be		the routing area as a routing adjacency and is considered as such by
	considered as such by all area routers. The Remote-Binding SID is		all area routers. The Remote-Binding SID is preferred as it allows
	preferred as it allows to advertise the presence of a tunnel without		to advertise the presence of a tunnel without influencing the LSDB
	influencing the LSDB and the SPF computation.		and the SPF computation.
	3.7. Inter-Area Considerations		3.7. Inter-Area Considerations
	In the following example diagram we assume an IGP deployed using		In the following example diagram we assume an IGP deployed using
	areas and where SR has been deployed.		areas and where SR has been deployed.
	! !		! !
	! !		! !
	B------C-----F----G-----K		B------C-----F----G-----K
	/ | | |		/ | | |
	S---A/ | | |		S---A/ | | |
	\ | | |		\ | | |
	\D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150)		\D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150)
	! !		! !
	Area-1 ! Backbone ! Area 2		Area-1 ! Backbone ! Area 2
	! area !		! area !
	Figure 2: Inter-Area Topology Example		Figure 2: Inter-Area Topology Example
	In area 2, node Z allocates Node-SID 150 to his local prefix		In area 2, node Z allocates Node-SID 150 to his local prefix
	192.0.2.1/32. ABRs G and J will propagate the prefix into the		192.0.2.1/32. ABRs G and J will propagate the prefix into the
	backbone area by creating a new instance of the prefix according to		backbone area by creating a new instance of the prefix according to
	normal inter-area/level IGP propagation rules.		normal inter-area/level IGP propagation rules.
	Nodes C and I will apply the same behavior when leaking prefixes from		Nodes C and I will apply the same behavior when leaking prefixes from
	the backbone area down to area 1. Therefore, node S will see prefix		the backbone area down to area 1. Therefore, node S will see prefix
	skipping to change at page 17, line 17 ¶		skipping to change at page 18, line 25 ¶
	* Next-Hop: loadbalance across any connected interface to any		* Next-Hop: loadbalance across any connected interface to any
	peer in the related group.		peer in the related group.
	A peer set could be all the connected peers from the same AS or a		A peer set could be all the connected peers from the same AS or a
	subset of these. A group could also span across AS. The group		subset of these. A group could also span across AS. The group
	definition is a policy set by the operator.		definition is a policy set by the operator.
	The BGP extensions necessary in order to signal these BGP peering		The BGP extensions necessary in order to signal these BGP peering
	segments will be defined in a separate document.		segments will be defined in a separate document.
	5. Multicast		5. IGP Mirroring Context Segment
			It is beneficial for an IGP node to be able to advertise its ability
			to process traffic originally destined to another IGP node, called
			the Mirrored node and identified by an IP address or a Node-SID,
			provided that a "Mirroring Context" segment be inserted in the
			segment list prior to any service segment local to the mirrored node.
			When a given node B wants to provide egress node A protection, it
			advertises a segment identifying node's A context. Such segment is
			called "Mirror Context Segment" and identified by the Mirror SID.
			The Mirror SID is advertised using the Binding Segment defined in SR
			IGP protocol extensions ( [I-D.ietf-isis-segment-routing-extensions],
			[I-D.ietf-ospf-segment-routing-extensions] and
			[I-D.ietf-ospf-ospfv3-segment-routing-extensions]).
			In the event of a failure, a point of local repair (PLR) diverting
			traffic from A to B does a PUSH of the Mirror SID on the protected
			traffic. B, when receiving the traffic with the Mirror SID as the
			active segment, uses that segment and process underlying segments in
			the context of A.
			6. Multicast
	Segment Routing is defined for unicast. The application of the		Segment Routing is defined for unicast. The application of the
	source-route concept to Multicast is not in the scope of this		source-route concept to Multicast is not in the scope of this
	document.		document.
	6. IANA Considerations		7. IANA Considerations
	This document does not require any action from IANA.		This document does not require any action from IANA.
	7. Security Considerations		8. Security Considerations
	This document doesn't introduce new security considerations when		This document doesn't introduce new security considerations when
	applied to the MPLS dataplane.		applied to the MPLS dataplane.
	There are a number of security concerns with source routing at the		There are a number of security concerns with source routing at the
	IPv6 dataplane [RFC5095]. The new IPv6-based segment routing header		IPv6 dataplane [RFC5095]. The new IPv6-based segment routing header
	defined in [I-D.previdi-6man-segment-routing-header] and its		defined in [I-D.previdi-6man-segment-routing-header] and its
	associated security measures address these concerns. The IPv6		associated security measures address these concerns. The IPv6
	Segment Routing Header is defined in a way that blind attacks are		Segment Routing Header is defined in a way that blind attacks are
	never possible, i.e., attackers will be unable to send source routed		never possible, i.e., attackers will be unable to send source routed
	packets that get successfully processed, without being part of the		packets that get successfully processed, without being part of the
	negations for setting up the source routes or being able to eavesdrop		negations for setting up the source routes or being able to eavesdrop
	legitimate source routed packets. In some networks this base level		legitimate source routed packets. In some networks this base level
	security may be complemented with other mechanisms, such as packet		security may be complemented with other mechanisms, such as packet
	filtering, cryptographic security, etc.		filtering, cryptographic security, etc.
	8. Contributors		9. Contributors
	The following people have substantially contributed to the definition		The following people have substantially contributed to the definition
	of the Segment Routing architecture and to the editing of this		of the Segment Routing architecture and to the editing of this
	document:		document:
	Ahmed Bashandy		Ahmed Bashandy
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: bashandy@cisco.com		Email: bashandy@cisco.com
	Martin Horneffer		Martin Horneffer
	Deutsche Telekom		Deutsche Telekom
	Email: Martin.Horneffer@telekom.de		Email: Martin.Horneffer@telekom.de
	Wim Henderickx		Wim Henderickx
	Alcatel-Lucent		Alcatel-Lucent
	Email: wim.henderickx@alcatel-lucent.com		Email: wim.henderickx@alcatel-lucent.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Ericsson
	Email: Jeff.Tantsura@ericsson.com		Email: Jeff.Tantsura@ericsson.com
	Edward Crabbe		Edward Crabbe
	Individual		Individual
	Email: edward.crabbe@gmail.com		Email: edward.crabbe@gmail.com
	Igor Milojevic		Igor Milojevic
	Email: milojevicigor@gmail.com		Email: milojevicigor@gmail.com
	Saku Ytti		Saku Ytti
	TDC		TDC
	Email: saku@ytti.fi		Email: saku@ytti.fi
	9. Acknowledgements		10. Acknowledgements
	We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre		We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
	Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Hannes Gredler		Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Hannes
	and Pushpasis Sarkar for their comments and review of this document.		Gredler, Pushpasis Sarkar, Eric Rosen and Chris Bowers for their
			comments and review of this document.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)		[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
	Hierarchy with Generalized Multi-Protocol Label Switching		Hierarchy with Generalized Multi-Protocol Label Switching
	(GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/		(GMPLS) Traffic Engineering (TE)", RFC 4206,
	RFC4206, October 2005,		DOI 10.17487/RFC4206, October 2005,
	<http://www.rfc-editor.org/info/rfc4206>.		<http://www.rfc-editor.org/info/rfc4206>.
	10.2. Informative References		11.2. Informative References
			[I-D.filsfils-spring-large-scale-interconnect]
			Filsfils, C., Cai, D., Previdi, S., Henderickx, W.,
			Shakir, R., Cooper, D., Ferguson, F., Laberge, T., Lin,
			S., Decraene, B., and L. Jalil, "Interconnecting Millions
			Of Endpoints With Segment Routing", draft-filsfils-spring-
			large-scale-interconnect-00 (work in progress), July 2015.
	[I-D.filsfils-spring-segment-routing-central-epe]		[I-D.filsfils-spring-segment-routing-central-epe]
	Filsfils, C., Previdi, S., Patel, K., Aries, E.,		Filsfils, C., Previdi, S., Patel, K., Shaw, S., Ginsburg,
	shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment		D., and D. Afanasiev, "Segment Routing Centralized Egress
	Routing Centralized Egress Peer Engineering",		Peer Engineering", draft-filsfils-spring-segment-routing-
	draft-filsfils-spring-segment-routing-central-epe-04 (work		central-epe-05 (work in progress), August 2015.
	in progress), July 2015.
	[I-D.filsfils-spring-segment-routing-ldp-interop]		[I-D.filsfils-spring-segment-routing-ldp-interop]
	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 interoperability with LDP",		"Segment Routing interoperability with LDP", draft-
	draft-filsfils-spring-segment-routing-ldp-interop-03 (work		filsfils-spring-segment-routing-ldp-interop-03 (work in
	in progress), March 2015.		progress), March 2015.
	[I-D.filsfils-spring-segment-routing-msdc]		[I-D.filsfils-spring-segment-routing-msdc]
	Filsfils, C., Previdi, S., Mitchell, J., Aries, E.,		Filsfils, C., Previdi, S., Mitchell, J., Lapukhov, P.,
	Lapukhov, P., Gaya, G., Afanasiev, D., Laberge, T.,		Gaya, G., Afanasiev, D., Laberge, T., Nkposong, E.,
	Nkposong, E., Nanduri, M., Uttaro, J., and S. Ray, "BGP-		Nanduri, M., Uttaro, J., and S. Ray, "BGP-Prefix Segment
	Prefix Segment in large-scale data centers",		in large-scale data centers", draft-filsfils-spring-
	draft-filsfils-spring-segment-routing-msdc-03 (work in		segment-routing-msdc-03 (work in progress), July 2015.
	progress), July 2015.
	[I-D.francois-spring-segment-routing-ti-lfa]		[I-D.francois-rtgwg-segment-routing-ti-lfa]
	Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,		Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,
	"Topology Independent Fast Reroute using Segment Routing",		"Topology Independent Fast Reroute using Segment Routing",
	draft-francois-spring-segment-routing-ti-lfa-01 (work in		draft-francois-rtgwg-segment-routing-ti-lfa-00 (work in
	progress), October 2014.		progress), August 2015.
	[I-D.geib-spring-oam-usecase]		[I-D.geib-spring-oam-usecase]
	Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use		Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
	case for a scalable and topology aware MPLS data plane		case for a scalable and topology aware MPLS data plane
	monitoring system", draft-geib-spring-oam-usecase-06 (work		monitoring system", draft-geib-spring-oam-usecase-06 (work
	in progress), July 2015.		in progress), July 2015.
			[I-D.ietf-isis-prefix-attributes]
			Ginsberg, L., Decraene, B., Filsfils, C., Litkowski, S.,
			Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix
			Attributes for Extended IP and IPv6 Reachability", draft-
			ietf-isis-prefix-attributes-01 (work in progress), June
			2015.
	[I-D.ietf-isis-segment-routing-extensions]		[I-D.ietf-isis-segment-routing-extensions]
	Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,		Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
	Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS		Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
	Extensions for Segment Routing",		Extensions for Segment Routing", draft-ietf-isis-segment-
	draft-ietf-isis-segment-routing-extensions-05 (work in		routing-extensions-05 (work in progress), June 2015.
	progress), June 2015.
	[I-D.ietf-ospf-ospfv3-segment-routing-extensions]		[I-D.ietf-ospf-ospfv3-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, "OSPFv3		Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
	Extensions for Segment Routing",		Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
	draft-ietf-ospf-ospfv3-segment-routing-extensions-03 (work		segment-routing-extensions-03 (work in progress), June
	in progress), June 2015.		2015.
	[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",		Extensions for Segment Routing", draft-ietf-ospf-segment-
	draft-ietf-ospf-segment-routing-extensions-05 (work in		routing-extensions-05 (work in progress), June 2015.
	progress), June 2015.
	[I-D.ietf-pce-segment-routing]		[I-D.ietf-pce-segment-routing]
	Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,		Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
	Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,		Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
	"PCEP Extensions for Segment Routing",		"PCEP Extensions for Segment Routing", draft-ietf-pce-
	draft-ietf-pce-segment-routing-05 (work in progress),		segment-routing-06 (work in progress), August 2015.
	May 2015.
	[I-D.ietf-spring-ipv6-use-cases]		[I-D.ietf-spring-ipv6-use-cases]
	Brzozowski, J., Leddy, J., Leung, I., Previdi, S.,		Brzozowski, J., Leddy, J., Leung, I., Previdi, S.,
	Townsley, W., Martin, C., Filsfils, C., and R. Maglione,		Townsley, W., Martin, C., Filsfils, C., and R. Maglione,
	"IPv6 SPRING Use Cases",		"IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use-
	draft-ietf-spring-ipv6-use-cases-04 (work in progress),		cases-05 (work in progress), September 2015.
	March 2015.
	[I-D.ietf-spring-problem-statement]		[I-D.ietf-spring-problem-statement]
	Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,		Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,
	Horneffer, M., and R. Shakir, "SPRING Problem Statement		Horneffer, M., and R. Shakir, "SPRING Problem Statement
	and Requirements", draft-ietf-spring-problem-statement-04		and Requirements", draft-ietf-spring-problem-statement-04
	(work in progress), April 2015.		(work in progress), April 2015.
	[I-D.ietf-spring-resiliency-use-cases]		[I-D.ietf-spring-resiliency-use-cases]
	Francois, P., Filsfils, C., Decraene, B., and R. Shakir,		Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
	"Use-cases for Resiliency in SPRING",		"Use-cases for Resiliency in SPRING", draft-ietf-spring-
	draft-ietf-spring-resiliency-use-cases-01 (work in		resiliency-use-cases-01 (work in progress), March 2015.
	progress), March 2015.
	[I-D.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,		Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
	and E. Crabbe, "Segment Routing with MPLS data plane",		and E. Crabbe, "Segment Routing with MPLS data plane",
	draft-ietf-spring-segment-routing-mpls-01 (work in		draft-ietf-spring-segment-routing-mpls-01 (work in
	progress), May 2015.		progress), May 2015.
	[I-D.kumar-spring-sr-oam-requirement]		[I-D.ietf-spring-sr-oam-requirement]
	Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,		Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
	and S. Litkowski, "OAM Requirements for Segment Routing		and S. Litkowski, "OAM Requirements for Segment Routing
	Network", draft-kumar-spring-sr-oam-requirement-03 (work		Network", draft-ietf-spring-sr-oam-requirement-00 (work in
	in progress), March 2015.		progress), June 2015.
	[I-D.previdi-6man-segment-routing-header]		[I-D.previdi-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Field, B., Leung, I., Aries,		Previdi, S., Filsfils, C., Field, B., Leung, I., Vyncke,
	E., Vyncke, E., and D. Lebrun, "IPv6 Segment Routing		E., and D. Lebrun, "IPv6 Segment Routing Header (SRH)",
	Header (SRH)",
	draft-previdi-6man-segment-routing-header-07 (work in		draft-previdi-6man-segment-routing-header-07 (work in
	progress), July 2015.		progress), July 2015.
			[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
			Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
			RFC 4915, DOI 10.17487/RFC4915, June 2007,
			<http://www.rfc-editor.org/info/rfc4915>.
	[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation		[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
	of Type 0 Routing Headers in IPv6", RFC 5095,		of Type 0 Routing Headers in IPv6", RFC 5095,
	DOI 10.17487/RFC5095, December 2007,		DOI 10.17487/RFC5095, December 2007,
	<http://www.rfc-editor.org/info/rfc5095>.		<http://www.rfc-editor.org/info/rfc5095>.
			[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
			Topology (MT) Routing in Intermediate System to
			Intermediate Systems (IS-ISs)", RFC 5120,
			DOI 10.17487/RFC5120, February 2008,
			<http://www.rfc-editor.org/info/rfc5120>.
			[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
			Instance Extensions", RFC 6549, DOI 10.17487/RFC6549,
			March 2012, <http://www.rfc-editor.org/info/rfc6549>.
			[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D.
			Ward, "IS-IS Multi-Instance", RFC 6822,
			DOI 10.17487/RFC6822, December 2012,
			<http://www.rfc-editor.org/info/rfc6822>.
	Authors' Addresses		Authors' Addresses
	Clarence Filsfils (editor)		Clarence Filsfils (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Brussels,		Brussels
	BE		BE
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	Stefano Previdi (editor)		Stefano Previdi (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Via Del Serafico, 200		Via Del Serafico, 200
	Rome 00142		Rome 00142
	Italy		Italy
End of changes. 77 change blocks.
	198 lines changed or deleted		351 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/