< draft-previdi-filsfils-isis-segment-routing-00.txt		draft-previdi-filsfils-isis-segment-routing-01.txt >
	IS-IS for IP Internets S. Previdi, Ed.		IS-IS for IP Internets S. Previdi, Ed.
	Internet-Draft C. Filsfils, Ed.		Internet-Draft C. Filsfils, Ed.
	Intended status: Standards Track A. Bashandy		Intended status: Standards Track A. Bashandy
	Expires: September 13, 2013 Cisco Systems, Inc.		Expires: September 22, 2013 Cisco Systems, Inc.
	M. Horneffer		M. Horneffer
	Deutsche Telekom		Deutsche Telekom
	B. Decraene		B. Decraene
	S. Litkowski		S. Litkowski
	Orange		Orange
	I. Milojevic		I. Milojevic
	Telekom Srbija		Telekom Srbija
	R. Shakir		R. Shakir
	British Telecom		British Telecom
	S. Ytti		S. Ytti
	TDC Oy		TDC Oy
	March 12, 2013		W. Henderickx
			Alcatel-Lucent
			H. Gredler
			Juniper Networks, Inc.
			March 21, 2013
	Segment Routing with IS-IS Routing Protocol		Segment Routing with IS-IS Routing Protocol
	draft-previdi-filsfils-isis-segment-routing-00		draft-previdi-filsfils-isis-segment-routing-01
	Abstract		Abstract
	Segment Routing (SR) enables any node to select any path (explicit or		Segment Routing (SR) enables any node to select any path (explicit or
	derived from IGPs SPT computations) for each of its traffic classes.		derived from IGPs SPT computations) for each of its traffic classes.
	The path does not depend on a hop-by-hop signaling technique (neither		The path does not depend on a hop-by-hop signaling technique (neither
	LDP nor RSVP). It only depends on a set of "segments" that are		LDP nor RSVP). It only depends on a set of "segments" that are
	advertised by the IS-IS routing protocol. These segments act as		advertised by the IS-IS routing protocol. These segments act as
	topological sub-paths that can be combined together to form the		topological sub-paths that can be combined together to form the
	desired path.		desired path.
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 15 ¶
	This document describes the Segment Routing functions, a set of use		This document describes the Segment Routing functions, a set of use
	cases it addresses and the necessary changes that are required in the		cases it addresses and the necessary changes that are required in the
	IS-IS protocol.		IS-IS protocol.
	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 September 13, 2013.		This Internet-Draft will expire on September 22, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Capacity Planning and Traffic Engineering (TE) . . . . . . 5		2.2. Capacity Planning and Traffic Engineering (TE) . . . . . 5
	2.2.1. Disjointness in dual-plane networks . . . . . . . . . 9		2.2.1. Disjointness in dual-plane networks . . . . . . . . . 8
	2.2.2. QoS-based Routing Policies . . . . . . . . . . . . . . 10		2.2.2. QoS-based Routing Policies . . . . . . . . . . . . . 9
	2.2.3. Deterministic non-ECMP Path . . . . . . . . . . . . . 11		2.2.3. Deterministic non-ECMP Path . . . . . . . . . . . . . 10
	2.3. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . 12		2.3. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . 11
	2.4. Segment Routing in Software Defined Networks (SR-SDN) . . 13		2.4. Segment Routing in Software Defined Networks (SR-SDN) . . 12
	3. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 13		3. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 13
	3.1. Node Segment Identifier (Node-SID) . . . . . . . . . . . . 14		3.1. Node Segment Identifier (Node-SID) . . . . . . . . . . . 13
	3.1.1. Node-SID SubTLV . . . . . . . . . . . . . . . . . . . 14		3.1.1. Node-SID SubTLV . . . . . . . . . . . . . . . . . . . 14
	3.2. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . 15		3.2. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . 14
	3.2.1. Adj-SID and Interface Address . . . . . . . . . . . . 16		3.2.1. Adj-SID and Interface Address . . . . . . . . . . . . 16
	3.2.2. Adjacency Segment Identifier (Adj-SID) SubTLV . . . . 16		3.2.2. Adjacency Segment Identifier (Adj-SID) SubTLV . . . . 16
	3.2.3. Adjacency Segment Identifiers in LANs . . . . . . . . 17		3.2.3. Adjacency Segment Identifiers in LANs . . . . . . . . 17
	4. Segment Routing Capabilities . . . . . . . . . . . . . . . . . 18		4. Segment Routing Capabilities . . . . . . . . . . . . . . . . 19
	5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19		5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20
	5.1. Unicity . . . . . . . . . . . . . . . . . . . . . . . . . 20		5.1. Unicity . . . . . . . . . . . . . . . . . . . . . . . . . 20
	5.2. IS-IS Multi-Level . . . . . . . . . . . . . . . . . . . . 20		5.2. IS-IS Multi-Level . . . . . . . . . . . . . . . . . . . . 20
	5.3. Data-Plane Encodings . . . . . . . . . . . . . . . . . . . 20		5.3. Data-Plane Encodings . . . . . . . . . . . . . . . . . . 21
	5.3.1. Segment Routing RIB (SR-RIB) . . . . . . . . . . . . . 21		5.3.1. Segment Routing RIB (SR-RIB) . . . . . . . . . . . . 21
	5.3.2. Multiprotocol Label Switching (MPLS) . . . . . . . . . 23		5.3.2. Multiprotocol Label Switching (MPLS) . . . . . . . . 23
	5.3.3. IP Version 6 . . . . . . . . . . . . . . . . . . . . . 24		5.3.3. IP Version 6 . . . . . . . . . . . . . . . . . . . . 24
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	7. Manageability Considerations . . . . . . . . . . . . . . . . . 24		7. Manageability Considerations . . . . . . . . . . . . . . . . 24
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 24		8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 24		10.1. Normative References . . . . . . . . . . . . . . . . . . 24
	10.2. Informative References . . . . . . . . . . . . . . . . . . 25		10.2. Informative References . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	Segment Routing (SR) enables any node to select any path (explicit or		Segment Routing (SR) enables any node to select any path (explicit or
	derived from IGPs SPT computations) for each of its traffic classes.		derived from IGPs SPT computations) for each of its traffic classes.
	The path does not depend on a hop-by-hop signaling technique (neither		The path does not depend on a hop-by-hop signaling technique (neither
	LDP nor RSVP). It only depends on a set of "segments" that are		LDP nor RSVP). It only depends on a set of "segments" that are
	advertised by the IS-IS routing protocol. These segments act as		advertised by the IS-IS routing protocol. These segments act as
	topological sub-paths that can be combined together to form the		topological sub-paths that can be combined together to form the
	desired path.		desired path.
	There are two forms of segments: node and adjacency. A node segment		There are two forms of segments: node and adjacency. A Node Segment
	represents a path to a node. A Node Segment is typically a multi-hop		represents the shortest path to a node. A Node Segment is typically
	path. An adjacency segment represents a specific adjacency to a		a multi-hop sortest path. An adjacency Segment represents a specific
	node.		adjacency to a node.
	SR's control-plane can be applied to IPv6 and MPLS dataplanes.		SR's control-plane can be applied to IPv6 and MPLS dataplanes.
	In the MPLS dataplane, a node segment to node N is instantiated as an		In the MPLS dataplane, a node segment to node N is instantiated as an
	LSP along the shortest-path (spt) to the node. An adjacency segment		LSP along the shortest-path (spt) to the node. An adjacency segment
	is instantiated as a crossconnect entry pointing to a specific egress		is instantiated as a crossconnect entry pointing to a specific egress
	datalink.		datalink.
	At the heart of the SR technology, we find node segments. Node		At the heart of the SR technology, we find node segments. Node
	segments must be globally unique within the network domain.		segments must be globally unique within the network domain.
	A----B----C----D		A----B----C----D
	Figure 1		Figure 1
	In Figure 1, all the nodes must be configured with the same Segment		In Figure 1, all the nodes must be configured with the same Segment
	Routing Identifiers Block (called SRB Node Registry), e.g. 64-5000,		Routing Identifiers Block (called SRB Node Registry), e.g. 64-5000,
	and any node segment be uniquely allocated from that SRB Node		and any node segment be uniquely allocated from that SRB Node
	Registry (e.g. A, B, C and D are configured respectively with node		Registry (e.g. A, B, C and D are configured respectively with node
	segments 64, 65, 66 and 67).		segments 64, 65, 66 and 67).
	In the MPLS dataplane instantiation, this means that all the nodes		In the MPLS dataplane instantiation, this means that all the nodes
	need to be able to reserve and allocate to the SR control-plane the		need to be able to reserve and allocate to the SR control-plane the
	same MPLS label range (e.g. 64-5000).		same MPLS label range (e.g. 64-5000).
	2. Applicability		2. Applicability
	Segment Routing is applicable to the following use-cases: simplicity,		Segment Routing is applicable to the following use-cases: simplicity,
	TE, FRR and SDN.		TE, FRR and SDN.
	2.1. Simplicity		2.1. Simplicity
	The vast majority of IP traffic travels on shortest-paths to their		The vast majority of IP traffic travels on shortest-paths to their
	destination. SR delivers a very efficient control-plane technique to		destination. SR delivers a very efficient control-plane technique to
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 8 ¶
	Figure 2: Example Topology 1		Figure 2: Example Topology 1
	ECMP is extremely frequent in SP, Enterprise and DC architectures and		ECMP is extremely frequent in SP, Enterprise and DC architectures and
	it is not rare to see as much as 128 different ECMP paths between a		it is not rare to see as much as 128 different ECMP paths between a
	source and a destination within a single network domain.		source and a destination within a single network domain.
	This is illustrated in Figure 3 which consists of a subset of a		This is illustrated in Figure 3 which consists of a subset of a
	network where already 6 ECMP paths are observed from A to M.		network where already 6 ECMP paths are observed from A to M.
	C		C
	/ \		/ \
	B-D-L--		B-D-L--
	/ \ / \		/ \ / \
	A E \		A E \
	\ M		\ M
	\ G /		\ G /
	\ / \ /		\ / \ /
	F-H-K		F-H-K
	\ /		\ /
	I		I
	Figure 3: ECMP Topology Example		Figure 3: ECMP Topology Example
	Segment Routing offers a simple support for such ECMP-based shortest-		Segment Routing offers a simple support for such ECMP-based shortest-
	path placement: a node segment. A single node segment enumerates all		path placement: a node segment. A single node segment enumerates all
	the ECMP paths along the shortest-path.		the ECMP paths along the shortest-path.
	This is much simpler to the RSVP-TE model where one TE tunnel is		This is much simpler to the RSVP-TE model where one TE tunnel is
	required for each enumerated ECMP path.		required for each enumerated ECMP path.
	skipping to change at page 7, line 21 ¶		skipping to change at page 6, line 48 ¶
	Segment Routing offers a simple support for explicit path policy.		Segment Routing offers a simple support for explicit path policy.
	In the diagram described in Figure 3, it is assumed that the		In the diagram described in Figure 3, it is assumed that the
	requirement is that AM flow should not consume any resource on the LM		requirement is that AM flow should not consume any resource on the LM
	and the FG links.		and the FG links.
	The first option would consists of using the following encapsulation		The first option would consists of using the following encapsulation
	at A: A sends any traffic to M towards the nhop F with a two-label		at A: A sends any traffic to M towards the nhop F with a two-label
	stack where the top label is the adjacent segment FI and the next		stack where the top label is the adjacent segment FI and the next
	label is the node segment to M. Alternatively, a three-label stack		label is the node segment to M. Alternatively, a three-label stack
	with adjacency segments FI, IK and KM could have been used.		with adjacency segments FI, IK and KM could have been used.
	The first option seems preferred as classically IP capacity planners		The first option seems preferred as classically IP capacity planners
	optimize traffic along ECMP-aware shortest-path. The more node		optimize traffic along ECMP-aware shortest-path. The more node
	segment can be used, the better. However, both options are available		segment can be used, the better. However, both options are available
	and one can favor adjacency segments.		and one can favor adjacency segments.
	In the same way, if the requirement in the diagram described in		In the same way, if the requirement in the diagram described in
	Figure 3, is that the AM flow should not consume any resource along		Figure 3, is that the AM flow should not consume any resource along
	the LM link but should use any resource on the bottom of the		the LM link but should use any resource on the bottom of the
	skipping to change at page 10, line 4 ¶		skipping to change at page 9, line 30 ¶
	Segment Routing (SR) offers a simpler solution.		Segment Routing (SR) offers a simpler solution.
	Any node of the first plane can be configured with an anycast		Any node of the first plane can be configured with an anycast
	loopback say 1.1.1.1/32 to which node segment 111 is attached. Any		loopback say 1.1.1.1/32 to which node segment 111 is attached. Any
	node of the second plane can be configured with an anycast loopback		node of the second plane can be configured with an anycast loopback
	say 2.2.2.2/32 to which node segment 222 is attached. Let us also		say 2.2.2.2/32 to which node segment 222 is attached. Let us also
	assume that access node Z is advertising node segment 500.		assume that access node Z is advertising node segment 500.
	A flow from A to Z via the first plane is simply represented by the		A flow from A to Z via the first plane is simply represented by the
	segment list {111, 500}. In the MPLS dataplane case, A pushes a two-		segment list {111, 500}. In the MPLS dataplane case, A pushes a two-
	label stack for Z-destined packets: the top label is 111 and the		label stack for Z-destined packets: the top label is 111 and the
	second label is 500.		second label is 500.
	Node segment 111 gets the traffic on ECMP-aware shortest path to the		Node segment 111 gets the traffic on ECMP-aware shortest path to the
	first plane and then node segment 500 gets the traffic on ECMP-aware		first plane and then node segment 500 gets the traffic on ECMP-aware
	shortest path to Z.		shortest path to Z.
	Similarly, a flow from A to Z via the second plane is simply		Similarly, a flow from A to Z via the second plane is simply
	represented by the segment list {222, 500}.		represented by the segment list {222, 500}.
	skipping to change at page 10, line 47 ¶		skipping to change at page 10, line 24 ¶
	suite the latency requirements of the voice traffic between the two		suite the latency requirements of the voice traffic between the two
	cities.		cities.
	Segment Routing (SR) offers a simple solution to the problem.		Segment Routing (SR) offers a simple solution to the problem.
	The core routers in Russia are configured with an extra anycast		The core routers in Russia are configured with an extra anycast
	loopback 3.3.3.3/32 to which node segment 333 is attached.		loopback 3.3.3.3/32 to which node segment 333 is attached.
	If we assume that Brussels is configured with node segment 600, Tokyo		If we assume that Brussels is configured with node segment 600, Tokyo
	can send all its data traffic to Brussels with one single segment:		can send all its data traffic to Brussels with one single segment:
	600. 600 gets the traffic from Tokyo to Brussels via USA and exploits		600. 600 gets the traffic from Tokyo to Brussels via USA and
	any ECMP-path along this shortest-path.		exploits any ECMP-path along this shortest-path.
	Tokyo can send all its voice traffic to Brussels with a list of two		Tokyo can send all its voice traffic to Brussels with a list of two
	segments: {333, 600}. 333 gets the traffic to Russia and exploit any		segments: {333, 600}. 333 gets the traffic to Russia and exploit any
	ECMP path along the shortest path. 600 gets the traffic from Russia		ECMP path along the shortest path. 600 gets the traffic from Russia
	to Brussels via ECMP-aware shortest-path.		to Brussels via ECMP-aware shortest-path.
	One single metric per link is sufficient as clearly it is possible to		One single metric per link is sufficient as clearly it is possible to
	set the IGP metrics such that the shortest-path from Brussels to		set the IGP metrics such that the shortest-path from Brussels to
	Russia is via Russia and not via USA and the shortest-path from		Russia is via Russia and not via USA and the shortest-path from
	Russia to Brussels is not back via Tokyo and USA but straight to		Russia to Brussels is not back via Tokyo and USA but straight to
	Brussels.		Brussels.
	2.2.3. Deterministic non-ECMP Path		2.2.3. Deterministic non-ECMP Path
	skipping to change at page 14, line 7 ¶		skipping to change at page 13, line 34 ¶
	SR provides for very frequent transaction-based application as the		SR provides for very frequent transaction-based application as the
	network does not hold any state for the SR-encoded flows.		network does not hold any state for the SR-encoded flows.
	3. Segment Routing Identifiers		3. Segment Routing Identifiers
	Segment Routing defines two types of Segment Identifiers: Node-SID		Segment Routing defines two types of Segment Identifiers: Node-SID
	and Adj-SID.		and Adj-SID.
	3.1. Node Segment Identifier (Node-SID)		3.1. Node Segment Identifier (Node-SID)
	A node-SID is associated to a prefix advertised by a node (e.g. in a		A node-SID is associated to a prefix advertised by a node (e.g. in a
	TLV-135). The Node-SID SubTLV MAY be present in one of the following		TLV-135). The Node-SID SubTLV MAY be present in one of the following
	TLVs:		TLVs:
	TLV-135 (IPv4) defined in [RFC5305].		TLV-135 (IPv4) defined in [RFC5305].
	TLV-235 (MT-ipv4) [RFC5120].		TLV-235 (MT-ipv4) [RFC5120].
	TLV-236 (IPv6) [RFC5308].		TLV-236 (IPv6) [RFC5308].
	TLV-237 (MT-IPv6) [RFC5120].		TLV-237 (MT-IPv6) [RFC5120].
	skipping to change at page 15, line 21 ¶		skipping to change at page 15, line 4 ¶
	L-Flag: Level flag. If set, then the prefix has been		L-Flag: Level flag. If set, then the prefix has been
	propagated to the router in this level from another level		propagated to the router in this level from another level
	(i.e.: from level-1 into level-2 or from level-2 into level-1).		(i.e.: from level-1 into level-2 or from level-2 into level-1).
	Other bits: MUST be zero when sent and ignored when received.		Other bits: MUST be zero when sent and ignored when received.
	Segment Identifier (SID): 32 bits of Segment Identifier		Segment Identifier (SID): 32 bits of Segment Identifier
	3.2. Adjacency Segment Identifier (Adj-SID)		3.2. Adjacency Segment Identifier (Adj-SID)
	An Adjacency Segment Identifier (Adj-SID) represents a router		An Adjacency Segment Identifier (Adj-SID) represents a router
	adjacency. The value of the Adj-SID is local to the router and it is		adjacency. The value of the Adj-SID is local to the router and it is
	encoded as a 32 bit number value using a new SubTLV in the following		encoded as a 32 bit number value using a new SubTLV. According to
	TLVs:		IS-IS, each adjacency is advertised using one of the IS-IS Neighbor
			TLVs below:
	TLV-22 [RFC5305]		TLV-22 [RFC5305]
	TLV-222[RFC5120]		TLV-222 [RFC5120]
	TLV-23[RFC5311]		TLV-23 [RFC5311]
	TLV-223[RFC5311]		TLV-223 [RFC5311]
	Multiple Adj-SID SubTLVs MAY be attached to the above-mentioned TLVs.		TLV-141[RFC5316]
	An example where more than one is useful is the case of parallel
	adjacencies between two neighbors. Each Adjacency will be encoded
	separately (e.g. using TLV-22) and each adjacency will have one Adj-
	SID attached to it. This allow a remote router to explicitly
	determine which of the parallel adjacencies should be used for
	forwarding the packet.
	However, the remote router may prefer not to select a specific		Currently, [RFC5316] defines TLV-141 with the purpose of inter-AS
	parallel interface and leave the decision to the local router so that		connectivity. In the Segment Routing context, we relax the
	load sharing in the local router is determined locally.		constraint and we allow TLV-141 to be used for advertising any link
			that is external to the IS-IS domain no matter if it connects another
			AS or not.
	Therefore, the local router (i.e.: the router with parallel		The newly defined Adj-SID subTLV carries the Adj-SID value for each
	adjacencies) MAY insert a second Adj-SID, to each of its parallel		of the advertised adjacencies and MAY be present in any of the
	adjacencies, with the same value so that when packets are received		neighbor TLVs described above.
	with that Adj-SID the decision onto which link the packet should be
	forwarded is left to the local router.
	When the same Adj-SID value is used on different parallel		Multiple Adj-SID SubTLVs MAY be attached to the Neighbor TLVs (e.g.:
	adjacencies, we call such value a Bundle-Adj-SID.		TLV-22). An example where more than one is useful is the case of
			parallel adjacencies between two neighbors. In the figure here
			below:
			_____
			/ \
			----A------B------C----
			\_____/
			Figure 6: Parallel Adjacencies
			Router B nd C have 3 parallel adjacencies. Router B advertises three
			distinct Neighbor TLVs (e.g.: TLV-22), one for each parallel
			adjacency. Each of these advertisements will have its own Adj-SID
			SubTLV with a unique value (inside the Adj-SID space of the router).
			When router A inspects its IS-IS Link State Database (LSDB) it can
			figure out which link to use on a source routed path going through
			B-C links. It has knowledge of each individual parallel adjacency
			and can handle load sharing across them on its own (i.e.: decide in
			advance which packet should use which link).
			However, router A may prefer not to select a specific parallel
			interface and leave the load sharing decision to router B so that
			load sharing is handled locally (i.e.: where parallel interfaces
			resides).
			In order to achieve that, router B inserts an additional Adj-SID
			value on each of the parallel adjacencies it advertises. The value
			of this second Adj-SID is common to all parallel adjacencies.
			Again, when router A inspects its IS-IS LSDB, it finds that the
			parallel adjacencies advertised by router B have a second Adj-SID
			with a value that is common across all parallel adjacencies. Using
			that value will bring packets into router B and the load sharing
			decision is owned by router B itself.
			When the same Adj-SID value is used on parallel adjacencies, we
			called the Adj-SID a "Bundle-Adj-SID".
	3.2.1. Adj-SID and Interface Address		3.2.1. Adj-SID and Interface Address
	When advertising one or more Adj-SID SubTLVs, the router MUST also		When advertising one or more Adj-SID SubTLVs, the router MUST also
	advertise Interface Address and Neighbor Address SubTLVs (IPv4 or		advertise Interface Address and Neighbor Address SubTLVs (IPv4 or
	IPv6). The two MUST be present. The encoding is defined in		IPv6). The two MUST be present. The encoding is defined in
	[RFC5305] for IPv4 and in [RFC6119] for IPv6.		[RFC5305] for IPv4 and in [RFC6119] for IPv6.
	3.2.2. Adjacency Segment Identifier (Adj-SID) SubTLV		3.2.2. Adjacency Segment Identifier (Adj-SID) SubTLV
	skipping to change at page 18, line 51 ¶		skipping to change at page 19, line 17 ¶
	corresponding Adj-SID table in order to figure out which Adj-SID has		corresponding Adj-SID table in order to figure out which Adj-SID has
	to be used between any two neighbors in the LAN.		to be used between any two neighbors in the LAN.
	4. Segment Routing Capabilities		4. Segment Routing Capabilities
	Segment Routing requires each router to advertise its capabilities to		Segment Routing requires each router to advertise its capabilities to
	the rest of the routing domain. TLV-242 (defined in [RFC4971])		the rest of the routing domain. TLV-242 (defined in [RFC4971])
	describes router capabilities. For the purposes of Segment Routing		describes router capabilities. For the purposes of Segment Routing
	we define an additional subTLV: the SR-Cap SubTLV.		we define an additional subTLV: the SR-Cap SubTLV.
	The SR-Cap SubTLV MUST be present in the Router Capability TLV (TLV-		The SR-Cap SubTLV MUST be present in the Router Capability TLV
	242), MUST appear only once and has following format:		(TLV-242), MUST appear only once and has following format:
	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 | SR Capabilities Flags |		| Type | Length | SR Capabilities Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Type: TBA.		Type: TBA.
	skipping to change at page 19, line 18 ¶		skipping to change at page 19, line 33 ¶
	| Type | Length | SR Capabilities Flags |		| Type | Length | SR Capabilities Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Type: TBA.		Type: TBA.
	Length: 2 octets.		Length: 2 octets.
	SR Capabilities Flags: 2 octets field of following flags:		SR Capabilities Flags: 2 octets field of following flags:
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|M|F|S| |		|M|F|S| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	M-Flag: MPLS flag. If set, then the advertising router is		M-Flag: MPLS flag. If set, then the advertising router is
	capable of MPLS label based forwarding.		capable of MPLS label based forwarding.
	F-Flag: IPv4 flag. If set, then the advertising router is		F-Flag: IPv4 flag. If set, then the advertising router is
	capable of IPv4 based forwarding.		capable of IPv4 based forwarding.
	S-Flag: IPv6 flag. If set, then the advertising router is		S-Flag: IPv6 flag. If set, then the advertising router is
	capable of IPv6 based forwarding.		capable of IPv6 based forwarding.
	Other bits: MUST be zero when sent and ignored when received.		Other bits: MUST be zero when sent and ignored when
			received.
	The Router Capability TLV defined in [RFC4971]specifies the S and D		The Router Capability TLV defined in [RFC4971]specifies the S and D
	bits. The SR-Capability SubTLV MUST be propagated throughout the		bits. The SR-Capability SubTLV MUST be propagated throughout the
	entire routing domain and therefore the S bit in the Router		entire routing domain and therefore the S bit in the Router
	Capability TLV MUST be set.		Capability TLV MUST be set.
	The D bit of Router Capability TLV must be set accordingly. I.e.: it		The D bit of Router Capability TLV must be set accordingly. I.e.: it
	MUST be set when the Router Capability TLV is leaked from level-2 to		MUST be set when the Router Capability TLV is leaked from level-2 to
	level-1.		level-1.
	skipping to change at page 20, line 27 ¶		skipping to change at page 20, line 43 ¶
	prefix is of anycast type and is advertised by two nodes N and M,		prefix is of anycast type and is advertised by two nodes N and M,
	then N and M attach the same (anycast) Node-SID to the same anycast		then N and M attach the same (anycast) Node-SID to the same anycast
	IP address.		IP address.
	If a node N learns a remote Adj-SID S but advertised with a value		If a node N learns a remote Adj-SID S but advertised with a value
	that falls in its locally configured Node SRB range, N SHOULD issue		that falls in its locally configured Node SRB range, N SHOULD issue
	an error log warning for a misconfiguration.		an error log warning for a misconfiguration.
	If a node N learns a remote Node-SID S but with a value that falls		If a node N learns a remote Node-SID S but with a value that falls
	outside its locally configured node SRB range, N SHOULD NOT insert		outside its locally configured node SRB range, N SHOULD NOT insert
	any RIB entry for segment S. Node N SHOULD issue an error log warning		any RIB entry for segment S. Node N SHOULD issue an error log
	for misconfiguration.		warning for misconfiguration.
	If a node N learns about two different IP addresses advertised with		If a node N learns about two different IP addresses advertised with
	the same Node-SID, N MUST insert a RIB entry only for the node		the same Node-SID, N MUST insert a RIB entry only for the node
	segment related to the highest IP address. N SHOULD issue an error		segment related to the highest IP address. N SHOULD issue an error
	log warning for misconfiguration.		log warning for misconfiguration.
	5.2. IS-IS Multi-Level		5.2. IS-IS Multi-Level
	In IS-IS protocol, adjacencies advertisements (e.g.: TLV-22) are not		In IS-IS protocol, adjacencies advertisements (e.g.: TLV-22) are not
	propagated across level/area boundaries hence the adjacency segment		propagated across level/area boundaries hence the adjacency segment
	(Adj-SID) is not propagated across levels either.		(Adj-SID) is not propagated across levels either.
	If a prefix is propagated across levels, then its Node-SID SubTLVs		If a prefix is propagated across levels, then its Node-SID SubTLVs
	are also propagated. The Node-SID S flag is set accordingly,		are also propagated. The Node-SID S flag is set accordingly,
	independently from the settings of the U/D bit defined in [RFC5305].		independently from the settings of the U/D bit defined in [RFC5305].
	5.3. Data-Plane Encodings		5.3. Data-Plane Encodings
	skipping to change at page 21, line 40 ¶		skipping to change at page 22, line 8 ¶
	operation.		operation.
	Other operations will be introduced in future versions of the		Other operations will be introduced in future versions of the
	document.		document.
	Two types of SR-RIB entries are defined:		Two types of SR-RIB entries are defined:
	TRANSIT: the ingress packet comes with an active segment. A		TRANSIT: the ingress packet comes with an active segment. A
	Transit SR-RIB entry is represented as:		Transit SR-RIB entry is represented as:
	Ingress active segment.		Ingress active segment.
	Operation on the active segment.		Operation on the active segment.
	Egress Interface.		Egress Interface.
	INGRESS: the ingress packet comes without active segment (plain		INGRESS: the ingress packet comes without active segment (plain
	IP).		IP).
	5.3.1.1. SR-RIB entry for local segments		5.3.1.1. SR-RIB entry for local segments
	A node MUST install a transit SR-RIB entry for any local adjacency		A node MUST install a transit SR-RIB entry for any local adjacency
	segment (Adj-SID) of value V attached to datalink L with:		segment (Adj-SID) of value V attached to datalink L with:
	Ingress active segment : V		Ingress active segment : V
	Ingress operation: NEXT		Ingress operation: NEXT
	Egress interface: L		Egress interface: L
	A node MUST install a transit SRIB entry for any local adjacency		A node MUST install a transit SR-RIB entry for any local adjacency
	segment (Adj-SID) of value W attached to ISIS link bundle B with:		segment (Adj-SID) of value W attached to ISIS link bundle B with:
	Ingress active segment: W		Ingress active segment: W
	Ingress operation: NEXT		Ingress operation: NEXT
	Egress interface: hash between any datalink within bundle B		Egress interface: hash between any datalink within bundle B
	A node MUST install a transit SR-RIB entry for any local node segment		A node MUST install a transit SR-RIB entry for any local node segment
	(Node-SID) of value N with:		(Node-SID) of value N with:
	skipping to change at page 23, line 18 ¶		skipping to change at page 23, line 27 ¶
	plane. An ingress SR-RIB entry is generally represented as:		plane. An ingress SR-RIB entry is generally represented as:
	Classification: what traffic		Classification: what traffic
	Encapsulation: what list of segments to insert		Encapsulation: what list of segments to insert
	In this section, we define its simplest instantiation: the automated		In this section, we define its simplest instantiation: the automated
	ingress SR-RIB entry insertion towards remote node segments (Node-		ingress SR-RIB entry insertion towards remote node segments (Node-
	SID).		SID).
	A node MUST install an ingress SR-RIB entry for any remote node		A node SHOULD install an ingress SR-RIB entry for any remote node
	segment (Node-SID) of value V attached to IP prefix P with:		segment (Node-SID) of value V attached to IP prefix P with:
	FEC: prefix P		FEC: prefix P
	Ingress operation: insert nodal segment V.		Ingress operation: insert nodal segment V.
	Egress interface: interface to next-hop along the shortest-path to		Egress interface: interface to next-hop along the shortest-path to
	P.		P.
	5.3.1.4. Policy-based Ingress SRIB entry		5.3.1.4. Policy-based Ingress SRIB entry
	skipping to change at page 23, line 50 ¶		skipping to change at page 24, line 11 ¶
	The CONTINUE operation is implemented as a swap where the outgoing		The CONTINUE operation is implemented as a swap where the outgoing
	label value is set to the incoming label value.		label value is set to the incoming label value.
	The NEXT operation is implemented as a MPLS pop operation.		The NEXT operation is implemented as a MPLS pop operation.
	The INSERT operation is implemented as a MPLS push of a label		The INSERT operation is implemented as a MPLS push of a label
	stack.		stack.
	The Node-SID value or Adj-SID value rightmost 20 bits MUST be used		The Node-SID value or Adj-SID value rightmost 20 bits MUST be used
	for label values.		for label values. This implies SID values to be allocated
			according to the 20 bit space in MPLS labels.
	5.3.3. IP Version 6		5.3.3. IP Version 6
	The text will be added in future revision.		The text will be added in future revision.
	6. IANA Considerations		6. IANA Considerations
	TBD		TBD
	7. Manageability Considerations		7. Manageability Considerations
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 12 ¶
	System to Intermediate System (IS-IS) Extensions for		System to Intermediate System (IS-IS) Extensions for
	Advertising Router Information", RFC 4971, July 2007.		Advertising Router Information", RFC 4971, July 2007.
	[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi		[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
	Topology (MT) Routing in Intermediate System to		Topology (MT) Routing in Intermediate System to
	Intermediate Systems (IS-ISs)", RFC 5120, February 2008.		Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
	[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic		[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
	Engineering", RFC 5305, October 2008.		Engineering", RFC 5305, October 2008.
	[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,		[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
	October 2008.		2008.
	[RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand,		[RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand,
	"Simplified Extension of Link State PDU (LSP) Space for		"Simplified Extension of Link State PDU (LSP) Space for
	IS-IS", RFC 5311, February 2009.		IS-IS", RFC 5311, February 2009.
			[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
			Support of Inter-Autonomous System (AS) MPLS and GMPLS
			Traffic Engineering", RFC 5316, December 2008.
	[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic		[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
	Engineering in IS-IS", RFC 6119, February 2011.		Engineering in IS-IS", RFC 6119, February 2011.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-rtgwg-remote-lfa]		[I-D.ietf-rtgwg-remote-lfa]
	Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.		Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
	Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01		Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01
	(work in progress), December 2012.		(work in progress), December 2012.
	skipping to change at page 25, line 37 ¶		skipping to change at page 26, line 4 ¶
	Authors' Addresses		Authors' Addresses
	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
	Email: sprevidi@cisco.com		Email: sprevidi@cisco.com
	Clarence Filsfils (editor)		Clarence Filsfils (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Brussels,		Brussels
	BE		BE
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	Ahmed Bashandy		Ahmed Bashandy
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170, West Tasman Drive		170, West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: bashandy@cisco.com		Email: bashandy@cisco.com
	Martin Horneffer		Martin Horneffer
	Deutsche Telekom		Deutsche Telekom
	skipping to change at page 26, line 39 ¶		skipping to change at page 27, line 4 ¶
	Email: stephane.litkowski@orange.com		Email: stephane.litkowski@orange.com
	Igor Milojevic		Igor Milojevic
	Telekom Srbija		Telekom Srbija
	Takovska 2		Takovska 2
	Belgrade		Belgrade
	RS		RS
	Email: igormilojevic@telekom.rs		Email: igormilojevic@telekom.rs
	Rob Shakir		Rob Shakir
	British Telecom		British Telecom
	London		London
	UK		UK
	Email: rob.shakir@bt.com		Email: rob.shakir@bt.com
	Saku Ytti		Saku Ytti
	TDC Oy		TDC Oy
	Mechelininkatu 1a		Mechelininkatu 1a
	TDC 00094		TDC 00094
	FI		FI
	Email: saku@ytti.fi		Email: saku@ytti.fi
			Wim Henderickx
			Alcatel-Lucent
			Copernicuslaan 50
			Antwerp 2018
			BE
			Email: wim.henderickx@alcatel-lucent.com
			Hannes Gredler
			Juniper Networks, Inc.
			1194 N. Mathilda Ave.
			Sunnyvale, CA 94089
			US
			Email: hannes@juniper.net
End of changes. 47 change blocks.
	107 lines changed or deleted		150 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/