< draft-ietf-spring-ipv6-use-cases-05.txt		draft-ietf-spring-ipv6-use-cases-06.txt >
	Spring J. Brzozowski		Spring J. Brzozowski
	Internet-Draft J. Leddy		Internet-Draft J. Leddy
	Intended status: Informational Comcast		Intended status: Informational Comcast
	Expires: March 4, 2016 I. Leung		Expires: September 4, 2016 I. Leung
	Rogers Communications		Rogers Communications
	S. Previdi		S. Previdi
	M. Townsley		M. Townsley
	C. Martin		C. Martin
	C. Filsfils		C. Filsfils
	R. Maglione, Ed.		R. Maglione, Ed.
	Cisco Systems		Cisco Systems
	September 2015		March 3, 2016
	IPv6 SPRING Use Cases		IPv6 SPRING Use Cases
	draft-ietf-spring-ipv6-use-cases-05		draft-ietf-spring-ipv6-use-cases-06
	Abstract		Abstract
	Source Packet Routing in Networking (SPRING) architecture leverages		Source Packet Routing in Networking (SPRING) architecture leverages
	the source routing paradigm. A node steers a packet through a		the source routing paradigm. A node steers a packet through a
	controlled set of instructions, called segments, by prepending the		controlled set of instructions, called segments, by prepending the
	packet with SPRING header. A segment can represent any instruction,		packet with SPRING header. A segment can represent any instruction,
	topological or service-based. A segment can have a local semantic to		topological or service-based. A segment can have a local semantic to
	the SPRING node or global within the SPRING domain. SPRING allows to		the SPRING node or global within the SPRING domain. SPRING allows to
	enforce a flow through any topological path and service chain while		enforce a flow through any topological path and service chain while
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 4, 2016.		This Internet-Draft will expire on September 4, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	other than the source, such that the source is the only node that		other than the source, such that the source is the only node that
	knows and will know the path a packet will take, a priori		knows and will know the path a packet will take, a priori
	4. There is a need to connect millions of addressable segment		4. There is a need to connect millions of addressable segment
	endpoints, thus high routing scalability is a requirement. IPv6		endpoints, thus high routing scalability is a requirement. IPv6
	addresses are inherently summarizable: a very large operator		addresses are inherently summarizable: a very large operator
	could scale by summarizing IPv6 subnets at various internal		could scale by summarizing IPv6 subnets at various internal
	boundaries. This is very simple and is a basic property of IP		boundaries. This is very simple and is a basic property of IP
	routing. MPLS node segments are not summarizable. To reach the		routing. MPLS node segments are not summarizable. To reach the
	same scale, an operator would need to introduce additional		same scale, an operator would need to introduce additional
	complexity, such as mechanisms described in		complexity, such as mechanisms known with the industry term
	[I-D.ietf-mpls-seamless-mpls]		Seamless MPLS.
	In any environment with requirements such as those listed above, an		In any environment with requirements such as those listed above, an
	IPv6 data plane provides a powerful combination of capabilities for a		IPv6 data plane provides a powerful combination of capabilities for a
	network operator to realize benefits in explicit routing, protection		network operator to realize benefits in explicit routing, protection
	and restoration, high routing scalability, traffic engineering,		and restoration, high routing scalability, traffic engineering,
	service chaining, service differentiation and application flexibility		service chaining, service differentiation and application flexibility
	via programmability.		via programmability.
	This section will describe some scenarios where MPLS may not be		This section will describe some scenarios where MPLS may not be
	present and it will highlight how the SPRING architecture could be		present and it will highlight how the SPRING architecture could be
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 28 ¶
	5. Egress Peering Engineering		5. Egress Peering Engineering
	2.1. SPRING in the Home Network		2.1. SPRING in the Home Network
	An IPv6-enabled home network provides ample globally routed IP		An IPv6-enabled home network provides ample globally routed IP
	addresses for all devices in the home. An IPv6 home network with		addresses for all devices in the home. An IPv6 home network with
	multiple egress points and associated provider-assigned prefixes		multiple egress points and associated provider-assigned prefixes
	will, in turn, provide multiple IPv6 addresses to hosts. A homenet		will, in turn, provide multiple IPv6 addresses to hosts. A homenet
	performing Source and Destination Routing		performing Source and Destination Routing
	([I-D.lamparter-rtgwg-dst-src-routing]) will ensure that packets exit		([I-D.ietf-rtgwg-dst-src-routing]) will ensure that packets exit the
	the home at the appropriate egress based on the associated delegated		home at the appropriate egress based on the associated delegated
	prefix for that link.		prefix for that link.
	A SPRING enabled home provides the possibility for imposition of a		A SPRING enabled home provides the possibility for imposition of a
	Segment List by end-hosts in the home, or a customer edge router in		Segment List by end-hosts in the home, or a customer edge router in
	the home. If the Segment List is enabled at the customer edge		the home. If the Segment List is enabled at the customer edge
	router, that router is responsible for classifying traffic and		router, that router is responsible for classifying traffic and
	inserting the appropriate Segment List. If hosts in the home have		inserting the appropriate Segment List. If hosts in the home have
	explicit source selection rules, classification can be based on		explicit source selection rules, classification can be based on
	source address or associated network egress point, avoiding the need		source address or associated network egress point, avoiding the need
	for DPI-based implicit classification techniques. If the Segment		for DPI-based implicit classification techniques. If the Segment
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 37 ¶
	either dedicated physical servers or within VMs running on a		either dedicated physical servers or within VMs running on a
	virtualization platform.		virtualization platform.
	[I-D.ietf-sfc-dc-use-cases] describes use cases that demonstrate the		[I-D.ietf-sfc-dc-use-cases] describes use cases that demonstrate the
	applicability of Service Function Chaining (SFC) within a data center		applicability of Service Function Chaining (SFC) within a data center
	environment and provides SFC requirements for data center centric use		environment and provides SFC requirements for data center centric use
	cases.		cases.
	2.3.1. VM isolation in a Data Center		2.3.1. VM isolation in a Data Center
	[I-D.baker-openstack-ipv6-model] describes a network model for an		One of the fundamental requirements for Data Center architecture is
	OpenStack Data center which is designed to dramatically simplify		to provide scalable, isolated tenant networks. Today with OpenStack
	scalable network deployment and operations. This model proposes the		Networking (Neutron) this can be achieved via L2 segmentation using
	use of information within the IPv6 header in order to provide tenant		either a) standard 802.1Q VLANs or b) an overlay approach based on
	VM group isolation without relying on layer 2 logical separation.		one of several L2 over L3 encapsulation techniques available today
			such as 802.1ad, VXLAN, NVGRE. However, these approaches still
			struggle to provide scalable, transparent, manageable, high
			performance, isolated tenant networks.
	The 128-bit PE Ingress ID in the SRH policy list provides a natural		The 128-bit PE Ingress ID in the Segment Router Header (SRH) policy
	place to encode origin information of VM to VM traffic within the		list defined in [I-D.previdi-6man-segment-routing-header] provides a
	Data Center. The Segment List provides a method to direct traffic to		natural place to encode origin information of VM to VM traffic within
	a specific enforcement point based on traffic destination. Together,		the Data Center. The Segment List provides a method to direct
	these allow for a simple tagging and permit/deny comparison performed		traffic to a specific enforcement point based on traffic destination.
	between twin SR-capable nodes (e.g., the Neutron Virtual Router)		Together, these allow for a simple tagging and permit/deny comparison
	among VMs in a Data Center.		performed between twin SR-capable nodes (e.g., the Neutron Virtual
			Router) among VMs in a Data Center.
	2.4. SPRING in the Content Delivery Networks		2.4. SPRING in the Content Delivery Networks
	The rise of online video applications and new, video-capable IP		The rise of online video applications and new, video-capable IP
	devices has led to an explosion of video traffic traversing network		devices has led to an explosion of video traffic traversing network
	operator infrastructures. In the drive to reduce the capital and		operator infrastructures. In the drive to reduce the capital and
	operational impact of the massive influx of online video traffic, as		operational impact of the massive influx of online video traffic, as
	well as to extend traditional TV services to new devices and screens,		well as to extend traditional TV services to new devices and screens,
	network operators are increasingly turning to Content Delivery		network operators are increasingly turning to Content Delivery
	Networks (CDNs).		Networks (CDNs).
	skipping to change at page 10, line 29 ¶		skipping to change at page 10, line 32 ¶
	raise.		raise.
	The described use cases could be addressed with the SPRING		The described use cases could be addressed with the SPRING
	architecture by having the Edge nodes of network to impose a Segment		architecture by having the Edge nodes of network to impose a Segment
	List on specific traffic flows, based on certain classification		List on specific traffic flows, based on certain classification
	criteria that would include source IPv6 address.		criteria that would include source IPv6 address.
	3. Acknowledgements		3. Acknowledgements
	The authors would like to thank Brian Field, Robert Raszuk, Wes		The authors would like to thank Brian Field, Robert Raszuk, Wes
	George, Eric Vyncke, John G. Scudder and Yakov Rekhter for their		George, Eric Vyncke, Fred Baker, John G. Scudder and Yakov Rekhter
	valuable comments and inputs to this document.		for their valuable comments and inputs to this document.
	4. IANA Considerations		4. IANA Considerations
	This document does not require any action from IANA.		This document does not require any action from IANA.
	5. Security Considerations		5. Security Considerations
	There are a number of security concerns with source routing at the IP		There are a number of security concerns with source routing at the IP
	layer [RFC5095]. Security mechanisms applied to Segment Routing over		layer [RFC5095]. Security mechanisms applied to Segment Routing over
	IPv6 networks are detailed in section 9 of		IPv6 networks are detailed in section 9 of
	[I-D.previdi-6man-segment-routing-header]		[I-D.previdi-6man-segment-routing-header]
	6. Informative References		6. Informative References
	[I-D.baker-openstack-ipv6-model]
	Baker, F., Marino, C., Wells, I., Agarwalla, R., Jeuk, S.,
	and G. Salgueiro, "A Model for IPv6 Operation in
	OpenStack", draft-baker-openstack-ipv6-model-02 (work in
	progress), February 2015.
	[I-D.ietf-mif-mpvd-dhcp-support]		[I-D.ietf-mif-mpvd-dhcp-support]
	Krishnan, S., Korhonen, J., and S. Bhandari, "Support for		Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
	multiple provisioning domains in DHCPv6", draft-ietf-mif-		multiple provisioning domains in DHCPv6", draft-ietf-mif-
	mpvd-dhcp-support-01 (work in progress), March 2015.		mpvd-dhcp-support-02 (work in progress), October 2015.
	[I-D.ietf-mpls-seamless-mpls]		[I-D.ietf-rtgwg-dst-src-routing]
	Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,		Lamparter, D., "Destination/Source Routing", draft-ietf-
	M., and D. Steinberg, "Seamless MPLS Architecture", draft-		rtgwg-dst-src-routing-00 (work in progress), October 2015.
	ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
	[I-D.ietf-sfc-dc-use-cases]		[I-D.ietf-sfc-dc-use-cases]
	Surendra, S., Tufail, M., Majee, S., Captari, C., and S.		Surendra, S., Tufail, M., Majee, S., Captari, C., and S.
	Homma, "Service Function Chaining Use Cases In Data		Homma, "Service Function Chaining Use Cases In Data
	Centers", draft-ietf-sfc-dc-use-cases-03 (work in		Centers", draft-ietf-sfc-dc-use-cases-04 (work in
	progress), July 2015.		progress), January 2016.
	[I-D.ietf-sfc-nsh]		[I-D.ietf-sfc-nsh]
	Quinn, P. and U. Elzur, "Network Service Header", draft-		Quinn, P. and U. Elzur, "Network Service Header", draft-
	ietf-sfc-nsh-01 (work in progress), July 2015.		ietf-sfc-nsh-02 (work in progress), January 2016.
	[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-07
	(work in progress), April 2015.		(work in progress), March 2016.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and r. rjs@rob.sh, "Segment Routing Architecture", draft-		and R. Shakir, "Segment Routing Architecture", draft-ietf-
	ietf-spring-segment-routing-04 (work in progress), July		spring-segment-routing-07 (work in progress), December
	2015.		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-03 (work in
	progress), May 2015.		progress), February 2016.
	[I-D.lamparter-rtgwg-dst-src-routing]
	Lamparter, D., "Destination/Source Routing", draft-
	lamparter-rtgwg-dst-src-routing-01 (work in 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.
	[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,		[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
	"Connecting IPv6 Islands over IPv4 MPLS Using IPv6		"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
	Provider Edge Routers (6PE)", RFC 4798,		Provider Edge Routers (6PE)", RFC 4798,
	DOI 10.17487/RFC4798, February 2007,		DOI 10.17487/RFC4798, February 2007,
	<http://www.rfc-editor.org/info/rfc4798>.		<http://www.rfc-editor.org/info/rfc4798>.
	[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,
End of changes. 19 change blocks.
	52 lines changed or deleted		44 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/