draft-ietf-rtgwg-ipfrr-spec-base-07.txt   draft-ietf-rtgwg-ipfrr-spec-base-08.txt 
Network Working Group A. Atlas, Ed. Network Working Group A. Atlas, Ed.
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Expires: January 7, 2008 A. Zinin, Ed. Expires: March 9, 2008 A. Zinin, Ed.
Alcatel Alcatel
July 6, 2007 Sept 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-07 draft-ietf-rtgwg-ipfrr-spec-base-08
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 January 7, 2008. This Internet-Draft will expire on March 9, 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 21 skipping to change at page 2, line 21
2. Applicability of Described Mechanisms . . . . . . . . . . . . 8 2. Applicability of Described Mechanisms . . . . . . . . . . . . 8
3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 8 3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 10
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
4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 18 4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 18 4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 19
5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 20 5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 21
6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 20 6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 20 6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 21
6.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . 23 6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 24
6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 23 6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . 25 Topology is Insufficient . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30
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 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.
skipping to change at page 14, line 8 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 MAY specify the "local with LFAs needs to be defined. A router SHOULD NOT specify the
protection available" flag as a result of having LFAs. A router "local protection available" flag as a result of having LFAs. A
SHOULD NOT use an alternate next-hop that is along a link for which router SHOULD NOT use an alternate next-hop that is along a link for
the link has been advertised with the attribute "link excluded from which the link has been advertised with the attribute "link excluded
local protection path" or with the attribute "local maintenance from 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 18, line 13 skipping to change at page 18, line 13
19. Replace the P_i alternate next-hop set with H_h as follows: 19. Replace the P_i alternate next-hop set with H_h as follows:
P_i.alt_next_hops = {H_h} P_i.alt_next_hops = {H_h}
P_i.alt_type = cand_type P_i.alt_type = cand_type
P_i.alt_link-protect = cand_link-protect P_i.alt_link-protect = cand_link-protect
P_i.alt_node-protect = cand_node-protect P_i.alt_node-protect = cand_node-protect
P_i.alt_srlg-protect = cand_srlg-protect P_i.alt_srlg-protect = cand_srlg-protect
Continue to the next candidate next-hop. Continue to the next candidate next-hop.
3.7. A Simplification: Per-Next-Hop LFAs
It is possible to simplify the computation and use of LFAs when
solely link protection is desired by considering and computing only
one link-protecting LFA for each next-hop connected to the router.
All prefixes that use that next-hop as a primary will use the LFA
computed for that next-hop as its LFA.
Even a prefix with multiple primary next-hops will have each primary
next-hop protected individually by the primary next-hop's associated
LFA. That associated LFA might or might not be another of the
primary next-hops of the prefix.
This simplification may reduce coverage in a network. In addition to
limiting protection for multi-homed prefixes (see Section 6.1), the
computation per next-hop may also not find an LFA when one could be
found for some of the prefixes that use that next-hop.
For example, consider Figure 4 where S has 3 ECMP next-hops, E1, E2,
and E3 to reach D. For the prefix D, E3 can give link protection for
the next-hops E1 and E2; E1 and E2 can give link protection for the
next-hops E3. However, if one uses this simplification to compute
LFAs for E1, E2 and E3 individually, there is no link-protecting LFA
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 [FRAMEWORK]), the router
SHOULD: SHOULD:
skipping to change at page 25, line 14 skipping to change at page 26, line 9
Psenak, P., "Multi-Topology (MT) Routing in OSPF", Psenak, P., "Multi-Topology (MT) Routing in OSPF",
draft-ietf-ospf-mt-09 (work in progress), June 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-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-16 (work in progress), draft-ietf-ospf-ospfv3-update-17 (work in progress),
May 2007. August 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-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),
 End of changes. 13 change blocks. 
27 lines changed or deleted 53 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/