< draft-ietf-spring-resiliency-use-cases-02.txt		draft-ietf-spring-resiliency-use-cases-03.txt >
	Network Working Group Pierre Francois		Network Working Group Pierre Francois
	Internet-Draft Clarence Filsfils		Internet-Draft Clarence Filsfils
	Intended status: Informational Cisco Systems, Inc.		Intended status: Informational Cisco Systems, Inc.
	Expires: June 6, 2016 Bruno Decraene		Expires: October 8, 2016 Bruno Decraene
	Orange		Orange
	Rob Shakir		Rob Shakir
	Jive Communications, Inc.		Jive Communications, Inc.
	December 4, 2015		April 6, 2016
	Use-cases for Resiliency in SPRING		Use-cases for Resiliency in SPRING
	draft-ietf-spring-resiliency-use-cases-02		draft-ietf-spring-resiliency-use-cases-03
	Abstract		Abstract
	This document describes the use cases for resiliency in SPRING		This document describes the use cases for resiliency in SPRING
	networks.		networks.
	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.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 June 6, 2016.		This Internet-Draft will expire on October 8, 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 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Path protection . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Path protection . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Management free local protection . . . . . . . . . . . . . . . 4		3. Management free local protection . . . . . . . . . . . . . . . 4
	3.1. Management free bypass protection . . . . . . . . . . . . . 5		3.1. Management free bypass protection . . . . . . . . . . . . . 5
	3.2. Management-free shortest path based protection . . . . . . 5		3.2. Management-free shortest path based protection . . . . . . 5
	4. Managed local protection . . . . . . . . . . . . . . . . . . . 6		4. Managed local protection . . . . . . . . . . . . . . . . . . . 6
	4.1. Managed bypass protection . . . . . . . . . . . . . . . . . 6		4.1. Managed bypass protection . . . . . . . . . . . . . . . . . 6
	4.2. Managed shortest path protection . . . . . . . . . . . . . 6		4.2. Managed shortest path protection . . . . . . . . . . . . . 6
	5. Co-existence . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Loop avoidance . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Co-existence . . . . . . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	SPRING aims at providing a network architecture supporting services		SPRING aims at providing a network architecture supporting services
	with tight SLA guarantees [1]. This document reviews various use		with tight SLA guarantees [1]. This document reviews various use
	cases for the protection of services in a SPRING network. Note that		cases for the protection of services in a SPRING network. Note that
	these use cases are in particular applicable to existing LDP based		these use cases are in particular applicable to existing LDP based
	and pure IP networks.		and pure IP networks.
	Three key alternatives are described: path protection, local		Three key alternatives are described: path protection, local
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	The rest of the document focuses on approaches where protection is		The rest of the document focuses on approaches where protection is
	performed by the node adjacent to the failed component, commonly		performed by the node adjacent to the failed component, commonly
	referred to as local protection techniques or Fast Reroute		referred to as local protection techniques or Fast Reroute
	techniques.		techniques.
	We discuss two different approaches to provide unmanaged local		We discuss two different approaches to provide unmanaged local
	protection, namely link/node bypass protection and shortest path		protection, namely link/node bypass protection and shortest path
	based protection, in Section 3.		based protection, in Section 3.
			In Section 5, we discuss the opportunity for the SPRING architecture
			to provide loop-avoidance mechanisms, such that transient forwarding
			state inconsistencies during routing convergence does not lead to
			traffic loss.
	A case is then made to allow the operator to manage the local		A case is then made to allow the operator to manage the local
	protection behavior in order to accommodate specific policies, in		protection behavior in order to accommodate specific policies, in
	Section 4.		Section 4.
	The purpose of this document is to illustrate the different		The purpose of this document is to illustrate the different
	approaches and explain how an operator could combine them in the same		approaches and explain how an operator could combine them in the same
	network (see Section 5). Solutions are not defined in this document.		network (see Section 6). Solutions are not defined in this document.
	B------C------D------E		B------C------D------E
	/| | \ / | \ / |\		/| | \ / | \ / |\
	/ | | \/ | \/ | \		/ | | \/ | \/ | \
	A | | /\ | /\ | Z		A | | /\ | /\ | Z
	\ | | / \ | / \ | /		\ | | / \ | / \ | /
	\| |/ \|/ \|/		\| |/ \|/ \|/
	F------G------H------I		F------G------H------I
	Figure 1: Reference topology		Figure 1: Reference topology
	skipping to change at page 7, line 15 ¶		skipping to change at page 7, line 15 ¶
	B * * *C------D------E		B * * *C------D------E
	*| * \ / | \ * |*		*| * \ / | \ * |*
	* | * \/ | \* | *		* | * \/ | \* | *
	A | * /\ | *\ | Z		A | * /\ | *\ | Z
	\ | * / \ | * \ | *		\ | * / \ | * \ | *
	\| */ \|* \|*		\| */ \|* \|*
	F------G * * *H * * *I		F------G * * *H * * *I
	Figure 5: Managed shortest path protection		Figure 5: Managed shortest path protection
	5. Co-existence		5. Loop avoidance
			Transient inconsistencies among the Forwarding Information Bases of
			routers converging after a change in the state of links of the
			network can occur. Such inconsistencies (some nodes forwarding
			traffic according to the past network topology while some other nodes
			are forwarding packets according to the new topology) may lead to
			forwarding loops.
			The SPRING architecture SHOULD provide solutions to prevent the
			occurrence of micro-loops during convergence following a change in
			the network state. A SPRING enabled router could take advantage of
			the increased packet steering capabilities offered by SPRING in order
			to steer packets in a way that packets do not enter such loops.
			6. Co-existence
	The operator may want to support several very-different services on		The operator may want to support several very-different services on
	the same packet-switching infrastructure. As a result, the SPRING		the same packet-switching infrastructure. As a result, the SPRING
	architecture SHOULD allow for the co-existence of the different use		architecture SHOULD allow for the co-existence of the different use
	cases listed in this document, in the same network.		cases listed in this document, in the same network.
	Let us illustrate this with the following example.		Let us illustrate this with the following example.
	o Flow F1 is supported over path {C, C-D, E}		o Flow F1 is supported over path {C, C-D, E}
	o Flow F2 is supported over path {C, C-D, I)		o Flow F2 is supported over path {C, C-D, I)
	o Flow F3 is supported over path {C, C-D, Z)		o Flow F3 is supported over path {C, C-D, Z)
	o Flow F4 is supported over path {C, C-D, Z}		o Flow F4 is supported over path {C, C-D, Z}
	o It should be possible for the operator to configure the network to		o It should be possible for the operator to configure the network to
	achieve path protection for F1, management free shortest path		achieve path protection for F1, management free shortest path
	local protection for F2, managed protection over path {C-G, G-H,		local protection for F2, managed protection over path {C-G, G-H,
	Z} for F3, and management free bypass protection for F4.		Z} for F3, and management free bypass protection for F4.
	6. References		7. References
	[1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and r.		[1] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R.
	rjs@rob.sh, "Segment Routing Architecture",		Shakir, "Segment Routing Architecture",
	draft-ietf-spring-segment-routing-06 (work in progress),		draft-ietf-spring-segment-routing-07 (work in progress),
	October 2015.		December 2015.
	Authors' Addresses		Authors' Addresses
	Pierre Francois		Pierre Francois
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Vimercate		Vimercate
	IT		IT
	Email: pifranco@cisco.com		Email: pifranco@cisco.com
	Clarence Filsfils		Clarence Filsfils
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Brussels		Brussels
	BE		BE
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	Bruno Decraene		Bruno Decraene
	Orange		Orange
	Issy-les-Moulineaux		Issy-les-Moulineaux
End of changes. 12 change blocks.
	15 lines changed or deleted		37 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/