< draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00.txt		draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01.txt >
	Routing Area Working Group S. Litkowski		Routing Area Working Group S. Litkowski
	Internet-Draft B. Decraene		Internet-Draft B. Decraene
	Intended status: Standards Track Orange		Intended status: Standards Track Orange
	Expires: May 17, 2013 C. Fils Fils		Expires: August 22, 2013 C. FilsFils
	K. Raza		K. Raza
	Cisco Systems		Cisco Systems
	November 13, 2012		February 18, 2013
	Interactions between LFA and RSVP-TE		Interactions between LFA and RSVP-TE
	draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00		draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01
	Abstract		Abstract
	RSVP-TE FRR is a well known and deployed technology for fast reroute,		This document defines the behavior of a node supporting Loopfree
	and there are some use cases where LFA and RSVP-TE may interact.		Alternates (LFA) when the node has established RSVP TE tunnels. It
	This document clarifies the behavior of LFA when RSVP-TE tunnels are		first describes the decisions to be made by the LFA mechanism with
	used simultaneously.		respect to the use of TE tunnels as LFA candidates. Second, it
			discusses the use of RSVP TE tunnels as a way to complement the LFA
			coverage, illustrating how these technologies can benefit from each
			other.
			Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [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 May 17, 2013.		This Internet-Draft will expire on August 22, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. LFA FRR and MPLS TE FRR interaction . . . . . . . . . . . . . 3		2. LFA FRR and MPLS-TE interactions . . . . . . . . . . . . . . . 3
	2.1. LFA on TE head end router . . . . . . . . . . . . . . . . 3		2.1. Use case : using MPLS LSP as LFA candidates . . . . . . . 3
	2.1.1. LFA and TE IGP shortcut . . . . . . . . . . . . . . . 3		2.2. Specifications of interactions between LFA and TE LSP . . 4
	2.1.2. TE tunnel as an LFA candidate . . . . . . . . . . . . 4		2.2.1. Having both a physical interface and a TE tunnel
	2.1.3. LFA candidate TE tunnel and TE IGP shortcut . . . . . 4		toward a LFA . . . . . . . . . . . . . . . . . . . . . 4
	2.1.4. LFA and TE tunnel to a directly connected neighbor . . 4		2.2.2. TE ingress LSP as LFA candidate . . . . . . . . . . . 5
	2.2. LFA on TE midpoint router . . . . . . . . . . . . . . . . 4		2.2.3. Independence between LFA and TE FRR . . . . . . . . . 5
	3. Need for LFA and RSVP-TE interactions . . . . . . . . . . . . 4		3. Operational considerations . . . . . . . . . . . . . . . . . . 7
	3.1. Network with some already deployed RSVP-TE tunnels . . . . 5		3.1. Relevance of joint LFA FRR and RSVP-TE FRR deployments . . 7
	3.2. Network with no protection at all . . . . . . . . . . . . 5		3.2. Extending LFA coverage using RSVP-TE tunnels . . . . . . . 8
	4. LFA FRR and MPLS TE FRR interaction scenarios . . . . . . . . 5		3.2.1. Creating multihop tunnel to extend topology . . . . . 8
	4.1. LFA activated on RSVP-TE tunnel headend . . . . . . . . . 5		3.2.2. Selecting multihop tunnels to extend topology . . . . 9
	4.2. LFA activated on RSVP-TE tunnel midpoint . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5. Extending LFA coverage using RSVP-TE tunnels . . . . . . . . . 7		5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Reference topology . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5.2. Creating multihop tunnel to extend topology . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		When a failure occurs in an IP network, the subsequent converge
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		process often leads to traffic disruption. Some mechanisms are
	document are to be interpreted as described in [RFC2119].		available to limit traffic disruptions by pre-computing alternate
			paths and locally reroute over these as soon as the failure is
	This document is being discussed on the rtgwg@ietf.org mailing list.		detected. Such techniques are commonly known as "protection
			mechanisms". Currently, the protection mechanisms widely used in
			Service Provider networks are RSVP-TE Fast Reroute [RFC4090] and Loop
			Free Alternates [RFC5286]. RSVP-TE FRR permits full network coverage
			but with a quite high complexity in terms of operation, as well as
			potential scaling issues. On the other hand, LFA offer a very easy,
			manageable, and scalable mechanism, but does not provide full
			coverage.
	When a failure occurs inside an IP network, network has to converge.		This document discusses how LFA and RSVP-TE should interact. It
	This convergence leads to traffic disruption. Some mechanisms are		first describes how an LFA implementation should deal with existing
	already available to limit traffic disruption by computing alternate		RSVP TE tunnels established by the LFA node, as well as its behavior
	path and switching locally to alternate path as soon as failure is		with respect to established IGP Shortcut tunnels [RFC3906]. Second,
	detected. All this can be termed as a protection mechanism.		the document suggets the use of RSVP-TE tunnels to extend LFA
	Currently, the widely used protection mechanisms for traffic are (i)		coverage, and discusses the management and operational aspects of
	RSVP-TE Fast Reroute [RFC4090] and Loop Free Alternates [RFC5286].		such a practice.
	Both have pros and cons. For example, RSVP-TE FRR permits full
	network coverage but with a quite high complexity in terms of
	operation as well as potential scaling issues. Whereas, LFA is a
	very easy, manageable and quite scalable mechanism but it does not
	provides full coverage.
	This document presents some scenarios where LFA and RSVP-TE may		2. LFA FRR and MPLS-TE interactions
	interact. The document also proposes the usage of RSVP-TE tunnels to
	extend LFA coverage and clarifies interactions between the two
	protection mechanisms.
	2. LFA FRR and MPLS TE FRR interaction		This section discusses the various interactions among LFA FRR and
			MPLS-TE FRR. It starts with a simple example emphasizing the
			benefits of jointly using of LFA-FRR and MPLS-TE FRR, and then
			summarizes the requirements for the interactions between LFAs and
			MPLS-FRR.
	This section provides the summarized normative requirements for the		2.1. Use case : using MPLS LSP as LFA candidates
	interaction between LFA FRR and TE FRR. Following sections provide
	illustration and reasoning why an operator may care for these
	behavior.
	2.1. LFA on TE head end router		In some cases, typically in ring shapped parts of network topologies,
			links cannot be protected by LFAs. In the following topology, from
			the point of view of R5, LFAs are able to partiatlly protect (49% of
			the destination routers) from the failure of R3, while the failure of
			R4 is not covered at all.
	2.1.1. LFA and TE IGP shortcut		(30 routers) --- R1 ----(30)---- R2 --- (50 routers)
			| |
			(5) (30)
			| |
			R3 R4 --- (20 routers)
			| |
			(10) (30)
			| |
			------- R5 ------
	If a node N has an IGP/LDP forwarding entry F1 with outgoing		Figure 1
	interface i1 and an IGP/LDP forwarding entry F2 with outgoing
	interface onto a TE tunnel T2 (due to IGP shortcut [RFC3906]) and
	tunnel T2 has outgoing interface i2, then an implementation MUST
	support enabling LFA FRR for F1 and using TE FRR for F2 as long as i1
	!= i2.
	If i1 == i2, an implementation SHOULD allow for using LFA FRR backup		Many networks deploy MPLS tunnels for traffic engineering and
	for F1 and TE FRR backup for F2.		resiliency reasons. To extend its benefit, an LFA implementation
			could take advantage of such existing MPLS tunnels. In the exemple
			above, if R5 has established TE tunnels bypassing R4 and R3, these
			could be considerd as LFA candidates respectively protecting links
			from R5 to R4 and R3.
	2.1.2. TE tunnel as an LFA candidate		In the following section, we provide a detailed summary of the
			behavior to be applied by an LFA implementation which would consider
			the existence of MPLS TE tunnels to improve its applicability. The
			explicit configuration of such tunnels with the intent of improving
			LFA applicability is discussed in later sections.
	TE tunnel LFA candidate mechanism is the ability to use a TE tunnel		2.2. Specifications of interactions between LFA and TE LSP
	as a virtual neighbor in LFA computation.
	If a node N has an IGP/LDP forwarding entry F1 with outgoing		Here we summarize the normative requirements for the interaction
	interface i1 and N originates a TE tunnel T1 terminating at node Y,		between LFA FRR and MPLS TE tunnels.
	then an implementation SHOULD support a local policy which instructs
	node N to consider Y as a virtual neighbor and hence include Y as
	part of the LFA FRR alternate computation. In such case, an
	implementation MUST not use Y as an LFA for F1 if T1's outgoing
	interface is i1.
	This would permit to extend LFA coverage as described in		2.2.1. Having both a physical interface and a TE tunnel toward a LFA
	[I-D.ietf-rtgwg-remote-lfa]
	2.1.3. LFA candidate TE tunnel and TE IGP shortcut		If a node S has both a physical interface and a TE tunnel to reach a
			LFA, it SHOULD use the physical interface unless :
	The mechanisms for using TE tunnel as an LFA candidate, and RFC3906		1. The tunnel has been explicitly configured as an LFA candidate.
	mechanisms MUST be de-correlated -- i.e an implementation MUST
	support TE tunnel configuration with RFC3906 only, as LFA candidate
	only, or both at the same time.
	2.1.4. LFA and TE tunnel to a directly connected neighbor		2. The tunnel does not pass through the link subject to LFA
			protection.
	If a node N has an IGP/LDP forwarding entry F1 with outgoing		In other words, if a node S has an IGP/LDP forwarding entry F1 with
	interface i1, and N originates a TE tunnel T2 terminating on direct		outgoing interface i1, and S originates a TE tunnel T2 terminating on
	neighbor N2 (for example : if a TE tunnel is provisionned for link		direct neighbor N2 (for example : if a TE tunnel is provisionned for
	protection), T2 has an outgoing interface i2 and N2 is best LFA for		link protection), T2 has an outgoing interface i2 and N2 is best LFA
	F1, then an implementation MUST NOT use T2 when programming LFA		for F1, then an implementation MUST NOT use T2 when programming LFA
	repair for F1 unless T2 is configured as an LFA candidate.		repair for F1 unless T2 is configured as an LFA candidate.
	2.2. LFA on TE midpoint router		2.2.2. TE ingress LSP as LFA candidate
	If a node N has an IGP/LDP forwarding entry F1 with outgoing		A TE LSP can be used as a virtual interface to reach a LFA if
	interface i1 and a MPLS TE midpoint forwarding entry F2 with outgoing
	interface i2, then an implementation MUST support using LFA FRR for
	F1 and TE FRR for F2 as long as i1 != i2.
	If i1 == i2, an implementation SHOULD allow for using LFA FRR backup		1. The TE tunnel has been configured to allow its use as an LFA
	for F1 and TE FRR backup for F2.		candidate.
	3. Need for LFA and RSVP-TE interactions		2. The TE tunnel does not pass through the primary outgoing
			interface of D.
	This section describes some of the deployment scenarios where LFA and		This would permit to extend LFA coverage as described in
	RSVP-TE may interact.		[I-D.ietf-rtgwg-remote-lfa], in a controlled fashioned, as the
			tunnels used by the fast reroute mechanism are defined by
			configuration.
	3.1. Network with some already deployed RSVP-TE tunnels		In other words, if a node S has an IGP/LDP forwarding entry F1 with
			outgoing interface i1 and S originates a TE tunnel T1 terminating at
			node Y, then an implementation SHOULD support a local policy which
			instructs node S to consider Y as a virtual neighbor and hence
			include Y as part of the LFA FRR alternate computation. In such
			case, an implementation MUST not use Y as an LFA for F1 if T1's
			outgoing interface is i1.
	There are many networks where RSVP-TE is already deployed. The		2.2.3. Independence between LFA and TE FRR
	deployment of RSVP-TE is typically for two main reasons :
	o Traffic engineering : a provider wants to route some flows on some		2.2.3.1. Tunnel head-end case
	specific paths using constraints;
	o Traffic protection using Fast-reroute ability		Similar requirements can be expressed for TE IGP shortcut tunnels.
	LFA is a feature that may bring benefits on RSVP-TE enabled networks,		-----C1 ---------
	with no/minimal operational cost (compared to RSVP-TE FRR global roll		/ | \
	out). These benefits include:		/ | \
			PE1 ---- C2 --- C3 ---- PE2
			| /
			PE3
	o Should increase protection on network where FRR is not available		Figure 2
	everywhere. Although it may not provide full coverage, it will
	increase the protection significantly.
	o May provide better protection in specific cases than RSVP-TE FRR		PE to Cx metrics are 50, Cx to Cx are 1
	3.2. Network with no protection at all		A service provider is often providing traffic-engineered path for
			specific customer traffic (L3VPN, PW ...) to ensure path diversity or
			traffic constraints. In the diagram above, we consider a TE tunnel
			T2 built on a non shortest path as follows : PE1->C2->C3->PE2 and IGP
			shortcut is activated on PE1 to make traffic to PE2 using T2. Based
			on operational feedback, some implementations prevent LFA computation
			to run for an interface where a TE tunnel exists. In our example, if
			LFA is activated on N, we would not be able to have a protection for
			PE3 destination as a tunnel exists on the interface. This current
			observed behavior leads to a very limited coverage for LFA. In the
			other hand, it is important to keep protection mechanisms independant
			as much as possible to keep implementation simple. We propose the
			following approach :
	For IP networks that do not have any traffic protection mechanism,		o If an IP prefix is reachable through a TE tunnel, LFA must not
	LFA is a very good first step to provide traffic protection even if		compute a protection for it.
	its coverage is not 100%.
	Providers may want to increase protection coverage if LFA benefit is		o If an IP prefix is reachable through a native IP path, LFA MUST
	not sufficient for some destinations. The following sections		compute a protection for it disregarding the presence of a tunnel
	describe usage of basic RSVP-TE tunnels to extend protection		or not on the primary interface.
	coverage.
	4. LFA FRR and MPLS TE FRR interaction scenarios		In other words, if a node S has an IGP/LDP forwarding entry F1 with
			outgoing interface i1 and an IGP/LDP forwarding entry F2 with
			outgoing interface onto a TE tunnel T2 (due to IGP shortcut
			[RFC3906]) and tunnel T2 has outgoing interface i2, then an
			implementation MUST support enabling LFA FRR for F1 and using TE FRR
			for F2 as long as i1 != i2.
	4.1. LFA activated on RSVP-TE tunnel headend		If i1 == i2, an implementation SHOULD allow for using LFA FRR backup
			for F1 and TE FRR backup for F2.
	R4 --(10)- R5 -(1)- R6 -(10)- R7		The mechanisms for using TE tunnel as an LFA candidate, and RFC3906
	| |		mechanisms MUST be de-correlated -- i.e an implementation MUST
	(10) ---(30)----R14--(10)----- (10)		support TE tunnel configuration with RFC3906 only, as LFA candidate
	| / \ |		only, or both at the same time.
	R1 -R2 -(100)-- R3 --(22)--- R8 ---(10)------- R9 --(100)-- R10 ---- R11
	/ / | |
	(10) (10) (40) |
	| / | |
	R16-(200)-R15 R12 --(1)-- R13--------(5)------
	Figure 1		2.2.3.2. Tunnel midpoint case
	In figure 1, shortest path from R1 to R11 is : R1-R2-R3-R8-R9-R10-		-----C1 ---------
	R11.		/ | \
			/ | \
			PE1 ---- C2 --- C3 ---- PE2
			| /
			PE3
	An RSVP-TE tunnel (tunnel1) is configured on R3 towards R10 using		Figure 3
	constrained path R4-R5-R6-R7-R9-R10, and another tunnel (tunnel2) is
	configured towards R8 using IGP path (with no constraints). IGP
	shortcut ([RFC3906]) is activated on R3, leading to the following
	forwarding informations (not exhaustive) on R3 :
	o R8 and R9 via tunnel2		PE to Cx metrics are 50, except PE3-C3 (60), Cx to Cx are 1In the
			diagram above, we consider a TE tunnel T2 built on a non shortest
			path as follows : PE1->C2->C3->PE2 and IGP shortcut is activated on
			PE1 to make traffic to PE2 using T2. C2 is a TE tunnel midpoint
			router. In terms of forwarding, C2 has a MPLS TE forwarding entry
			for T2, as well as an IP forwarding entry to PE2. As explained in
			previous sections, it would be too restrictive and would limit LFA
			benefit on C2 if C2 would not be able to compute an LFA for the IP
			forwarding entry to PE2 due to the presence of a transit tunnel.
	o R10 and R11 via tunnel1		We propose the following approach for a midpoint router of a TE
			tunnel :
	o R4 and R5 via R4		o MPLS TE forwarding entries MUST not be protected by LFA (if an
			operator wants protection, TE FRR could be enabled).
	o R14 via R14		o IP forwarding entries MUST be protected by LFA disregarding the
			presence of a TE tunnel transiting through the primary interface
			of the destination.
	Per destination LFA is also activated on R3		In our example :
	Based on the normative principles already described, here are the FRR		o MPLS TE forwarding entry for T2 (ending on PE2) would be protected
	backup paths :		by TE-FRR (if enabled).
	o R8, R9, R10 and R11 are forwarded via an RSVP-TE tunnel, so there		o IP forwarding entry for PE2 would be protected by LFA.
	will be no LFA programmed, TE FRR may be used for protection, if
	available.
	o R14 has primary nexthop R14, LFA computed to protect R14 is R8,		In case of failure of C2-C3 :
	but R8 is primarily reachable through tunnel2. As defined in
	normative principles, backup forwarding entry for R14 will be
	programmed to direct neighbor (R8) rather than using tunnel2.
	o R4 has primary nexthop R4, alternate is R12. (no ambiguity in this		o traffic from PE1 to PE2 (encapsulated in T2), would be protected
	case as no tunnel is involved)		by TE FRR.
	o R16,R15,R2,R1 are not covered because though alternate paths exist		o traffic from PE3 to PE2 (native IP), would be protected by LFA.
	but they are not loop free. We could envisage to create a new TE
	tunnel to provide more path diversity using loop free tunnel
	endpoints. For example, we could create a tunnel from R3 to R16
	(explicity routed through R15), that is configured only as an LFA
	candidate, to provide loop free alternate to R1 and R2.
	4.2. LFA activated on RSVP-TE tunnel midpoint		In other words, if a node S has an IGP/LDP forwarding entry F1 with
	R4 --(10)-- R5 -(1)- R6 -(10)- R7		outgoing interface i1 and a MPLS TE midpoint forwarding entry F2 with
	| | |		outgoing interface i2, then an implementation MUST support using LFA
	(10) (60) (10)		FRR for F1 and TE FRR for F2 as long as i1 != i2.
	| | |
	R1 -R2 -(100)-- R3 --(22)--- R8 ---(10)------- R9 --(100)-- R10 ---- R11
	| |
	(40) |
	| |
	R12 --(1)-- R13--------(5)------
	Figure 3		If i1 == i2, an implementation SHOULD allow for using LFA FRR backup
			for F1 and TE FRR backup for F2.
	In figure 3, RSVP-TE tunnel is configured from R3 to R9 using		3. Operational considerations
	constrained path R4-R5-R6-R7. R4 to R7 routers are midpoints of
	tunnels, and they are receiving tunneled packets as well as native IP
	packets on their interface. We consider LFA implemented on R5.
	As explained in normative principles, IP prefixes will be programmed		In this section, we first discuss the benefit of considering a joint
	with LFA alternate as backup entry (if available) and MPLS ILM		deployment of LFA and MPLS tunnels to achieve resiliency. We then
	(Incoming label map) of transit TE tunnel will not use LFA alternate		discuss one approach aiming at defining MPLS tunnels for the purpose
	as backup NHLFE even if there is a LFA to reach tunnel tail-end (TE		of complementing LFA coverage.
	use his own protection).
	In our figure 3, R5 receives native IP traffic from R4 to R10 and		3.1. Relevance of joint LFA FRR and RSVP-TE FRR deployments
	tunneled traffic from R1 to R11 (tunneling done by R3). R5 computes
	LFAs for all destinations. R8 is an alternate to reach R10, as well
	as to reach R11 and R9. When link R5->R6 fails, traffic from R4 is
	switched to alternate R8 (protection by LFA), but traffic from R1 to
	R11 may be dropped (in case of tunnel without protection) or switched
	to RSVP-TE protection path (in case tunnel has protection).
	5. Extending LFA coverage using RSVP-TE tunnels		This section describes the deployment scenarios where it can be
			beneficial to jointly use LFAs and RSVP-TE FRR.
	We already have seen in previous section that creating RSVP-TE		There are many networks where RSVP-TE is already deployed. The
	tunnels would increase LFA coverage. The choice of tunnel placement		deployment of RSVP-TE is typically for two main reasons :
	should depend on what type of protection (link or node) we want to
	achieve, as well as on the set of destinations we want to protect.
	5.1. Reference topology		o Traffic engineering : a provider wants to route some flows on some
			specific paths using constraints;
	Some topologies like rings do not work well with LFA. We consider		o Traffic protection using Fast-reroute ability
	the following topology in our document for further illustration.
	(30 routers) --- R1 ----(30)---- R2 --- (50 routers)		LFA is a feature that may bring benefits on RSVP-TE enabled networks,
	| |		with no/minimal operational cost (compared to RSVP-TE FRR global roll
	(5) (30)		out). These benefits include:
	| |
	R3 R4 --- (20 routers)
	| |
	(10) (30)
	| |
	------- R5 ------
	Figure 5		o Should increase protection on network where FRR is not available
			everywhere. Although it may not provide full coverage, it will
			increase the protection significantly.
	In this topology, we consider LFA enabled on all routers and links.		o May provide better protection in specific cases than RSVP-TE FRR
	We will focus on R5 view of the network.
	R5 is routing all traffic towards R3 as nominal nexthop, except		For IP networks that do not have any traffic protection mechanism,
	traffic towards R4 which is routed using R4 (direct link) as nexthop.		LFA is a very good first step to provide traffic protection even if
	R5 has LFAs only for R2 and destinations behind R2 (primary nexthop		its coverage is not 100%. Providers may want to increase protection
	R3, alternate R4). There are 104 destinations (routers) in the		coverage if LFA benefit is not sufficient for some destinations, in
	network in figure 5. R5-R3 link has 49% LFA coverage with 83		some parts of the network. The following sections discusses the use
	destinations primarily routed on it. R3 node (from R5 point of view)		of basic RSVP-TE tunnels to extend protection coverage.
	has 49% LFA coverage with 83 destinations primarily routed through it
	from R5. R5-R4 link has 0% coverage with 21 destinations primarily
	routed on it. R4 node (from R5 point of view) has 0% coverage with
	21 destinations primarily routed on it through it from R5.
	Globally from R5 point of view, LFA is able to protect to partially		3.2. Extending LFA coverage using RSVP-TE tunnels
	(49%) protect from failure of R3, while failure of R4 is not
	protected at all.
	5.2. Creating multihop tunnel to extend topology		We already have seen in previous sections that RSVP-TE tunnels could
			be established by an operator to complement LFA coverage. The method
			of tunnel placement depends on what type of protection (link or node)
			is required, as well as on the set of destinations or network parts
			which requires better protection than what LFA can provide.
	From R5 point of view, traffic routed through R3 is protected (node		3.2.1. Creating multihop tunnel to extend topology
	protected) at about 49% with 83 destinations routed on it.
	Destinations R1,R3 and routers behind R1 are not protected, while R2
	and destinations behind it are protected.
	To extend the coverage, the idea is to extend the topology using LFA		To extend the coverage, the idea is to use a mechanism extending LFA
	tunnel candidate mechanism. This mechanism is of a local		by turning TE tunnels into LFA candidates. This mechanism is of a
	significance only.		local significance only.
	The hardest task is then to choose the tunnel(s) endpoint such as to		When explicitly establishing tunnels for that purpose, choices have
	achieve the maximum coverage. Tunnel definition must satisfy :		to be made for the endpoints of such tunnels, in order to maximize
			coverage while preserving management simplicity. Requirements are
			that:
	o Endpoint must satisfy equations from [RFC5286], otherwise it will		o Endpoints must satisfy equations from [RFC5286], otherwise it will
	not be a LFA : so when releasing traffic from tunnel, the traffic		not be a valide LFA candidate: so when releasing traffic from
	will go to the destination without flowing through the protected		tunnel, the traffic will go to the destination without flowing
	link or node. Depending on which equations are satisfied, node or		through the protected link or node. Depending on which equations
	link protection will be provided by the tunnel hop.		are satisfied, node or link protection will be provided by the
			tunnel hop.
	o Tunnel must not flow though the link or node to be protected,		o Tunnel must not flow though the link or node to be protected,
	explicit routing of tunnel is highly recommended to enforce this		explicit routing of tunnel is recommended to enforce this
	condition.		condition.
	The approach to choose tunnel endpoints might be different here when		The approach to choose tunnel endpoints might be different here when
	compared to [I-D.ietf-rtgwg-remote-lfa] as endpoint choice is a		compared to [I-D.ietf-rtgwg-remote-lfa] as endpoint choice is a
	manual one. Automatic behavior and scaling of		manual one. Automatic behavior and scaling of
	[I-D.ietf-rtgwg-remote-lfa] requires :		[I-D.ietf-rtgwg-remote-lfa] requires:
	o Non null intersection of Extended P-Space and Q-Space		o Non null intersection of Extended P-Space and Q-Space
	o Computation of PQ node only for the remote end of the link		o Computation of PQ node only for the remote end of the link
	Based on this, [I-D.ietf-rtgwg-remote-lfa] may :		Based on this, [I-D.ietf-rtgwg-remote-lfa] may:
	o Not find a tunnel endpoint;		o Not find a tunnel endpoint;
	o Not provide the more efficient protection : -- i.e. provides only		o Not provide the more efficient protection : -- i.e. provides only
	link protection, while there is node protection possible for a		link protection, while there is node protection possible for a
	specific destination		specific destination
	The proposed solution of manual explicitly routed tunnels is a good		The proposed solution of manual explicitly routed tunnels is a good
	complement for [I-D.ietf-rtgwg-remote-lfa] and provides more		complement for [I-D.ietf-rtgwg-remote-lfa] and provides more
	flexibility:		flexibility:
	o Always a possibility to find a tunnel endpoint for a specific		o Always a possibility to find a tunnel endpoint for a specific
	destination		destination.
	o Possibility to provide better protection level		o Possibility to provide a better protection type (link vs. node).
	From manageability aspect of our manual solution, computing a best Q		3.2.2. Selecting multihop tunnels to extend topology
	node for each destination could lead to have one different Q node for
	different destination. This is not optimal in terms of number of		From a manageability point of view, computing a best Q node for each
	tunnels, given that possibly one Q node may be able to serve multiple		destination could lead to have one different Q node for each
	non covered destinations.		destination. This is not optimal in terms of number of tunnels,
			given that possibly one Q node may be able to serve multiple non
			covered destinations.
	Rather than computing the best Q node per non covered destination, we		Rather than computing the best Q node per non covered destination, we
	would prefer to find best compromise Q nodes (best for multiple		would prefer to find best compromise Q nodes (best for multiple
	destinations). To find the best compromise between coverage increase		destinations). To find the best compromise between coverage increase
	and number of tunnels, we recommend to use a simulator that do the		and number of tunnels, we recommend to use a simulator performing the
	following computation per link :		following computations per link:
	Step 1 : Compute for each not covered destination (routed on the		Step 1 : Compute for each not covered destination (routed on the
	link) the list of endpoints that are satisfying equations		link) the list of endpoints that are satisfying equations
	from [RFC5286] (node or link protection equations depending		from [RFC5286] (node or link protection equations depending
	of required level of protection) : nodes in Q-Space		of required level of protection) : nodes in Q-Space
	Step 2 : Remove endpoint that you want to avoid to use as repair		Step 2 : Remove endpoints that are not eligible for repair (Edge
	(Edge nodes, low bandwidth meshed nodes, number of hops		nodes, low bandwidth meshed nodes, number of hops ...) :
	...) : multiple attributes could be specified to exclude		multiple attributes could be specified to exclude some
	some nodes from Q-Space : The example of attributes include		nodes from Q-Space : The example of attributes include
	router type, metric to node, bandwidth, packet loss, RTD		router type, metric to node, bandwidth, packet loss, RTD
	...		...
	Step 3 : Within all the list of endpoints (one list per		Step 3 : Within the list of endpoints (one list per destination),
	destination), order the endpoints by number of destination		order the endpoints by number of destination covered
	covered
	Step 4 : Choose the endpoint that has the highest number of		Step 4 : Choose the endpoint that has the highest number of
	destination covered : some other criteria could be used to		destination covered : some other criteria could be used to
	prefer an endpoint from another (same type of criteria that		prefer an endpoint from another (same type of criteria that
	excluded some nodes from Q-Space)		excluded some nodes from Q-Space)
	Step 5 : Remove destinations covered by this endpoint from non		Step 5 : Remove destinations covered by this endpoint from non
	covered list		covered list
	Step 6 : If non covered list is not empty, restart from Step 1		Step 6 : If non covered list is not empty, restart from Step 1
	Multiple endpoint (and so tunnels) could be necessary to have 100%		Multiple endpoint (and so tunnels) could be necessary to have 100%
	coverage. But the idea is to find a tradeoff between number of		coverage. But the idea is to find a tradeoff between number of
	tunnels configured (complexity) and number of destination covered,		tunnels configured (complexity) and number of destination covered,
	combining with traffic information would also provide a better view.		combining with traffic information would also provide a better view.
	Globally, configuring 2 tunnels providing 80% coverage would be
	considered as (operationnally) better than configuring 15 tunnels to
	obtain 100% coverage.
	In our example, we can create a tunnel from R5 to R2. R2 satisfies		4. Security Considerations
	node protection equation for destination R1, routers behind R1 and
	R3. To satisfy the second criteria, the tunnel must not use IGP path
	but must be constrained through R4. With this, we achieve 100% of
	LFA coverage for R3 router failure.
	6. Security Considerations
	TBD.		TBD.
	7. Acknowledgements		5. Contributors
	8. IANA Considerations		Significant contribution was made by Pierre Francois which the
			authors would like to acknowledge.
	This document has no actions for IANA.		6. IANA Considerations
	9. References		This document has no actions for IANA.
	9.1. Normative References		7. References
			7.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway		[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
	Protocol (IGP) Routes Over Traffic Engineering Tunnels",		Protocol (IGP) Routes Over Traffic Engineering Tunnels",
	RFC 3906, October 2004.		RFC 3906, October 2004.
	[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute		[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
	Extensions to RSVP-TE for LSP Tunnels", RFC 4090,		Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
	May 2005.		May 2005.
	[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast		[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
	Reroute: Loop-Free Alternates", RFC 5286, September 2008.		Reroute: Loop-Free Alternates", RFC 5286, September 2008.
	9.2. Informative References		7.2. Informative References
	[I-D.bryant-ipfrr-tunnels]		[I-D.bryant-ipfrr-tunnels]
	Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP		Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
	Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03		Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03
	(work in progress), November 2007.		(work in progress), November 2007.
	[I-D.ietf-rtgwg-remote-lfa]		[I-D.ietf-rtgwg-remote-lfa]
	Bryant, S., Filsfils, C., Shand, M., and S. Ning, "Remote		Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
	LFA FRR", draft-ietf-rtgwg-remote-lfa-00 (work in		Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01
	progress), June 2012.		(work in progress), December 2012.
	Authors' Addresses		Authors' Addresses
	Stephane Litkowski		Stephane Litkowski
	Orange		Orange
	Email: stephane.litkowski@orange.com		Email: stephane.litkowski@orange.com
	Bruno Decraene		Bruno Decraene
	Orange		Orange
	Email: bruno.decraene@orange.com		Email: bruno.decraene@orange.com
	Clarence Fils Fils
			Clarence FilsFils
	Cisco Systems		Cisco Systems
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	Kamran Raza		Kamran Raza
	Cisco Systems		Cisco Systems
	Email: skraza@cisco.com		Email: skraza@cisco.com
End of changes. 94 change blocks.
	277 lines changed or deleted		278 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/