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. 19 change blocks. 
25 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/