draft-ietf-rtgwg-ipfrr-spec-base-05.txt   draft-ietf-rtgwg-ipfrr-spec-base-06.txt 
Network Working Group A. Atlas, Ed. Network Working Group A. Atlas, Ed.
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Expires: August 5, 2006 A. Zinin, Ed. Expires: September 2, 2007 A. Zinin, Ed.
Alcatel Alcatel
February 2006 March 1, 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-05 draft-ietf-rtgwg-ipfrr-spec-base-06
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 August 5, 2006. This Internet-Draft will expire on September 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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
link group (SRLG). The goal of this technology is to reduce the link group (SRLG). The goal of this technology is to reduce the
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 . . . . . . . . . . . . 6 2. Applicability of Described Mechanisms . . . . . . . . . . . . 7
3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 7 3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 8
3.1 Basic Loop-free Condition . . . . . . . . . . . . . . . . 8 3.1. Basic Loop-free Condition . . . . . . . . . . . . . . . . 9
3.2 Node-Protecting Alternate Next-Hops . . . . . . . . . . . 9 3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 9
3.3 Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 9 3.3. Broadcast and NBMA Links . . . . . . . . . . . . . . . . . 10
3.4 ECMP and Alternates . . . . . . . . . . . . . . . . . . . 11 3.4. ECMP and Alternates . . . . . . . . . . . . . . . . . . . 11
3.5 Interactions with ISIS Overload, RFC 3137 and Costed 3.5. Interactions with ISIS Overload, RFC 3137 and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 11 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.1 Interactions with ISIS Link Attributes . . . . . . . . 12 3.5.1. Interactions with ISIS Link Attributes . . . . . . . . 13
3.6 Selection Procedure . . . . . . . . . . . . . . . . . . . 12 3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 13
4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 16 4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Terminating Use of Alternate . . . . . . . . . . . . . . . 17 4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 18
5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 18 5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 19
6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 19 6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 19 6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 20
6.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1 OSPF External Routing . . . . . . . . . . . . . . . . 20 6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3 BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 21 6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 22
6.4 Multicast Considerations . . . . . . . . . . . . . . . . . 21 6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1 Normative References . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.2 Informative References . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
A. OSPF Example Where LFA Based on Local Area Topology is 9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Insufficient . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. OSPF Example Where LFA Based on Local Area
Intellectual Property and Copyright Statements . . . . . . . . 26 Topology is Insufficient . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28
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 seconds; the application traffic
may be sensitive to losses greater than 10s of milliseconds. may be sensitive to losses greater than 10s 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 [I-D.ietf- The terminology used in this specification is given in
rtgwg-ipfrr-framework]. The described mechanism assumes that routing [I-D.ietf-rtgwg-ipfrr-framework]. The described mechanism assumes
in the network is performed using a link-state routing protocol-- that routing in the network is performed using a link-state routing
OSPF[RFC2328] or ISIS [RFC1195] [RFC2966]. protocol-- OSPF [RFC2328] [RFC2740] [I-D.ietf-ospf-ospfv3-update] or
ISIS [RFC1195] [RFC2966] (for IPv4 or IPv6).
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 seconds.
<-- <--
+-----+ +-----+
skipping to change at page 4, line 35 skipping to change at page 4, line 36
link to N_1, until a new SPF is run and its results are installed. link to N_1, until a new SPF is run and its results are installed.
As with the primary next-hop, an alternate next-hop is computed for As with the primary next-hop, an alternate next-hop is computed for
each destination. The process of computing an alternate next-hop each destination. The process of computing an alternate next-hop
does not alter the primary next-hop computed via a standard SPF. does not alter the primary next-hop computed via a standard SPF.
If in the example of Figure 1, the link cost from N_1 to D increased If in the example of Figure 1, the link cost from N_1 to D increased
to 30 from 3, then N_1 would not be a loop-free alternate, because to 30 from 3, then N_1 would not be a loop-free alternate, because
the cost of the path from N_1 to D via S would be 17 while the cost the cost of the path from N_1 to D via S would be 17 while the cost
from N_1 directly to D would be 30. In real networks, we may often from N_1 directly to D would be 30. In real networks, we may often
face this situation. The existence of a suitable loop-free alternate face this situation. The existence of a suitable loop-free alternate
next-hop is topology dependent and the nature of the failure the next-hop is dependent on the topology and the nature of the failure
alternate is calculated for. the alternate is calculated for.
This specification uses the terminology introduced in
[I-D.ietf-rtgwg-ipfrr-framework]. In particular, it uses
Distance_opt(X,Y), abbreviated to D_opt(X,Y), to indicate the
shortest distance from X to Y. S is used to indicate the calculating
router. N_i is a neighbor of S; N is used as an abbreviation when
only one neighbor is being discussed. D is the destination under
consideration.
A neighbor N can provide a loop-free alternate (LFA) if and only if A neighbor N can provide a loop-free alternate (LFA) if and only if
Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D) Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)
Equation 1: Loop-Free Criterion Inequality 1: Loop-Free Criterion
A sub-set of loop-free alternate are downstream paths which must meet A sub-set of loop-free alternate are downstream paths which must meet
a more restrictive condition that is applicable to more complex a more restrictive condition that is applicable to more complex
failure scenarios: failure scenarios:
Distance_opt(N, D) < Distance_opt(S, D) Distance_opt(N, D) < Distance_opt(S, D)
Equation 2: Downstream Path Criterion Inequality 2: Downstream Path Criterion
1.1 Failure Scenarios 1.1. Failure Scenarios
The alternate next-hop can protect against a single link failure, a The alternate next-hop can protect against a single link failure, a
single node failure, one or more shared risk link group failure, or a single node failure, one or more shared risk link group failures, or
combination of these. Whenever a failure occurs that is more a combination of these. Whenever a failure occurs that is more
extensive than what the alternate was intended to protect, there is extensive than what the alternate was intended to protect, there is
the possibility of temporarily looping traffic (note again, that such the possibility of temporarily looping traffic (note again, that such
a loop would only last until the next complete SPF calculation). The a loop would only last until the next complete SPF calculation). The
example where a node fails when the alternate provided only link example where a node fails when the alternate provided only link
protection is illustrated below. If unexpected simultaneous failures protection is illustrated below. If unexpected simultaneous failures
occur, then micro-looping may occur since the alternates are not pre- occur, then micro-looping may occur since the alternates are not pre-
computed to avoid the set of failed links. computed to avoid the set of failed links.
If only link protection is provided and the node fails, it is If only link protection is provided and the node fails, it is
possible for traffic using the alternates to experience micro- possible for traffic using the alternates to experience micro-
skipping to change at page 6, line 4 skipping to change at page 6, line 24
| +-----+ | | +-----+ |
+----| E |---+ +----| E |---+
+--+--+ +--+--+
| |
| |
| 10 | 10
| |
+--+--+ +--+--+
| D | | D |
+-----+ +-----+
Figure 2: Link-Protecting Alternates Causing Loop on Node Failure Figure 2: Link-Protecting Alternates Causing Loop on Node Failure
Micro-looping of traffic via the alternates caused when a more Micro-looping of traffic via the alternates caused when a more
extensive failure than planned for can be prevented via selection of extensive failure than planned for occurs can be prevented via
only downstream paths as alternates. In Figure 2, S would be able to selection of only downstream paths as alternates. In Figure 2, S
use N as an alternate, but N could not use S; therefore N would have would be able to use N as an alternate, but N could not use S;
no alternate and would discard the traffic, thus avoiding the micro- therefore N would have no alternate and would discard the traffic,
loop. A micro-loop due to the use of alternates can be avoided by thus avoiding the micro-loop. A micro-loop due to the use of
using downstream paths because each router in the path to the alternates can be avoided by using downstream paths because each
destination must be closer to the destination (according to the succeeding router in the path to the destination must be closer to
topology prior to the failures). Although use of downstream paths the destination than its predecessor (according to the topology prior
ensures that the micro-looping via alternates does not occur, such a to the failures). Although use of downstream paths ensures that the
restriction can severely limit the coverage of alternates. micro-looping via alternates does not occur, such a restriction can
severely limit the coverage of alternates.
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-
skipping to change at page 6, line 41 skipping to change at page 7, line 14
physical port because of channelization, or if multiple interfaces physical port because of channelization, or if multiple interfaces
share a correlated failure because they are on the same line-card. share a correlated failure because they are on the same line-card.
This sub-category of SRLGs will be referred to as local-SRLGs. A This sub-category of SRLGs will be referred to as local-SRLGs. A
local-SRLG has all of its member links with one end connected to the local-SRLG has all of its member links with one end connected to the
same router. Thus, router S could select a loop-free alternate which same router. Thus, router S could select a loop-free alternate which
does not use a link in the same local-SRLG as the primary next-hop. does not use a link in the same local-SRLG as the primary next-hop.
The local-SRLGs belonging to E can be protected against via node- The local-SRLGs belonging to E can be protected against via node-
protection; i.e. picking a loop-free node-protecting alternate. protection; i.e. picking a loop-free node-protecting alternate.
Where SRLG protection is provided, it is in the context of the Where SRLG protection is provided, it is in the context of the
particular OSPF or ISIS area, whose topology is used the SPF particular OSPF or ISIS area, whose topology is used in the SPF
computations to compute the loop-free alternates. If an SRLG computations to compute the loop-free alternates. If an SRLG
contains links in multiple areas, then separate SRLG-protecting contains links in multiple areas, then separate SRLG-protecting
alternates would be required in each area that is traversed by the alternates would be required in each area that is traversed by the
affected traffic. affected traffic.
2. Applicability of Described Mechanisms 2. Applicability of Described Mechanisms
IP Fast Reroute mechanisms described in this memo cover intra-domain IP Fast Reroute mechanisms described in this memo cover intra-domain
routing only, with OSPF[RFC2328] or ISIS [RFC1195] [RFC2966] as the routing only, with OSPF[RFC2328] or ISIS [RFC1195] [RFC2966] as the
IGP. Specifically, Fast Reroute for BGP inter-domain routing is not IGP. Specifically, Fast Reroute for BGP inter-domain routing is not
part of this specification. part of this specification.
Certain aspects of OSPF inter-area routing behavior explained in Certain aspects of OSPF inter-area routing behavior explained in
Section 6.2 and Appendix A impact the ability of the router Section 6.3 and Appendix A impact the ability of the router
calculating the backup next-hops to assess traffic trajectories. In calculating the backup next-hops to assess traffic trajectories. In
order to avoid micro-looping and ensure required coverage, certain order to avoid micro-looping and ensure required coverage, certain
constrains are applied to multi-area OSPF networks: constraints are applied to multi-area OSPF networks:
a. Loop-free alternates should not be used in the backbone area if a. Loop-free alternates should not be used in the backbone area if
there are any virtual links configured unless, for each transit there are any virtual links configured unless, for each transit
area, there is a full mesh of virtual links between all ABRs in area, there is a full mesh of virtual links between all ABRs in
that area. Loop-free alternates may be used in non-backbone that area. Loop-free alternates may be used in non-backbone
areas regardless of whether there are virtual links configured. areas regardless of whether there are virtual links configured.
b. Loop-free alternates should not be used for inter-area routes in b. Loop-free alternates should not be used for inter-area routes in
an area that contains more than one alternate ABR. [RFC3509] an area that contains more than one alternate ABR. [RFC3509]
skipping to change at page 7, line 41 skipping to change at page 8, line 15
forwarding address of 0.0.0.0 or by one or more ASBRs with forwarding address of 0.0.0.0 or by one or more ASBRs with
forwarding addresses in multiple non-backbone areas when an ABR forwarding addresses in multiple non-backbone areas when an ABR
exists simultaneously in two or more of those non-backbone areas. exists simultaneously in two or more of those non-backbone areas.
3. Alternate Next-Hop Calculation 3. Alternate Next-Hop Calculation
In addition to the set of primary next-hops obtained through a In addition to the set of primary next-hops obtained through a
shortest path tree (SPT) computation that is part of standard link- shortest path tree (SPT) computation that is part of standard link-
state routing functionality, routers supporting IP Fast Reroute also state routing functionality, routers supporting IP Fast Reroute also
calculate a set of backup next hops that are engaged when a local calculate a set of backup next hops that are engaged when a local
failure occurs. These backup next hops are calculated to provide failure occurs. These backup next hops are calculated to provide the
required type of protection (i.e. link-protecting and/or node- required type of protection (i.e. link-protecting and/or node-
protecting) and to guarantee that when the expected failure occurs, protecting) and to guarantee that when the expected failure occurs,
forwarding traffic through them will not result in a loop. Such next forwarding traffic through them will not result in a loop. Such next
hops are called loop-free alternates or LFAs throughout this hops are called loop-free alternates or LFAs throughout this
specification. specification.
In general, to be able to calculate the set of LFAs for a specific In general, to be able to calculate the set of LFAs for a specific
destination D, a router needs to know the following basic pieces of destination D, a router needs to know the following basic pieces of
information: information:
skipping to change at page 8, line 24 skipping to change at page 8, line 45
o Distance_opt(S, D) is normally available from the regular SPF o Distance_opt(S, D) is normally available from the regular SPF
calculation performed by the link-state routing protocols. calculation performed by the link-state routing protocols.
Distance_opt(N, D) and Distance_opt(N, S) can be obtained by Distance_opt(N, D) and Distance_opt(N, S) can be obtained by
performing additional SPF calculations from the perspective of performing additional SPF calculations from the perspective of
each IGP neighbor (i.e. considering the neighbor's vertex as the each IGP neighbor (i.e. considering the neighbor's vertex as the
root of the SPT--called SPT(N) hereafter--rather than the root of the SPT--called SPT(N) hereafter--rather than the
calculating router's one, called SPT(S)). calculating router's one, called SPT(S)).
This specification defines a form of SRLG protection limited to those This specification defines a form of SRLG protection limited to those
SRLGs that include a link that the calculating router is directly SRLGs that include a link that the calculating router is directly
connected to. Information about local link SRLG membership is connected to. Only that set of SRLGs could cause a local failure;
manually configured. Information about remote link SRLG membership the calculating router only computes alternates to handle a local
is dynamically obtained using [RFC4205] or [RFC4203]. In order to failure. Information about local link SRLG membership is manually
choose among all available LFAs that provide required SRLG protection configured. Information about remote link SRLG membership may be
for a given destination, the calculating router needs to track the dynamically obtained using [RFC4205] or [RFC4203]. Define
set of SRLGs that the path through a specific IGP neighbor involves. SRLG_local(S) to be the set of SRLGs that include a link that the
To do so, each node D in the network topology is associated with calculating router S is directly connected to. Only SRLG_local(S) is
SRLG_set(N, D), which is the set of SRLGs that would be crossed if of interest during the calculation, but the calculating router must
traffic to D was forwarded through N. To calculate this set, the correctly handle changes to SRLG_local(S) triggered by local link
router initializes SRLG_set(N, N) for each of its IGP neighbors to be SRLG membership changes.
empty. During the SPT(N) calculation, when a new vertex V is added
to the SPT, its SRLG_set(N, V) is set to the union of SRLG sets In order to choose among all available LFAs that provide required
associated with its parents, and the SRLG sets associated with the SRLG protection for a given destination, the calculating router needs
links from V's parents to V. The union of the set of SRLG associated to track the set of SRLGs in SRLG_local(S) that the path through a
with a candidate alternate next-hop and the SRLG_set(N, D) for the specific IGP neighbor involves. To do so, each node D in the network
neighbor reached via that candidate next-hop is used to determine topology is associated with SRLG_set(N, D), which is the set of SRLGs
SRLG protection. that would be crossed if traffic to D was forwarded through N. To
calculate this set, the router initializes SRLG_set(N, N) for each of
its IGP neighbors to be empty. During the SPT(N) calculation, when a
new vertex V is added to the SPT, its SRLG_set(N, V) is set to the
union of SRLG sets associated with its parents, and the SRLG sets in
SRLG_local(S) that are associated with the links from V's parents to
V. The union of the set of SRLG associated with a candidate alternate
next-hop and the SRLG_set(N, D) for the neighbor reached via that
candidate next-hop is used to determine SRLG protection.
The following sections provide information required for calculation The following sections provide information required for calculation
of LFAs. Sections Section 3.1 through Section 3.4 define different of LFAs. Sections Section 3.1 through Section 3.4 define different
types of LFA conditions. Section 3.5 describes constrains imposed by types of LFA conditions. Section 3.5 describes constraints imposed
the IS-IS overload and OSPF stub router functionality. Section 3.6 by the IS-IS overload and OSPF stub router functionality.
defines the summarized algorithm for LFA calculation using the Section 3.6 defines the summarized algorithm for LFA calculation
definitions in the previous sections. using the definitions in the previous sections.
3.1 Basic Loop-free Condition 3.1. Basic Loop-free Condition
Alternate next hops used by implementations following this Alternate next hops used by implementations following this
specification MUST conform to at least the loop-freeness condition specification MUST conform to at least the loop-freeness condition
stated above in Equation 1. This condition guarantees that stated above in Inequality 1. This condition guarantees that
forwarding traffic to an LFA will not result in a loop after a link forwarding traffic to an LFA will not result in a loop after a link
failure. failure.
Further conditions may be applied when determining link-protecting Further conditions may be applied when determining link-protecting
and/or node-protecting alternate next-hops as described in Sections and/or node-protecting alternate next-hops as described in Sections
Section 3.2 and Section 3.3. Section 3.2 and Section 3.3.
3.2 Node-Protecting Alternate Next-Hops 3.2. Node-Protecting Alternate Next-Hops
For an alternate next-hop N to protect against node failure of a For an alternate next-hop N to protect against node failure of a
primary neighbor E for destination D, N must be loop-free with primary neighbor E for destination D, N must be loop-free with
respect to both E and D. In other words, N's path to D must not go respect to both E and D. In other words, N's path to D must not go
through E. This is the case if Equation 3 is true, where N is the through E. This is the case if Inequality 3 is true, where N is the
neighbor providing a loop-free alternate. neighbor providing a loop-free alternate.
Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D) Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D)
Equation 3: Criteria for a Node-Protecting Loop-Free Alternate Inequality 3: Criteria for a Node-Protecting Loop-Free Alternate
If Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), it is If Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), it is
possible that N has equal-cost paths and one of those could provide possible that N has equal-cost paths and one of those could provide
protection against E's node failure. However, it is equally possible protection against E's node failure. However, it is equally possible
that one of N's paths goes through E, and the calculating router has that one of N's paths goes through E, and the calculating router has
no way to influence N's decision to use it. Therefore, it SHOULD be no way to influence N's decision to use it. Therefore, it SHOULD be
assumed that an alternate next-hop does not offer node protection if assumed that an alternate next-hop does not offer node protection if
Equation 3 is not met. Inequality 3 is not met.
3.3 Broadcast and NBMA Links 3.3. Broadcast and NBMA Links
Verification of the link-protection property of a next hop in the Verification of the link-protection property of a next hop in the
case of a broadcast link is more elaborate than for a point-to-point case of a broadcast link is more elaborate than for a point-to-point
link. This is because a broadcast link is represented as a pseudo- link. This is because a broadcast link is represented as a pseudo-
node with zero-cost links connecting it to other nodes. node with zero-cost links connecting it to other nodes.
Because failure of an interface attached to a broadcast segment may Because failure of an interface attached to a broadcast segment may
mean loss of connectivity of the whole segment, the condition mean loss of connectivity of the whole segment, the condition
described for broadcast link protection is pessimistic and requires described for broadcast link protection is pessimistic and requires
that the alternate is loop-free with regard to the pseudo-node. that the alternate is loop-free with regard to the pseudo-node.
skipping to change at page 10, line 26 skipping to change at page 10, line 51
| 5 | | 5 |
+-----+ 5 +-----+ +-----+ 5 +-----+
| E |----| D | | E |----| D |
+-----+ +-----+ +-----+ +-----+
Figure 3: Loop-Free Alternate that is Link-Protecting Figure 3: Loop-Free Alternate that is Link-Protecting
In Figure 3, N offers a loop-free alternate which is link-protecting. In Figure 3, N offers a loop-free alternate which is link-protecting.
If the primary next-hop uses a broadcast link, then an alternate If the primary next-hop uses a broadcast link, then an alternate
SHOULD be loop-free with respect to that link's pseudo-node to SHOULD be loop-free with respect to that link's pseudo-node to
provide link protection. This requirement is described in Equation 4 provide link protection. This requirement is described in
below. Inequality 4 below.
D_opt(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D) D_opt(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D)
Equation 4: Loop-Free Link-Protecting Criterion for Broadcast Links Inequality 4: Loop-Free Link-Protecting Criterion for Broadcast Links
Because the shortest path from the pseudo-node goes through E, if a Because the shortest path from the pseudo-node goes through E, if a
loop-free alternate from a neighbor N is node-protecting, the loop-free alternate from a neighbor N is node-protecting, the
alternate will also be link-protecting unless the router S can only alternate will also be link-protecting unless the router S can only
reach the alternate neighbor N via the same pseudo-node. This can reach the alternate neighbor N via the same pseudo-node. Because S
occur because S will direct traffic away from the shortest path to can direct the traffic away from the shortest path to use the
use an alternate. alternate N, traffic might pass through the same broadcast link as it
would when S sent the traffic to the primary E. Thus, an LFA from N
that is node-protecting is not automatically link-protecting.
To obtain link protection, it is necessary both that the path from To obtain link protection, it is necessary both that the path from
the selected alternate next-hop does not traverse the link of the selected alternate next-hop does not traverse the link of
interest and that the link used from S to reach that alternate next- interest and that the link used from S to reach that alternate next-
hop is not the link of interest. The latter can only occur with non- hop is not the link of interest. The latter can only occur with non-
point-to-point links. Therefore, if the primary next-hop is across a point-to-point links. Therefore, if the primary next-hop is across a
broadcast or NBMA interface, it is necessary to consider link broadcast or NBMA interface, it is necessary to consider link
protection during the alternate selection. Similar consideration of protection during the alternate selection. To clarify, consider the
the link from S to the selected alternate next-hop as well as the topology in Figure 3. For N to provide link-protection, it is first
path from the selected alternate next-hop is also necessary for SRLG necessary that N's shortest path to D does not traverse the pseudo-
protection. node PN. Second, it is necessary that the alternate next-hop
selected by S does not traverse PN. In this example, S's shortest
path to N is via the pseudo-node. Thus, to obtain link-protection, S
must find a next-hop to N (the point-to-point link from S to N in
this example) that avoids the pseudo-node PN.
3.4 ECMP and Alternates Similar consideration of the link from S to the selected alternate
next-hop as well as the path from the selected alternate next-hop is
also necessary for SRLG protection. S's shortest path to the
selected neighbor N may not be acceptable as an alternate next-hop to
provide SRLG protection, even if the path from N to D can provide
SRLG protection.
3.4. ECMP and Alternates
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
skipping to change at page 11, line 48 skipping to change at page 12, line 38
can obtain link and node protection from L2 to E1 and from L2 to E2. can obtain link and node protection from L2 to E1 and from L2 to E2.
It is possible for both the primary next-hop L2 to E2 and the primary It is possible for both the primary next-hop L2 to E2 and the primary
next-hop L2 to E1 to obtain an alternate next-hop that provides both next-hop L2 to E1 to obtain an alternate next-hop that provides both
link and node protection by using L1. link and node protection by using L1.
Alternate next-hops are determined for each primary next-hop Alternate next-hops are determined for each primary next-hop
separately. As with alternate selection in the non-ECMP case, these separately. As with alternate selection in the non-ECMP case, these
alternate next-hops should maximize the coverage of the failure alternate next-hops should maximize the coverage of the failure
cases. cases.
3.5 Interactions with ISIS Overload, RFC 3137 and Costed Out Links 3.5. Interactions with ISIS Overload, RFC 3137 and Costed Out Links
As described in [RFC3137], there are cases where it is desirable not As described in [RFC3137], there are cases where it is desirable not
to have a router used as a transit node. For those cases, it is also to have a router used as a transit node. For those cases, it is also
desirable not to have the router used on an alternate path. desirable not to have the router used on an alternate path.
For computing an alternate, a router MUST NOT use an alternate next- For computing an alternate, a router MUST NOT use an alternate next-
hop that is along a link whose cost or reverse cost is LSInfinity hop that is along a link whose cost or reverse cost is LSInfinity
(for OSPF) or the maximum cost (for ISIS) or which has the overload (for OSPF) or the maximum cost (for ISIS) or which has the overload
bit set (for ISIS). For a broadcast link, the reverse cost bit set (for ISIS). For a broadcast link, the reverse cost
associated with a potential alternate next-hop is the cost towards associated with a potential alternate next-hop is the cost towards
skipping to change at page 12, line 33 skipping to change at page 13, line 23
router which is following [RFC3137] and it also preserves the desired router which is following [RFC3137] and it also preserves the desired
behavior when an operator sets the cost of a link to LSInfinity for behavior when an operator sets the cost of a link to LSInfinity for
maintenance which is not permitting traffic across that link unless maintenance which is not permitting traffic across that link unless
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 SHOULD NOT specify the
"local protection available" flag as a result of having LFAs. A "local protection available" flag as a result of having LFAs. A
router SHOULD NOT use an alternate next-hop that is along a link for router SHOULD NOT use an alternate next-hop that is along a link for
which the link has been advertised with the attribute "link excluded which the link has been advertised with the attribute "link excluded
from local protection path" or with the attribute "local mainenance 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.
The alternate selection should maximize the coverage of the failure The alternate selection should maximize the coverage of the failure
cases. cases.
skipping to change at page 13, line 29 skipping to change at page 14, line 20
3. If S has multiple primary next-hops, then S SHOULD select as a 3. If S has multiple primary next-hops, then S SHOULD select as a
loop-free alternate either one of the other primary next-hops or loop-free alternate either one of the other primary next-hops or
a loop-free node-protecting alternate if available. If no loop- a loop-free node-protecting alternate if available. If no loop-
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 a minimal level of protection are preferred over any non- least link or node protection are preferred over any non-primary
primary alternates. This mode is provided to allow the alternates. This mode is provided to allow the administrator to
administrator to preserve traffic patterns based on regular ECMP preserve traffic patterns based on regular ECMP behavior.
behavior.
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.
Loop-Free Node-Protecting Alternate - This next-hop satisfies Loop-Free Node-Protecting Alternate - This next-hop satisfies
Equation 1 and Equation 3. The path avoids S, S's primary Inequality 1 and Inequality 3. The path avoids S, S's primary
neighbor E, and the link from S to E. neighbor E, and the link from S to E.
Loop-Free Link-Protecting Alternate - This next-hop satisfies Loop-Free Link-Protecting Alternate - This next-hop satisfies
Equation 1 but not Equation 3. If the primary next-hop uses a Inequality 1 but not Inequality 3. If the primary next-hop uses a
broadcast link, then this next-hop satisfies Equation 4. broadcast link, then this next-hop satisfies Inequality 4.
An alternate path may also provide none, some or complete SRLG An alternate path may also provide none, some or complete SRLG
protection as well as node and link or link protection. For protection as well as node and link or link protection. For
instance, a link may belong to two SRLGs G1 and G2. The alternate instance, a link may belong to two SRLGs G1 and G2. The alternate
path might avoid other links in G1 but not G2, in which case the path might avoid other links in G1 but not G2, in which case the
alternate would only provide partial SRLG protection. alternate would only provide partial SRLG protection.
Below is an algorithm that can be used to calculate loop-free Below is an algorithm that can be used to calculate loop-free
alternate next-hops. The algorithm is given for informational alternate next-hops. The algorithm is given for informational
purposes and implementations are free to use any other algorithm as purposes and implementations are free to use any other algorithm as
skipping to change at page 14, line 32 skipping to change at page 15, line 21
when the logical topological transformation described in Section 6.1 when the logical topological transformation described in Section 6.1
is used. is used.
S is the computing router and has candidate next-hops H_1 through S is the computing router and has candidate next-hops H_1 through
H_k. N_i and N_j are used to refer to neighbors of S. For a next-hop H_k. N_i and N_j are used to refer to neighbors of S. For a next-hop
to be a candidate, the next-hop must be associated with a bi- to be a candidate, the next-hop must be associated with a bi-
directional link, as is determined by the IGP. For a particular directional link, as is determined by the IGP. For a particular
destination router D, let S have already computed D_opt(S, D), and destination router D, let S have already computed D_opt(S, D), and
for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i, for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i,
N_j), the distance from N_i to each other neighbor N_j, and the set N_j), the distance from N_i to each other neighbor N_j, and the set
of SRLGs traversed by the path D_opt(N_i, D). S SHOULD follow the of SRLGs traversed by the path D_opt(N_i, D). S should follow the
below procedure for every primary next-hop selected to reach D. This below procedure for every primary next-hop selected to reach D. This
set of primary next-hops is represented P_1 to P_p. This procedure set of primary next-hops is represented P_1 to P_p. This procedure
finds the alternate next-hop(s) for P_i. finds the alternate next-hop(s) for P_i.
First, initialize the alternate information for P_i as follows: First, initialize the alternate information for P_i as follows:
P_i.alt_next_hops = {} P_i.alt_next_hops = {}
P_i.alt_type = NONE P_i.alt_link-protect = FALSE P_i.alt_type = NONE
P_i.alt_link-protect = FALSE
P_i.alt_node-protect = FALSE P_i.alt_node-protect = FALSE
P_i.alt_srlg-protect = {} P_i.alt_srlg-protect = {}
For each candidate next-hop H_h, For each candidate next-hop H_h,
1. Initialize variables as follows: 1. Initialize variables as follows:
cand_type = NONE cand_type = NONE
cand_link-protect = FALSE cand_link-protect = FALSE
cand_node-protect = FALSE cand_node-protect = FALSE
skipping to change at page 15, line 4 skipping to change at page 15, line 42
P_i.alt_srlg-protect = {} P_i.alt_srlg-protect = {}
For each candidate next-hop H_h, For each candidate next-hop H_h,
1. Initialize variables as follows: 1. Initialize variables as follows:
cand_type = NONE cand_type = NONE
cand_link-protect = FALSE cand_link-protect = FALSE
cand_node-protect = FALSE cand_node-protect = FALSE
cand_srlg-protect = {} cand_srlg-protect = {}
2. If H_h is P_i, skip it and continue to the next candidate next- 2. If H_h is P_i, skip it and continue to the next candidate next-
hop. hop.
3. If H_h.link is administratively allowed to be used as an 3. If H_h.link is administratively allowed to be used as an
alternate, alternate,
and the cost of H_h.link less than the maximum, and the cost of H_h.link is less than the maximum,
and the reverse cost of H_h is less than the maximum, and the reverse cost of H_h is less than the maximum,
and H_h.neighbor is not overloaded (for ISIS), and H_h.neighbor is not overloaded (for ISIS),
and H_h.link is bi-directional, and H_h.link is bi-directional,
then H_h can be considered as an alternate. Otherwise, skip it then H_h can be considered as an alternate. Otherwise, skip it
and continue to the next candidate next-hop. and continue to the next candidate next-hop.
4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S, 4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S,
D), then H_h is not loop-free. Skip it and continue to the next D), then H_h is not loop-free. Skip it and continue to the next
candidate next-hop. candidate next-hop.
5. cand_type = LOOP-FREE. 5. cand_type = LOOP-FREE.
6. If H_h is a primary next-hop, set cand_type to PRIMARY. 6. If H_h is a primary next-hop, set cand_type to PRIMARY.
skipping to change at page 15, line 26 skipping to change at page 16, line 15
and continue to the next candidate next-hop. and continue to the next candidate next-hop.
4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S, 4. If D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S,
D), then H_h is not loop-free. Skip it and continue to the next D), then H_h is not loop-free. Skip it and continue to the next
candidate next-hop. candidate next-hop.
5. cand_type = LOOP-FREE. 5. cand_type = LOOP-FREE.
6. If H_h is a primary next-hop, set cand_type to PRIMARY. 6. If H_h is a primary next-hop, set cand_type to PRIMARY.
7. If H_h.link is not P_i.link, set can_link-protect to TRUE. 7. If H_h.link is not P_i.link, set cand_link-protect to TRUE.
8. If D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) + 8. If D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) +
D_opt(P_i.neighbor, D), set cand_node-protect to TRUE. D_opt(P_i.neighbor, D), set cand_node-protect to TRUE.
9. If the router considers SRLGs, then set the cand_srlg-protect to 9. If the router considers SRLGs, then set the cand_srlg-protect to
the set of SRLGs traversed on the path from S via P_i to the set of SRLGs traversed on the path from S via P_i to
P_i.neighbor. Remove the set of SRLGs to which H_h belongs from P_i.neighbor. Remove the set of SRLGs to which H_h belongs from
cand_srlg-protect. Remove from cand_srlg-protect the set of cand_srlg-protect. Remove from cand_srlg-protect the set of
SRLGs traversed on the path from H_h.neighbor to D. Now SRLGs traversed on the path from H_h.neighbor to D. Now
cand_srlg-protect holds the set of SRLGs to which P_i belongs cand_srlg-protect holds the set of SRLGs to which P_i belongs
and that are not traversed on the path from S via H_h to D. and that are not traversed on the path from S via H_h to D.
10. If cand_type is PRIMARY, the router prefers other primary next- 10. If cand_type is PRIMARY, the router prefers other primary next-
hops for use as the alternate, and the P_i.alt_type is not hops for use as the alternate, and the P_i.alt_type is not
PRIMARY, goto Step 18. PRIMARY, goto Step 19.
11. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE, 11. If cand_node-protect is TRUE and P_i.alt_node-protect is FALSE,
goto Paragraph 18. goto Paragraph 19.
12. If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE, 12. If cand_link-protect is TRUE and P_i.alt_link-protect is FALSE,
goto Step 18. goto Step 19.
13. If cand_srlg-protect has a better set of SRLGs than 13. If cand_srlg-protect has a better set of SRLGs than
P_i.alt_srlg-protect, goto Step 18. P_i.alt_srlg-protect, goto Step 19.
14. If cand_srlg-protect is different from P_i.alt_srlg-protect, 14. If cand_srlg-protect is different from P_i.alt_srlg-protect,
then select between H_h and P_i.alt_next_hops based upon then select between H_h and P_i.alt_next_hops based upon
distance, IP addresses, or any router-local tie-breaker. If H_h distance, IP addresses, or any router-local tie-breaker. If H_h
is preferred, then goto to Step 18. Otherwise, skip H_h and is preferred, then goto Step 19. Otherwise, skip H_h and
continue to the next candidate next-hop. continue to the next candidate next-hop.
15. Based upon the alternate types, the alternate distances, IP 15. If D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D) and
D_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h
is a downstream alternate and P_i.alt_next_hops is simply an
LFA. Prefer H_h and goto Step 19.
16. Based upon the alternate types, the alternate distances, IP
addresses, or other tie-breakers, decide if H_h is preferred to addresses, or other tie-breakers, decide if H_h is preferred to
P_i.alt_next_hops. If so, goto Step 18. P_i.alt_next_hops. If so, goto Step 19.
16. Decide if P_i.alt_next_hops is preferred to H_h. If so, then 17. Decide if P_i.alt_next_hops is preferred to H_h. If so, then
skip H_h and continue to the next candidate next-hop. skip H_h and continue to the next candidate next-hop.
17. Add H_h into P_i.alt_next_hops. Set P_i.alt_type to the better 18. Add H_h into P_i.alt_next_hops. Set P_i.alt_type to the better
type of H_h.alt_type and P_i.alt_type. Continue to the next type of H_h.alt_type and P_i.alt_type. Continue to the next
candidate next-hop. candidate next-hop.
18. 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.
4. Using an Alternate 4. Using an Alternate
skipping to change at page 17, line 9 skipping to change at page 18, line 5
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.
The alternate next-hop MUST be used only for traffic types which are The alternate next-hop MUST be used only for traffic types which are
routed according to the shortest path. Multicast traffic is routed according to the shortest path. Multicast traffic is
specifically out of scope for this specification. specifically out of scope for this specification.
4.1 Terminating Use of Alternate 4.1. Terminating Use of Alternate
A router MUST limit the amount of time an alternate next-hop is used A router MUST limit the amount of time an alternate next-hop is used
after the primary next-hop has become unavailable. This ensures that after the primary next-hop has become unavailable. This ensures that
the router will start using the new primary next-hops. It ensures the router will start using the new primary next-hops. It ensures
that all possible transient conditions are removed and the network that all possible transient conditions are removed and the network
converges according to the deployed routing protocol. converges according to the deployed routing protocol.
A router that implements [I-D.ietf-rtgwg-microloop-analysis] SHOULD A router that implements [I-D.ietf-rtgwg-microloop-analysis] SHOULD
follow the rules given there for terminating the use of an alternate. follow the rules given there for terminating the use of an alternate.
A router that implements [I-D.francois-ordered-fib] SHOULD follow the
rules given there for terminating the use of an alternate.
It is desirable to avoid micro-forwarding loops involving S. An It is desirable to avoid micro-forwarding loops involving S. An
example illustrating the problem is given in Figure 5. If the link example illustrating the problem is given in Figure 5. If the link
from S to E fails, S will use N1 as an alternate and S will compute from S to E fails, S will use N1 as an alternate and S will compute
N2 as the new primary next-hop to reach D. If S starts using N2 as N2 as the new primary next-hop to reach D. If S starts using N2 as
soon as S can compute and install its new primary, it is probable soon as S can compute and install its new primary, it is probable
that N2 will not have yet installed its new primary next-hop. This that N2 will not have yet installed its new primary next-hop. This
would cause traffic to loop and be dropped until N2 has installed the would cause traffic to loop and be dropped until N2 has installed the
new topology. This can be avoided by S delaying its installation and new topology. This can be avoided by S delaying its installation and
leaving traffic on the alternate next-hop. leaving traffic on the alternate next-hop.
skipping to change at page 18, line 39 skipping to change at page 19, line 38
change, or change, or
b. if a configured hold-down, which represents a worst-case bound on b. if a configured hold-down, which represents a worst-case bound on
the length of the network convergence transition, has expired, or the length of the network convergence transition, has expired, or
c. if notification of an unrelated topological change in the network c. if notification of an unrelated topological change in the network
is received. is received.
5. Requirements on LDP Mode 5. Requirements on LDP Mode
Since LDP traffic will follow the path specified by the IGP, it is Since LDP [RFC3036] traffic will follow the path specified by the
also possible for the LDP traffic to follow the loop-free alternates IGP, it is also possible for the LDP traffic to follow the loop-free
indicated by the IGP. To do so, it is necessary for LDP to have the alternates indicated by the IGP. To do so, it is necessary for LDP
appropriate labels available for the alternate so that the to have the appropriate labels available for the alternate so that
appropriate out-segments can be installed in the forwarding plane the appropriate out-segments can be installed in the forwarding plane
before the failure occurs. before the failure occurs.
This means that a Label Switched Router (LSR) running LDP must This means that a Label Switched Router (LSR) running LDP must
distribute its labels for the FECs it can provide to all its distribute its labels for the FECs it can provide to all its
neighbors, regardless of whether or not they are upstream. neighbors, regardless of whether or not they are upstream.
Additionally, LDP must be acting in liberal label retention mode so Additionally, LDP must be acting in liberal label retention mode so
that the labels which correspond to neighbors that aren't currently that the labels which correspond to neighbors that aren't currently
the primary neighbor are stored. Similarly, LDP should be in the primary neighbor are stored. Similarly, LDP should be in
downstream unsolicited mode, so that the labels for the FEC are downstream unsolicited mode, so that the labels for the FEC are
distributed other than along the SPT. distributed other than along the SPT.
If these requirements are met, then LDP can use the loop-free If these requirements are met, then LDP can use the loop-free
alternates without requiring any targeted sessions or signaling alternates without requiring any targeted sessions or signaling
extensions for this purpose. extensions for this purpose.
6. Routing Aspects 6. Routing Aspects
6.1 Multi-Homed Prefixes 6.1. Multi-Homed Prefixes
An SPF-like computation is run for each topology, which corresponds An SPF-like computation is run for each topology, which corresponds
to a particular OSPF area or ISIS level. The IGP needs to determine to a particular OSPF area or ISIS level. The IGP needs to determine
loop-free alternates to multi-homed routes. Multi-homed routes occur loop-free alternates to multi-homed routes. Multi-homed routes occur
for routes obtained from outside the routing domain by multiple for routes obtained from outside the routing domain by multiple
routers, for subnets on links where the subnet is announced from routers, for subnets on links where the subnet is announced from
multiple ends of the link, and for routes advertised by multiple multiple ends of the link, and for routes advertised by multiple
routers to provide resiliency. routers to provide resiliency.
Figure 6 demonstrates such a topology. In this example, the shortest Figure 6 demonstrates such a topology. In this example, the shortest
skipping to change at page 20, line 14 skipping to change at page 21, line 14
connectivity and the difference in metrics to those routers, then a connectivity and the difference in metrics to those routers, then a
single node can be used to represent the set. For instance, if in single node can be used to represent the set. For instance, if in
Figure 6 there were another prefix X that was connected to E with a Figure 6 there were another prefix X that was connected to E with a
metric of 1 and to F with a metric of 3, then that prefix X could use metric of 1 and to F with a metric of 3, then that prefix X could use
the same alternate next-hop as was computed for prefix p. the same alternate next-hop as was computed for prefix p.
A router SHOULD compute the alternate next-hop for an IGP multi-homed A router SHOULD compute the alternate next-hop for an IGP multi-homed
prefix by considering alternate paths via all routers that have prefix by considering alternate paths via all routers that have
announced that prefix. announced that prefix.
6.2 OSPF 6.2. ISIS
The applicability and interactions of LFAs with multi-topology ISIS
[I-D.ietf-isis-wg-multi-topology] is out of scope for this
specification.
6.3. OSPF
OSPF introduces certain complications because it is possible for the OSPF introduces certain complications because it is possible for the
traffic path to exit an area and then re-enter that area. This can traffic path to exit an area and then re-enter that area. This can
occur whenever a router considers the same route from multiple areas. occur whenever a router considers the same route from multiple areas.
There are several cases where issues such as this can occur. They There are several cases where issues such as this can occur. They
happen when another area permits a shorter path to connect two ABRs happen when another area permits a shorter path to connect two ABRs
than is available in the area where the LFA has been computed. To than is available in the area where the LFA has been computed. To
clarify, an example topology is given in Appendix A. clarify, an example topology is given in Appendix A.
a. Virtual Links: These allow paths to leave the backbone area and a. Virtual Links: These allow paths to leave the backbone area and
skipping to change at page 20, line 47 skipping to change at page 22, line 5
into multiple areas. This presents other ABRs with a decision as into multiple areas. This presents other ABRs with a decision as
to which area to use. This is the example illustrated in to which area to use. This is the example illustrated in
Figure 7. Figure 7.
d. AS External Prefixes: A prefix may be advertised by multiple d. AS External Prefixes: A prefix may be advertised by multiple
ASBRs in different areas and/or with multiple forwarding ASBRs in different areas and/or with multiple forwarding
addresses that are in different areas, which are connected via at addresses that are in different areas, which are connected via at
least one common ABR. This presents such ABRs with a decision as least one common ABR. This presents such ABRs with a decision as
to which area to use to reach the prefix. to which area to use to reach the prefix.
6.2.1 OSPF External Routing Loop-free alternates should not be used in an area where one of the
above issues affects that area.
6.3.1. OSPF External Routing
When a forwarding address is set in an OSPF AS-external LSA, all When a forwarding address is set in an OSPF AS-external LSA, all
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 BGP Next-Hop Synchronization 6.3.2. OSPF Multi-Topology
Typically BGP prefixes are advertised with AS exit routers router-id, The applicabilty and interactions of LFAs with multi-topology OSPF
and AS exit routers are reached by means of IGP routes. BGP resolves [I-D.ietf-ospf-mt] [I-D.ietf-ospf-mt-ospfv3] is out of scope for this
its advertised next-hop to the immediate next-hop by potential specification.
recursive lookups in the routing database. IP Fast-Reroute computes
the alternate next-hops to all IGP destinations, which include
alternate next-hops to the AS exit router's router-id. BGP simply
inherits the alternate next-hop from IGP. The BGP decision process
is unaltered; BGP continues to use the IGP optimal distance to find
the nearest exit router. MBGP routes do not need to copy the
alternate next hops.
It is possible to provide ASBR protection if BGP selected selected a 6.4. BGP Next-Hop Synchronization
set of IGP next-hops and allowed the IGP to determine the primary and
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
routes. BGP resolves its advertised next-hop to the immediate next-
hop by potential recursive lookups in the routing database. IP Fast-
Reroute computes the alternate next-hops to all IGP destinations,
which include alternate next-hops to the AS exit router's router-id.
BGP simply inherits the alternate next-hop from IGP. The BGP
decision process is unaltered; BGP continues to use the IGP optimal
distance to find the nearest exit router. MBGP routes do not need to
copy the alternate next hops.
It is possible to provide ASBR protection if BGP selected a set of
BGP next-hops and allowed the IGP to determine the primary and
alternate next-hops as if the BGP route were a multi-homed prefix. alternate next-hops as if the BGP route were a multi-homed prefix.
This is for future study. This is for future study.
6.4 Multicast Considerations 6.5. Multicast Considerations
Multicast traffic is out of scope for this specification of IP Fast- Multicast traffic is out of scope for this specification of IP Fast-
Reroute. The alternate next-hops SHOULD not be used for multi-cast Reroute. The alternate next-hops SHOULD NOT be used for multicast
RPF checks. RPF checks.
7. Security Considerations 7. Security Considerations
The mechanism described in this document does not modify any routing The mechanism described in this document does not modify any routing
protocol messages, and hence no new threats related to packet protocol messages, and hence no new threats related to packet
modifications or replay attacks are introduced. Traffic to certain modifications or replay attacks are introduced. Traffic to certain
destinations can be temporarily routed via next-hop routers that destinations can be temporarily routed via next-hop routers that
would not be used with the same topology change if this mechanism would not be used with the same topology change if this mechanism
wasn't employed. However, these next-hop routers can be used anyway wasn't employed. However, these next-hop routers can be used anyway
when a different topological change occurs, and hence this can't be when a different topological change occurs, and hence this can't be
viewed as a new security threat. viewed as a new security threat.
In LDP, the wider distribution of FEC label information is still to
neighbors with whom a trusted LDP session has been established. This
wider distribution and the recommendation of using liberal label
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. References
9.1 Normative References 9.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",
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.
9.2 Informative References 9.2. Informative References
[I-D.francois-ordered-fib]
Francois, P., "Loop-free convergence using oFIB",
draft-francois-ordered-fib-02 (work in progress),
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-01 (work in Attribute sub-TLV", draft-ietf-isis-link-attr-03 (work in
progress), May 2005. progress), February 2007.
[I-D.ietf-isis-wg-multi-topology]
Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in
IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in
progress), October 2005.
[I-D.ietf-ospf-mt]
Psenak, P., "Multi-Topology (MT) Routing in OSPF",
draft-ietf-ospf-mt-08 (work in progress), January 2007.
[I-D.ietf-ospf-mt-ospfv3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-01 (work in
progress), March 2006.
[I-D.ietf-ospf-ospfv3-update]
Ferguson, D., "OSPF for IPv6",
draft-ietf-ospf-ospfv3-update-14 (work in progress),
December 2006.
[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-05 (work in progress), draft-ietf-rtgwg-ipfrr-framework-06 (work in progress),
March 2006. October 2006.
[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.
[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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 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.
Appendix A. OSPF Example Where LFA Based on Local Area Topology is
Insufficient
This appendix provides an example scenario where the local area
topology does not suffice to determine that an LFA is available. As
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
there is at least one ABR or alternate ABR that is in both areas.
The following Figure 7 illustrates this case.
5
[ F ]-----------[ C ]
| |
| | 5
20 | 5 | 1
| [ N ]-----[ A ]*****[ F ]
| | # *
| 40 | # 50 * 2
| | 5 # 2 *
| [ S ]-----[ B ]*****[ G ]
| | *
| 5 | * 15
| | *
| [ E ] [ H ]
| | *
| 5 | * 10**
| | *
|---[ X ]-----[ASBR]
5
---- Link in Area 1
**** Link in Area 2
#### Link in Backbone Area 0
Figure 7: Topology with Multi-area ASBR Causing Area Transiting
In Figure 7, the ASBR is also an ABR and is announced into both area
1 and area 2. A and B are both ABRs that are also connected to the
backbone area. S determines that N can provide a loop-free alternate
to reach the ASBR. N's path goes via A. A also sees an intra-area
route to ASBR via Area 2; the cost of the path in area 2 is 30, which
is less than 35, the cost of the path in area 1. Therefore, A uses
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
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
that connects to S.
Authors' Addresses Authors' Addresses
Alia K. Atlas (editor) Alia K. Atlas (editor)
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: akatlas@alum.mit.edu 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
Email: zinin@psg.com Email: alex.zinin@alcatel.com
Raveendra Torvi Raveendra Torvi
Avici Systems, Inc. FutureWei Technologies Inc.
101 Billerica Avenue 1700 Alma Dr. Suite 100
N. Billerica, MA 01862 Plano, TX 75075
USA USA
Phone: +1 978 964 2026 Email: traveendra@huawei.com
Email: rtorvi@avici.com
Gagan Choudhury Gagan Choudhury
AT&T AT&T
200 Laurel Avenue, Room D5-3C21 200 Laurel Avenue, Room D5-3C21
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Phone: +1 732 420-3721 Phone: +1 732 420-3721
Email: gchoudhury@att.com Email: gchoudhury@att.com
Christian Martin Christian Martin
iPath Technologies iPath Technologies
Email: chris@ipath.net Email: chris@ipath.net
Brent Imhoff Brent Imhoff
Juniper Networks Juniper Networks
1194 North Mathilda 1194 North Mathilda
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Phone: +1 314 378 2571 Phone: +1 314 378 2571
Email: bimhoff@planetspork.com Email: bimhoff@planetspork.com
Don Fedyk Don Fedyk
skipping to change at page 24, line 27 skipping to change at page 28, line 5
Don Fedyk Don Fedyk
Nortel Networks Nortel Networks
600 Technology Park 600 Technology Park
Billerica, MA 01821 Billerica, MA 01821
USA USA
Phone: +1 978 288 3041 Phone: +1 978 288 3041
Email: dwfedyk@nortelnetworks.com Email: dwfedyk@nortelnetworks.com
Appendix A. OSPF Example Where LFA Based on Local Area Topology is Full Copyright Statement
Insufficient
This appendix provides an example scenario where the local area
topology does not suffice to determine that an LFA is available. As
described in Section 6.2, one problem scenario is for ASBR summaries
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.
The following Figure 7 illustrates this case.
5
[ F ]-----------[ C ]
| |
| | 5
20 | 5 | 1
| [ N ]-----[ A ]*****[ F ]
| | # *
| 40 | # 50 * 2
| | 5 # 2 *
| [ S ]-----[ B ]*****[ G ]
| | *
| 5 | * 15
| | *
| [ E ] [ H ]
| | *
| 5 | * 10**
| | *
|---[ X ]-----[ASBR]
5
---- Link in Area 1 Copyright (C) The IETF Trust (2007).
**** Link in Area 2
#### Link in Backbone Area 0
Figure 7: Topology with Multi-area ASBR Causing Area Transiting This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
In Figure 7, the ASBR is also an ABR and is announced into both area This document and the information contained herein are provided on an
1 and area 2. A and B are both ABRs that are also connected to the "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
backbone area. S determines that N can provide a loop-free alternate OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
to reach the ASBR. N's path goes via A. A also sees an intra-area THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
route to ASBR via Area 2; the cost of the path in area 2 is 30, which OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
is less than 35, the cost of the path in area 1. Therefore, A uses THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
the path from area 2 and directs traffic to F. The path from F in WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
path via area 2 (cost 25). Therefore, B uses the path from area 1
that connects to S.
Intellectual Property Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 26, line 29 skipping to change at page 28, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 88 change blocks. 
232 lines changed or deleted 315 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/