< draft-ietf-rtgwg-ipfrr-spec-base-08.txt		draft-ietf-rtgwg-ipfrr-spec-base-09.txt >
	Network Working Group A. Atlas, Ed.		Routing Area Working Group A. Atlas, Ed.
	Internet-Draft Google, Inc.		Internet-Draft Google, Inc.
	Expires: March 9, 2008 A. Zinin, Ed.		Intended status: Standards Track A. Zinin, Ed.
	Alcatel		Expires: March 21, 2008 Alcatel
	Sept 6, 2007		Sept 18, 2007
	Basic Specification for IP Fast-Reroute: Loop-free Alternates		Basic Specification for IP Fast-Reroute: Loop-free Alternates
	draft-ietf-rtgwg-ipfrr-spec-base-08		draft-ietf-rtgwg-ipfrr-spec-base-09
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 9, 2008.		This Internet-Draft will expire on March 21, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes the use of loop-free alternates to provide		This document describes the use of loop-free alternates to provide
	local protection for unicast traffic in pure IP and MPLS/LDP networks		local protection for unicast traffic in pure IP and MPLS/LDP networks
	in the event of a single failure, whether link, node or shared risk		in the event of a single failure, whether link, node or shared risk
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	after a topology change due to a failure. Rapid failure repair is		after a topology change due to a failure. Rapid failure repair is
	achieved through use of precalculated backup next-hops that are loop-		achieved through use of precalculated backup next-hops that are loop-
	free and safe to use until the distributed network convergence		free and safe to use until the distributed network convergence
	process completes.		process completes.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5		1.1. Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5
	2. Applicability of Described Mechanisms . . . . . . . . . . . . 8		2. Applicability of Described Mechanisms . . . . . . . . . . . . 8
	3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 8		3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 9
	3.1. Basic Loop-free Condition . . . . . . . . . . . . . . . . 10		3.1. Basic Loop-free Condition . . . . . . . . . . . . . . . . 10
	3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 10		3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 10
	3.3. Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 10		3.3. Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 11
	3.4. ECMP and Alternates . . . . . . . . . . . . . . . . . . . 12		3.4. ECMP and Alternates . . . . . . . . . . . . . . . . . . . 12
	3.5. Interactions with ISIS Overload, RFC 3137 and Costed		3.5. Interactions with ISIS Overload, RFC 3137 and Costed
	Out Links . . . . . . . . . . . . . . . . . . . . . . . . 13		Out Links . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.5.1. Interactions with ISIS Link Attributes . . . . . . . . 14		3.5.1. Interactions with ISIS Link Attributes . . . . . . . . 14
	3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 14		3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 14
	3.7. A Simplification: Per-Next-Hop LFAs . . . . . . . . . . . 18		3.7. A Simplification: Per-Next-Hop LFAs . . . . . . . . . . . 18
	4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 18		4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 19
	4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 19		4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 19
	5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 21		5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 21
	6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 21		6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 21
	6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 21		6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 21
	6.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		6.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 23		6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 23
	6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 23		6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 23
	6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 24		6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 24
	6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 24		6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 24
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 25		10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
	10.2. Informative References . . . . . . . . . . . . . . . . . . 25		10.2. Informative References . . . . . . . . . . . . . . . . . . 25
	Appendix A. OSPF Example Where LFA Based on Local Area		Appendix A. OSPF Example Where LFA Based on Local Area
	Topology is Insufficient . . . . . . . . . . . . . . 26		Topology is Insufficient . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . . . 30		Intellectual Property and Copyright Statements . . . . . . . . . . 30
	1. Introduction		1. Introduction
			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 RFC 2119. [RFC2119]
	Applications for interactive multimedia services such as VoIP and		Applications for interactive multimedia services such as VoIP and
	pseudo-wires can be very sensitive to traffic loss, such as occurs		pseudo-wires can be very sensitive to traffic loss, such as occurs
	when a link or router in the network fails. A router's convergence		when a link or router in the network fails. A router's convergence
	time is generally on the order of hundreds of milliseconds; the		time is generally on the order of hundreds of milliseconds; the
	application traffic may be sensitive to losses greater than tens of		application traffic may be sensitive to losses greater than tens of
	milliseconds.		milliseconds.
	As discussed in [I-D.ietf-rtgwg-ipfrr-framework], minimizing traffic		As discussed in [I-D.ietf-rtgwg-ipfrr-framework], minimizing traffic
	loss requires a mechanism for the router adjacent to a failure to		loss requires a mechanism for the router adjacent to a failure to
	rapidly invoke a repair path, which is minimally affected by any		rapidly invoke a repair path, which is minimally affected by any
	skipping to change at page 12, line 32 ¶		skipping to change at page 13, line 6 ¶
	With equal-cost multi-path, a prefix may have multiple primary next-		With equal-cost multi-path, a prefix may have multiple primary next-
	hops that are used to forward traffic. When a particular primary		hops that are used to forward traffic. When a particular primary
	next-hop fails, alternate next-hops should be used to preserve the		next-hop fails, alternate next-hops should be used to preserve the
	traffic. These alternate next-hops may themselves also be primary		traffic. These alternate next-hops may themselves also be primary
	next-hops, but need not be. Other primary next-hops are not		next-hops, but need not be. Other primary next-hops are not
	guaranteed to provide protection against the failure scenarios of		guaranteed to provide protection against the failure scenarios of
	concern.		concern.
	20 L1 L3 3		20 L1 L3 3
	[N]-----[ S ]--------[E3]		[ N ]----[ S ]--------[ E3 ]
	| | |		| | |
	| 5 | L2 |		| 5 | L2 |
	20 | | |		20 | | |
	| --------- | 2		| --------- | 2
	| 5 | | 5 |		| 5 | | 5 |
	| [E1] [E2]------|		| [ E1 ] [ E2 ]-----|
	| | |		| | |
	| 10 | 10 |		| 10 | 10 |
	|---[A] [B]		|---[ A ] [ B ]
	| |		| |
	2 |--[D]--| 2		2 |--[ D ]-| 2
	Figure 4: ECMP where Primary Next-Hops Provide Limited Protection		Figure 4: ECMP where Primary Next-Hops Provide Limited Protection
	In Figure 4 S has three primary next-hops to reach D; these are L2 to		In Figure 4 S has three primary next-hops to reach D; these are L2 to
	E1, L2 to E2 and L3 to E3. The primary next-hop L2 to E1 can obtain		E1, L2 to E2 and L3 to E3. The primary next-hop L2 to E1 can obtain
	link and node protection from L3 to E3, which is one of the other		link and node protection from L3 to E3, which is one of the other
	primary next-hops; L2 to E1 cannot obtain link protection from the		primary next-hops; L2 to E1 cannot obtain link protection from the
	other primary next-hop L2 to E2. Similarly, the primary next-hop L2		other primary next-hop L2 to E2. Similarly, the primary next-hop L2
	to E2 can only get node protection from L2 to E1 and can only get		to E2 can only get node protection from L2 to E1 and can only get
	link protection from L3 to E3. The third primary next-hop L3 to E3		link protection from L3 to E3. The third primary next-hop L3 to E3
	skipping to change at page 18, line 45 ¶		skipping to change at page 19, line 14 ¶
	LFAs for E1, E2 and E3 individually, there is no link-protecting LFA		LFAs for E1, E2 and E3 individually, there is no link-protecting LFA
	for E1. E3 and E2 can protect each other.		for E1. E3 and E2 can protect each other.
	4. Using an Alternate		4. Using an Alternate
	If an alternate next-hop is available, the router redirects traffic		If an alternate next-hop is available, the router redirects traffic
	to the alternate next-hop in case of a primary next-hop failure as		to the alternate next-hop in case of a primary next-hop failure as
	follows.		follows.
	When a next-hop failure is detected via a local interface failure or		When a next-hop failure is detected via a local interface failure or
	other failure detection mechanisms (see [FRAMEWORK]), the router		other failure detection mechanisms (see
	SHOULD:		[I-D.ietf-rtgwg-ipfrr-framework]), the router SHOULD:
	1. Remove the primary next-hop associated with the failure.		1. Remove the primary next-hop associated with the failure.
	2. Install the loop-free alternate calculated for the failed next-		2. Install the loop-free alternate calculated for the failed next-
	hop if it is not already installed (e.g. the alternate is also a		hop if it is not already installed (e.g. the alternate is also a
	primary next-hop).		primary next-hop).
	Note that the router MAY remove other next-hops if it believes (via		Note that the router MAY remove other next-hops if it believes (via
	SRLG analysis) that they may have been affected by the same failure,		SRLG analysis) that they may have been affected by the same failure,
	even if it is not visible at the time of failure detection.		even if it is not visible at the time of failure detection.
	skipping to change at page 23, line 46 ¶		skipping to change at page 23, line 49 ¶
	routers in the network calculate their next-hops for the external		routers in the network calculate their next-hops for the external
	prefix by doing a lookup for the forwarding address in the routing		prefix by doing a lookup for the forwarding address in the routing
	table, rather than using the next-hops calculated for the ASBR. In		table, rather than using the next-hops calculated for the ASBR. In
	this case, the alternate next-hops SHOULD be computed by selecting		this case, the alternate next-hops SHOULD be computed by selecting
	among the alternate paths to the forwarding link(s) instead of among		among the alternate paths to the forwarding link(s) instead of among
	alternate paths to the ASBR.		alternate paths to the ASBR.
	6.3.2. OSPF Multi-Topology		6.3.2. OSPF Multi-Topology
	The applicabilty and interactions of LFAs with multi-topology OSPF		The applicabilty and interactions of LFAs with multi-topology OSPF
	[I-D.ietf-ospf-mt] [I-D.ietf-ospf-mt-ospfv3] is out of scope for this		[RFC4915] [I-D.ietf-ospf-mt-ospfv3] is out of scope for this
	specification.		specification.
	6.4. BGP Next-Hop Synchronization		6.4. BGP Next-Hop Synchronization
	Typically BGP prefixes are advertised with AS exit routers router-id		Typically BGP prefixes are advertised with AS exit routers router-id
	as the BGP next-hop, and AS exit routers are reached by means of IGP		as the BGP next-hop, and AS exit routers are reached by means of IGP
	routes. BGP resolves its advertised next-hop to the immediate next-		routes. BGP resolves its advertised next-hop to the immediate next-
	hop by potential recursive lookups in the routing database. IP Fast-		hop by potential recursive lookups in the routing database. IP Fast-
	Reroute computes the alternate next-hops to all IGP destinations,		Reroute computes the alternate next-hops to all IGP destinations,
	which include alternate next-hops to the AS exit router's router-id.		which include alternate next-hops to the AS exit router's router-id.
	skipping to change at page 25, line 14 ¶		skipping to change at page 25, line 14 ¶
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Joel Halpern, Mike Shand, Stewart		The authors would like to thank Joel Halpern, Mike Shand, Stewart
	Bryant, and Stefano Previdi for their assistance and useful review.		Bryant, and Stefano Previdi for their assistance and useful review.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	dual environments", RFC 1195, December 1990.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",		[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
	RFC 2740, December 1999.		RFC 2740, December 1999.
	[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
	Distribution with Two-Level IS-IS", RFC 2966,
	October 2000.
	[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and		[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
	B. Thomas, "LDP Specification", RFC 3036, January 2001.		B. Thomas, "LDP Specification", RFC 3036, January 2001.
	10.2. Informative References		10.2. Informative References
	[I-D.francois-ordered-fib]		[I-D.francois-ordered-fib]
	Francois, P., "Loop-free convergence using oFIB",		Francois, P., "Loop-free convergence using oFIB",
	draft-francois-ordered-fib-02 (work in progress),		draft-francois-ordered-fib-02 (work in progress),
	October 2006.		October 2006.
	[I-D.ietf-isis-link-attr]		[I-D.ietf-isis-link-attr]
	Vasseur, J. and S. Previdi, "Definition of an IS-IS Link		Vasseur, J. and S. Previdi, "Definition of an IS-IS Link
	Attribute sub-TLV", draft-ietf-isis-link-attr-03 (work in		Attribute sub-TLV", draft-ietf-isis-link-attr-03 (work in
	progress), February 2007.		progress), February 2007.
	[I-D.ietf-isis-wg-multi-topology]		[I-D.ietf-isis-wg-multi-topology]
	Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in		Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in
	IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in		IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in
	progress), October 2005.		progress), October 2005.
	[I-D.ietf-ospf-mt]
	Psenak, P., "Multi-Topology (MT) Routing in OSPF",
	draft-ietf-ospf-mt-09 (work in progress), June 2007.
	[I-D.ietf-ospf-mt-ospfv3]		[I-D.ietf-ospf-mt-ospfv3]
	Mirtorabi, S. and A. Roy, "Multi-topology routing in		Mirtorabi, S. and A. Roy, "Multi-topology routing in
	OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in		OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in
	progress), July 2007.		progress), July 2007.
	[I-D.ietf-ospf-ospfv3-update]		[I-D.ietf-ospf-ospfv3-update]
	Ferguson, D., "OSPF for IPv6",		Ferguson, D., "OSPF for IPv6",
	draft-ietf-ospf-ospfv3-update-17 (work in progress),		draft-ietf-ospf-ospfv3-update-17 (work in progress),
	August 2007.		August 2007.
	skipping to change at page 26, line 23 ¶		skipping to change at page 26, line 16 ¶
	Shand, M. and S. Bryant, "IP Fast Reroute Framework",		Shand, M. and S. Bryant, "IP Fast Reroute Framework",
	draft-ietf-rtgwg-ipfrr-framework-07 (work in progress),		draft-ietf-rtgwg-ipfrr-framework-07 (work in progress),
	July 2007.		July 2007.
	[I-D.ietf-rtgwg-microloop-analysis]		[I-D.ietf-rtgwg-microloop-analysis]
	Zinin, A., "Analysis and Minimization of Microloops in		Zinin, A., "Analysis and Minimization of Microloops in
	Link-state Routing Protocols",		Link-state Routing Protocols",
	draft-ietf-rtgwg-microloop-analysis-01 (work in progress),		draft-ietf-rtgwg-microloop-analysis-01 (work in progress),
	October 2005.		October 2005.
			[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
			dual environments", RFC 1195, December 1990.
			[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
			Distribution with Two-Level IS-IS", RFC 2966,
			October 2000.
	[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.		[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
	McPherson, "OSPF Stub Router Advertisement", RFC 3137,		McPherson, "OSPF Stub Router Advertisement", RFC 3137,
	June 2001.		June 2001.
	[RFC3509] Zinin, A., Lindem, A., and D. Yeung, "Alternative		[RFC3509] Zinin, A., Lindem, A., and D. Yeung, "Alternative
	Implementations of OSPF Area Border Routers", RFC 3509,		Implementations of OSPF Area Border Routers", RFC 3509,
	April 2003.		April 2003.
	[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support		[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
	of Generalized Multi-Protocol Label Switching (GMPLS)",		of Generalized Multi-Protocol Label Switching (GMPLS)",
	RFC 4203, October 2005.		RFC 4203, October 2005.
	[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to		[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
	Intermediate System (IS-IS) Extensions in Support of		Intermediate System (IS-IS) Extensions in Support of
	Generalized Multi-Protocol Label Switching (GMPLS)",		Generalized Multi-Protocol Label Switching (GMPLS)",
	RFC 4205, October 2005.		RFC 4205, October 2005.
			[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
			Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
			RFC 4915, June 2007.
	Appendix A. OSPF Example Where LFA Based on Local Area Topology is		Appendix A. OSPF Example Where LFA Based on Local Area Topology is
	Insufficient		Insufficient
	This appendix provides an example scenario where the local area		This appendix provides an example scenario where the local area
	topology does not suffice to determine that an LFA is available. As		topology does not suffice to determine that an LFA is available. As
	described in Section 6.3, one problem scenario is for ASBR summaries		described in Section 6.3, one problem scenario is for ASBR summaries
	where the ASBR is available in two areas via intra-area routes and		where the ASBR is available in two areas via intra-area routes and
	there is at least one ABR or alternate ABR that is in both areas.		there is at least one ABR or alternate ABR that is in both areas.
	The following Figure 7 illustrates this case.		The following Figure 7 illustrates this case.
	5		5
	[ F ]-----------[ C ]		[ F ]-----------[ C ]
	| |		| |
	| | 5		| | 5
	20 | 5 | 1		20 | 5 | 1
	| [ N ]-----[ A ]*****[ F ]		| [ N ]-----[ A ]*****[ F ]
	| | # *		| | # *
	| 40 | # 50 * 2		| 40 | # 50 * 2
End of changes. 18 change blocks.
	29 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/