draft-ietf-rtgwg-ipfrr-spec-base-06.txt   draft-ietf-rtgwg-ipfrr-spec-base-07.txt 
Network Working Group A. Atlas, Ed. Network Working Group A. Atlas, Ed.
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Expires: September 2, 2007 A. Zinin, Ed. Expires: January 7, 2008 A. Zinin, Ed.
Alcatel Alcatel
March 1, 2007 July 6, 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-06 draft-ietf-rtgwg-ipfrr-spec-base-07
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 September 2, 2007. This Internet-Draft will expire on January 7, 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 11 skipping to change at page 2, line 11
micro-looping and packet loss that happens while routers converge micro-looping and packet loss that happens while routers converge
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 . . . . . . . . . . . . 7 2. Applicability of Described Mechanisms . . . . . . . . . . . . 8
3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 8 3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 8
3.1. Basic Loop-free Condition . . . . . . . . . . . . . . . . 9 3.1. Basic Loop-free Condition . . . . . . . . . . . . . . . . 10
3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 9 3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 10
3.3. Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 10 3.3. Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 10
3.4. ECMP and Alternates . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1. Interactions with ISIS Link Attributes . . . . . . . . 13 3.5.1. Interactions with ISIS Link Attributes . . . . . . . . 14
3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 13 3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 14
4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 17 4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 18 4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 18
5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 19 5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 20
6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 20 6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 20 6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 20
6.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 22 6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 22
6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 22 6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 23
6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 22 6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 23
6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 22 6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. OSPF Example Where LFA Based on Local Area Appendix A. OSPF Example Where LFA Based on Local Area
Topology is Insufficient . . . . . . . . . . . . . . 25 Topology is Insufficient . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
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 seconds; the application traffic time is generally on the order of hundreds of milliseconds; the
may be sensitive to losses greater than 10s of milliseconds. application traffic may be sensitive to losses greater than tens of
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
subsequent re-convergence. This specification describes such a subsequent re-convergence. This specification describes such a
mechanism which allows a router whose local link has failed to mechanism which allows a router whose local link has failed to
forward traffic to a pre-computed alternate until the router installs forward traffic to a pre-computed alternate until the router installs
the new primary next-hops based upon the changed network topology. the new primary next-hops based upon the changed network topology.
The terminology used in this specification is given in The terminology used in this specification is given in
[I-D.ietf-rtgwg-ipfrr-framework]. The described mechanism assumes [I-D.ietf-rtgwg-ipfrr-framework]. The described mechanism assumes
that routing in the network is performed using a link-state routing that routing in the network is performed using a link-state routing
protocol-- OSPF [RFC2328] [RFC2740] [I-D.ietf-ospf-ospfv3-update] or protocol-- OSPF [RFC2328] [RFC2740] [I-D.ietf-ospf-ospfv3-update] or
ISIS [RFC1195] [RFC2966] (for IPv4 or IPv6). ISIS [RFC1195] [RFC2966] (for IPv4 or IPv6). The mechanism also
assumes that both the primary path and the alternate path are in the
same routing area.
When a local link fails, a router currently must signal the event to When a local link fails, a router currently must signal the event to
its neighbors via the IGP, recompute new primary next-hops for all its neighbors via the IGP, recompute new primary next-hops for all
affected prefixes, and only then install those new primary next-hops affected prefixes, and only then install those new primary next-hops
into the forwarding plane. Until the new primary next-hops are into the forwarding plane. Until the new primary next-hops are
installed, traffic directed towards the affected prefixes is installed, traffic directed towards the affected prefixes is
discarded. This process can take seconds. discarded. This process can take hundreds of milliseconds.
<-- <--
+-----+ +-----+
/------| S |--\ /------| S |--\
/ +-----+ \ / +-----+ \
/ 5 8 \ / 5 8 \
/ \ / \
+-----+ +-----+ +-----+ +-----+
| E | | N_1 | | E | | N_1 |
+-----+ +-----+ +-----+ +-----+
skipping to change at page 6, line 40 skipping to change at page 6, line 40
would be able to use N as an alternate, but N could not use S; would be able to use N as an alternate, but N could not use S;
therefore N would have no alternate and would discard the traffic, therefore N would have no alternate and would discard the traffic,
thus avoiding the micro-loop. A micro-loop due to the use of thus avoiding the micro-loop. A micro-loop due to the use of
alternates can be avoided by using downstream paths because each alternates can be avoided by using downstream paths because each
succeeding router in the path to the destination must be closer to succeeding router in the path to the destination must be closer to
the destination than its predecessor (according to the topology prior the destination than its predecessor (according to the topology prior
to the failures). Although use of downstream paths ensures that the to the failures). Although use of downstream paths ensures that the
micro-looping via alternates does not occur, such a restriction can micro-looping via alternates does not occur, such a restriction can
severely limit the coverage of alternates. severely limit the coverage of alternates.
As shown above, the use of either a node protecting LFA or a
downstream path provides protection against micro-looping in the
event of node failure. There are topologies where there may be
either a node portecting LFA, a downstream path, both or neither. A
node may select either a node protecting LFA or a downstream path
without risk of causing micro-loops in the event of node failure.
While a link-and-node-protecting LFA guarantees protection against
either link or node failure, a downstream path provides protection
only against a link failure and may or may not provide protection
against a node failure depending on the protection available at the
downstream node, but it cannot cause a micro-loop. For example in
Figure 2, if S uses N as a downstream path, although no looping can
occur, the traffic will not be protected in the event of the failure
of node E because N has no viable repair path, and it will simply
discard the packet. However, if N had a link and node protecting LFA
or downstream path via some other path (not shown), then the repair
may succeed.
Since the functionality of link and node protecting LFAs is greater
than that of downstream paths, a router SHOULD select a link and node
protecting LFA over a downstream path. If there are any destinations
for which a link and node protecting LFA is not available, then by
definition the path to all of those destinations from any neighbor of
the computing router (S) must be through the node (E) being protected
(otherwise there would be a node protecting LFA for that
destination). Consequently, if there exists a downstream path to the
protected node as destination, then that downstream path may be used
for all those destinations for which a link and node protecting LFA
is not available; the existence of a downstream path can be
determined by a single check of the condition Distance_opt(N, E) <
Distance_opt(S, E).
It may be desirable to find an alternate that can protect against It may be desirable to find an alternate that can protect against
other correlated failures (of which node failure is a specific other correlated failures (of which node failure is a specific
instance). In the general case, these are handled by shared risk instance). In the general case, these are handled by shared risk
link groups (SRLGs) where any links in the network can belong to the link groups (SRLGs) where any links in the network can belong to the
SRLG. General SRLGs may add unacceptably to the computational SRLG. General SRLGs may add unacceptably to the computational
complexity of finding a loop-free alternate. complexity of finding a loop-free alternate.
However, a sub-category of SRLGs is of interest and can be applied However, a sub-category of SRLGs is of interest and can be applied
only during the selection of an acceptable alternate. This sub- only during the selection of an acceptable alternate. This sub-
category is to express correlated failures of links that are category is to express correlated failures of links that are
skipping to change at page 13, line 26 skipping to change at page 14, line 8
there is no other path. there is no other path.
If a link or router which is costed out was the only possible If a link or router which is costed out was the only possible
alternate to protect traffic from a particular router S to a alternate to protect traffic from a particular router S to a
particular destination, then there should be no alternate provided particular destination, then there should be no alternate provided
for protection. for protection.
3.5.1. Interactions with ISIS Link Attributes 3.5.1. Interactions with ISIS Link Attributes
[I-D.ietf-isis-link-attr] describes several flags whose interactions [I-D.ietf-isis-link-attr] describes several flags whose interactions
with LFAs needs to be defined. A router SHOULD NOT specify the with LFAs needs to be defined. A router MAY specify the "local
"local protection available" flag as a result of having LFAs. A protection available" flag as a result of having LFAs. A router
router SHOULD NOT use an alternate next-hop that is along a link for SHOULD NOT use an alternate next-hop that is along a link for which
which the link has been advertised with the attribute "link excluded the link has been advertised with the attribute "link excluded from
from local protection path" or with the attribute "local maintenance local protection path" or with the attribute "local maintenance
required". required".
3.6. Selection Procedure 3.6. Selection Procedure
A router supporting this specification SHOULD attempt to select at A router supporting this specification SHOULD attempt to select at
least one loop-free alternate next-hop for each primary next-hop used least one loop-free alternate next-hop for each primary next-hop used
for a given prefix. A router MAY decide to not use an available for a given prefix. A router MAY decide to not use an available
loop-free alternate next-hop. A reason for such a decision might be loop-free alternate next-hop. A reason for such a decision might be
that the loop-free alternate next-hop does not provide protection for that the loop-free alternate next-hop does not provide protection for
the failure scenario of interest. the failure scenario of interest.
skipping to change at page 14, line 24 skipping to change at page 15, line 5
free node-protecting alternate is available and no other primary free node-protecting alternate is available and no other primary
next-hop can provide link-protection, then S SHOULD select a next-hop can provide link-protection, then S SHOULD select a
loop-free link-protecting alternate. loop-free link-protecting alternate.
4. Implementations SHOULD support a mode where other primary next- 4. Implementations SHOULD support a mode where other primary next-
hops satisfying the basic loop-free condition and providing at hops satisfying the basic loop-free condition and providing at
least link or node protection are preferred over any non-primary least link or node protection are preferred over any non-primary
alternates. This mode is provided to allow the administrator to alternates. This mode is provided to allow the administrator to
preserve traffic patterns based on regular ECMP behavior. preserve traffic patterns based on regular ECMP behavior.
5. Implementations considering SRLGs MAY use SRLG-protection to
determine that a node-protecting or link-protecting alternate is
not available for use.
Following the above rules maximizes the level of protection and use Following the above rules maximizes the level of protection and use
of primary (ECMP) next-hops. of primary (ECMP) next-hops.
Each next-hop is associated with a set of non-mutually-exclusive Each next-hop is associated with a set of non-mutually-exclusive
characteristics based on whether it is used as a primary next-hop to characteristics based on whether it is used as a primary next-hop to
a particular destination D, and the type of protection it can provide a particular destination D, and the type of protection it can provide
relative to a specific primary next-hop E: relative to a specific primary next-hop E:
Primary Path - The next-hop is used by S as primary. Primary Path - The next-hop is used by S as primary.
skipping to change at page 23, line 20 skipping to change at page 24, line 9
In LDP, the wider distribution of FEC label information is still to In LDP, the wider distribution of FEC label information is still to
neighbors with whom a trusted LDP session has been established. This neighbors with whom a trusted LDP session has been established. This
wider distribution and the recommendation of using liberal label wider distribution and the recommendation of using liberal label
retention mode are believed to have no significant security impact. retention mode are believed to have no significant security impact.
8. IANA Considerations 8. IANA Considerations
This document requires no IANA considerations. This document requires no IANA considerations.
9. References 9. Acknowledgements
9.1. Normative References The authors would like to thank Joel Halpern, Mike Shand, Stewart
Bryant, and Stefano Previdi for their assistance and useful review.
10. References
10.1. Normative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[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 [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966, Distribution with Two-Level IS-IS", RFC 2966,
October 2000. 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.
9.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] [I-D.ietf-ospf-mt]
Psenak, P., "Multi-Topology (MT) Routing in OSPF", Psenak, P., "Multi-Topology (MT) Routing in OSPF",
draft-ietf-ospf-mt-08 (work in progress), January 2007. 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-01 (work in OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in
progress), March 2006. 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-14 (work in progress), draft-ietf-ospf-ospfv3-update-16 (work in progress),
December 2006. May 2007.
[I-D.ietf-rtgwg-ipfrr-framework] [I-D.ietf-rtgwg-ipfrr-framework]
Shand, M. and S. Bryant, "IP Fast Reroute Framework", Shand, M. and S. Bryant, "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-framework-06 (work in progress), draft-ietf-rtgwg-ipfrr-framework-07 (work in progress),
October 2006. 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.
[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.
skipping to change at page 26, line 9 skipping to change at page 27, line 9
the path from area 2 and directs traffic to F. The path from F in the path from area 2 and directs traffic to F. The path from F in
area 2 goes to B. B is also an ABR and learns the ASBR from both area 2 goes to B. B is also an ABR and learns the ASBR from both
areas 1 and area 2; B's path via area 1 is shorter (cost 20) than B's areas 1 and area 2; B's path via area 1 is shorter (cost 20) than B's
path via area 2 (cost 25). Therefore, B uses the path from area 1 path via area 2 (cost 25). Therefore, B uses the path from area 1
that connects to S. that connects to S.
Authors' Addresses Authors' Addresses
Alia K. Atlas (editor) Alia K. Atlas (editor)
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway One Broadway, 7th Floor
Mountain View, CA 94043 Cambridge, MA 02142
USA USA
Email: akatlas@google.com Email: akatlas@google.com
Alex Zinin (editor) Alex Zinin (editor)
Alcatel Alcatel
701 E Middlefield Rd. 701 E Middlefield Rd.
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
 End of changes. 26 change blocks. 
44 lines changed or deleted 89 lines changed or added

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