< draft-ietf-spring-segment-routing-05.txt		draft-ietf-spring-segment-routing-06.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: March 23, 2016 B. Decraene		Expires: April 16, 2016 B. Decraene
	S. Litkowski		S. Litkowski
	Orange		Orange
	R. Shakir		R. Shakir
	Individual		Individual
	September 20, 2015		October 14, 2015
	Segment Routing Architecture		Segment Routing Architecture
	draft-ietf-spring-segment-routing-05		draft-ietf-spring-segment-routing-06
	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.
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 23, 2016.		This Internet-Draft will expire on April 16, 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
	skipping to change at page 3, line 24 ¶		skipping to change at page 3, line 24 ¶
	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.
	Segment Routing can be directly applied to the MPLS architecture (RFC		Segment Routing can be directly applied to the MPLS architecture
	3031) with no change on the forwarding plane. A segment is encoded		([RFC3031]) with no change on the forwarding plane. A segment is
	as an MPLS label. An ordered list of segments is encoded as a stack		encoded as an MPLS label. An ordered list of segments is encoded as
	of labels. The active segment is on the top of the stack. A		a stack of labels. The active segment is on the top of the stack. A
	completed segment is popped off the stack. The addition of a segment		completed segment is popped off the stack. The addition of a segment
	is performed with a push.		is performed with a push.
	In the Segment Routing MPLS instantiation, a segment could be of		In the Segment Routing MPLS instantiation, a segment could be of
	several types:		several types:
	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 are		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 header. A segment is encoded as an IPv6		with a new type of routing header. A segment is encoded as an IPv6
	address. An ordered list of segments is encoded as an ordered list		address. An ordered list of segments is encoded as an ordered list
	of IPv6 addresses in the routing header. The active segment is		of IPv6 addresses in the routing header. The active segment is
	indicated by the Destination Address of the packet. Upon completion		indicated by the Destination Address of the packet. Upon completion
	of a segment, a pointer in the new routing header is incremented and		of a segment, a pointer in the new routing header is incremented and
	indicates the next segment.		indicates the next segment.
	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.
	skipping to change at page 11, line 10 ¶		skipping to change at page 11, line 10 ¶
	This is useful to express macro-engineering policies or protection		This is useful to express macro-engineering policies or protection
	mechanisms.		mechanisms.
	An IGP-Anycast Segment MUST NOT reference a particular node.		An IGP-Anycast Segment MUST NOT reference a particular node.
	Within an anycast group, all routers MUST advertise the same prefix		Within an anycast group, all routers MUST advertise the same prefix
	with the same SID value.		with the same SID value.
	+--------------+		+--------------+
	| Group A |		| Group A |
	| 192.0.1.1/32 |		|192.0.2.10/32 |
	| SID:100 |		| SID:100 |
	| |		| |
	+-----------A1---A3----------+		+-----------A1---A3----------+
	| | | \ / | | |		| | | \ / | | |
	SID:10 | | | / | | | SID:30		SID:10 | | | / | | | SID:30
	1.1.1.1/32 | | | / \ | | | 1.1.1.3/32		203.0.113.1/32 | | | / \ | | | 203.0.113.3/32
	PE1------R1----------A2---A4---------R3------PE3		PE1------R1----------A2---A4---------R3------PE3
	\ /| | | |\ /		\ /| | | |\ /
	\ / | +--------------+ | \ /		\ / | +--------------+ | \ /
	\ / | | \ /		\ / | | \ /
	/ | | /		/ | | /
	/ \ | | / \		/ \ | | / \
	/ \ | +--------------+ | / \		/ \ | +--------------+ | / \
	/ \| | | |/ \		/ \| | | |/ \
	PE2------R2----------B1---B3----+----R4------PE4		PE2------R2----------B1---B3----+----R4------PE4
	1.1.1.2/32 | | | \ / | | | 1.1.1.4/32		203.0.113.2/32 | | | \ / | | | 203.0.113.4/32
	SID:20 | | | / | | | SID:40		SID:20 | | | / | | | SID:40
	| | | / \ | | |		| | | / \ | | |
	+-----+-----B2---B4----+-----+		+-----+-----B2---B4----+-----+
	| |		| |
	| Group B |		| Group B |
	| 192.0.2.1/32 |		| 192.0.2.1/32 |
	| SID:200 |		| SID:200 |
	+--------------+		+--------------+
	Transit device groups		Transit device groups
	The figure above describes a network example with two groups of		The figure above describes a network example with two groups of
	transit devices. Group A consists of devices {A1, A2, A3 and A4}.		transit devices. Group A consists of devices {A1, A2, A3 and A4}.
	They are all provisioned with the anycast address 192.0.1.1/32 and		They are all provisioned with the anycast address 192.0.2.10/32 and
	the anycast SID 100.		the anycast SID 100.
	Similarly, group B consists of devices {B1, B2, B3 and B4} and are		Similarly, group B consists of devices {B1, B2, B3 and B4} and are
	all provisioned with the anycast address 192.0.1.2/32, anycast SID		all provisioned with the anycast address 192.0.2.1/32, anycast SID
	200. In the above network topology, each PE device is connected to		200. In the above network topology, each PE device is connected to
	two routers in each of the groups A and B.		two routers in each of the groups A and B.
	PE1 can choose a particular transit device group when sending traffic		PE1 can choose a particular transit device group when sending traffic
	to PE3 or PE4. This will be done by pushing the anycast SID of the		to PE3 or PE4. This will be done by pushing the anycast SID of the
	group in the stack.		group in the stack.
	Processing the anycast, and subsequent segments, requires special		Processing the anycast, and subsequent segments, requires special
	care.		care.
	Obviously, the value of the SID following the anycast SID MUST be		Obviously, the value of the SID following the anycast SID MUST be
	understood by all nodes advertising the same anycast segment.		understood by all nodes advertising the same anycast segment.
	+-------------------------+		+-------------------------+
	| Group A |		| Group A |
	| 192.0.1.1/32 |		| 192.0.2.10/32 |
	| SID:100 |		| SID:100 |
	|-------------------------|		|-------------------------|
	| |		| |
	| SRGB: SRGB: |		| SRGB: SRGB: |
	SID:10 |(1000-2000) (3000-4000)| SID:30		SID:10 |(1000-2000) (3000-4000)| SID:30
	PE1---+ +-------A1-------------A3-------+ +---PE3		PE1---+ +-------A1-------------A3-------+ +---PE3
	\ / | | \ / | | \ /		\ / | | \ / | | \ /
	\ / | | +-----+ / | | \ /		\ / | | +-----+ / | | \ /
	SRGB: \ / | | \ / | | \ / SRGB:		SRGB: \ / | | \ / | | \ / SRGB:
	(7000-8000) R1 | | \ | | R3 (6000-7000)		(7000-8000) R1 | | \ | | R3 (6000-7000)
	skipping to change at page 20, line 27 ¶		skipping to change at page 20, line 27 ¶
	11. References		11. References
	11.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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
			[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
			December 1998, <http://www.rfc-editor.org/info/rfc2460>.
			[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
			Label Switching Architecture", RFC 3031,
			DOI 10.17487/RFC3031, January 2001,
			<http://www.rfc-editor.org/info/rfc3031>.
	[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,		(GMPLS) Traffic Engineering (TE)", RFC 4206,
	DOI 10.17487/RFC4206, October 2005,		DOI 10.17487/RFC4206, October 2005,
	<http://www.rfc-editor.org/info/rfc4206>.		<http://www.rfc-editor.org/info/rfc4206>.
	11.2. Informative References		11.2. Informative References
	[I-D.filsfils-spring-large-scale-interconnect]		[I-D.filsfils-spring-large-scale-interconnect]
	Filsfils, C., Cai, D., Previdi, S., Henderickx, W.,		Filsfils, C., Cai, D., Previdi, S., Henderickx, W.,
	skipping to change at page 22, line 48 ¶		skipping to change at page 23, line 6 ¶
	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.ietf-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-ietf-spring-sr-oam-requirement-00 (work in		Network", draft-ietf-spring-sr-oam-requirement-00 (work in
	progress), June 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., Vyncke,		Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
	E., and D. Lebrun, "IPv6 Segment Routing Header (SRH)",		J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
	draft-previdi-6man-segment-routing-header-07 (work in		Routing Header (SRH)", draft-previdi-6man-segment-routing-
	progress), July 2015.		header-08 (work in progress), October 2015.
	[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.		[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
	Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",		Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
	RFC 4915, DOI 10.17487/RFC4915, June 2007,		RFC 4915, DOI 10.17487/RFC4915, June 2007,
	<http://www.rfc-editor.org/info/rfc4915>.		<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>.
End of changes. 14 change blocks.
	19 lines changed or deleted		28 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/