draft-ietf-rtgwg-microloop-analysis-00.txt   draft-ietf-rtgwg-microloop-analysis-01.txt 
Network Working Group Alex Zinin Network Working Group Alex Zinin
Internet Draft Alcatel Internet Draft Alcatel
Expiration Date: January 2006 July 2005 Expiration Date: June 2006 October 2005
File name: draft-ietf-rtgwg-microloop-analysis-00.txt File name: draft-ietf-rtgwg-microloop-analysis-01.txt
Analysis and Minimization of Microloops in Analysis and Minimization of Microloops in
Link-state Routing Protocols Link-state Routing Protocols
draft-ietf-rtgwg-microloop-analysis-00.txt draft-ietf-rtgwg-microloop-analysis-01.txt
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 other Task Force (IETF), its Areas, and its Working Groups. Note that other
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Similar microloops may form when other topological changes happen in Similar microloops may form when other topological changes happen in
the network, for example, when a new link or a node is added, a link the network, for example, when a new link or a node is added, a link
cost is changed, etc. In summary, whenever a topological change in cost is changed, etc. In summary, whenever a topological change in
the network results in changes of the shortest path three (SPT) for the network results in changes of the shortest path three (SPT) for
more than one node, it is possible for the network to exhibit more than one node, it is possible for the network to exhibit
temporary loops. temporary loops.
This document provides an analysis of microloop formation. This document provides an analysis of microloop formation.
Specifically, we categorize different types of reconvergence Specifically, we categorize different types of reconvergence
scenarios, and explore their properties. We then show that in certain scenarios, and explore their properties. We then show that in certain
scenaiors microloops do not form, in others they can be eliminated scenarios microloops do not form, in others they can be eliminated
using simple techniques described in this document, and define using simple techniques described in this document, and define
scenarios where more sophisticated loop avoidance mechanisms may be scenarios where more sophisticated loop avoidance mechanisms may be
necessary. necessary.
It is useful to understand the relationship between [IPFRR] and the
technique described here. The two mechanisms play complimentary roles
to each other: deploying [IPFRR] without micro-loop prevention only
partially addresses the goal of minimizing packet loss during network
reconvergence, since packets will be lost due to microloops. On the
other hand, micro-loop prevention described in this document relies
on [IPFRR] local failure protection, as routers will keep forwarding
traffic down the old path until the new next-hops are known to be
safe.
2 Analysis 2 Analysis
To analyse the behavior of a network during reconvergence, we look at To analyse the behavior of a network during reconvergence, we look at
a given router and its neighbors before failure and during the a given router and its neighbors before failure and during the
transition to the new routes. More specifically, we analyse whether transition to the new routes. More specifically, we analyse whether
switching to the new routing information can result in loop formation switching to the new routing information can result in loop formation
or not. or not.
2.1 Terminology 2.1 Terminology
The following terms are used in the draft. The following terms are used in the draft.
Dopt(X,Y)
Integer function defined as the cumulative cost of the least-
cost path from node X to node Y in a topology graph. Normally
calculated by link-state routing protocols using Dijkstra
algorithm as part of regular route calculation procedures.
This is the same as "Distance_opt(A,B)" defined in [IPFRR-FW]
Downstream neighbor Downstream neighbor
Neighbor N of router S is considered S's downstream neighbor Neighbor N of router S is considered S's downstream neighbor
for destination D, if Dopt(N, D) < Dopt(S, D) for destination D, if Dopt(N, D) < Dopt(S, D)
Primary neighbor Primary neighbor
Neighbor N of router S is considered S's primary neighbor for Neighbor N of router S is considered S's primary neighbor for
destination D, if N provides the shortest path to D according destination D, if the path via N is such that D(S, D) is mini-
to the SPF calculation. mized, i.e. N provides a shortest path to D according to the
SPF calculation.
Loop-free neighbor Loop-free neighbor
Neighbor N of router S is considered S's loop-free neighbor Neighbor N of router S is considered S's loop-free neighbor
for destination D, if Dopt(N, D) < Dopt(N, S) + Dopt(S, D). for destination D, if Dopt(N, D) < Dopt(N, S) + Dopt(S, D).
Note that a loop-free neighbor may be, for example, router's Note that a loop-free neighbor may be, for example, router's
primary before or after failure. primary before and/or after failure.
2.2 Next hop safety condition 2.2 Next hop safety condition
We start the analysis with the following observation: We start the analysis of single-hop loops with the following observa-
tion:
When router X learns about a topology change and starts using After a topology change, there are precisely two situations when a
neighbor Y as its new primary neighbor for a given destination, a microloop between routers X and Y can form:
microloop between X and Y can only form if the topology before
failure or topology after failure are such that Y uses X as its
primary neighbor for the same destination.
Indeed, if the topologies before and after failure are such that Y a) Before failure, X uses Y as its next-hop. After failure, Y
does not use X as it's next hop, then there is no moment in time uses X as its next-hop. Y updates its routes based on the new
before Y learned about the failure or after it learned about it topology before X.
when it would forward traffic to X. Hence, at least one of the two
topologies must be such that Y uses X as its next hop for a
microloop between X and Y to form.
Based on the above, we can define a safety condition for neighbor Y b) Exact opposite of the previous case. Before failure, Y uses X
of router X that has just learned about a topology change. Note that as its next-hop. After failure, X uses Y as its next-hop. X
the condition must satisfy the topological criteria above, and be updates its routes based on the new topology before Y.
non-recursive, i.e. not lead to loops if both X and Y follow it.
Formulating this for a given calculating router S (either X or Y in
the above example) switching to a new primary Pn, a microloop may
occur between S and Pn only if Pn was forwarding through S before
failure.
Based on the above, we can define a general safety condition for any
neighbor N (whether new primary or not) of router S that has just
learned about a topology change. Note that the condition must satisfy
the topological criteria above, and be non-recursive, i.e. not lead
to loops if both S and N follow it.
Next-hop safety condition: Next-hop safety condition:
For networks with symmetric link costs, after a topology After a topology change, it is safe for router S to switch to
change, it is safe for router X to switch to neigbor Y as its neigbor N as its next-hop for a specific destination if the
next-hop for a specific destination if the path through Y sat- path through N satisfies both of the following criteria:
isfies both of the following criteria:
1. X considered Y as its loop-free neighbor based on the 1. S considered N as its loop-free neighbor based on the
topology before change AND topology before change AND
2: X considers Y as its downstream neighbor based on the 2. S considers N as its downstream neighbor based on the
topology after change. topology after change.
The first requirement ensures that Y has not been forwarding The first requirement ensures that N has not been forwarding
traffic to X before the change occured and both X and Y used traffic to S before the change occured and both S and N used
old topology. The second requirement makes sure Y does not old topology. The second requirement makes sure N does not
forward traffic to X when Y learns the new topology. forward traffic to S when N learns the new topology. Note
again, that N is S's any neighbor, and may or may not be used
by S as its new primary or a temporary safe neighbor.
The difference in the conditions before and after failure is The difference in the conditions before and after failure is
there to make sure that X and Y do not recursively consider there to make sure that S and N do not recursively consider
each other as safe next-hops when they learn about the fail- each other as safe next-hops when they learn about the fail-
ure. ure.
For networks with asymmetric link costs, the safety condition is mod-
ified as follows:
Y is X's downstream neighbor based on the topology both before
AND after the change.
Whether a given router uses a the safety condition for symmetric or
assymetric link costs will affect micro-loop coverage. Generally, the
stricter condition for asymmetric link costs will result in poorer
coverage, however using the less strict (symmetric-link) condition in
networks with asymmetric link costs may result in transformation of
single-hop loops into multi-hop ones rather than their removal.
Routers SHOULD use the symmetric-link safety condition by default,
MAY attempt to dynamically determine the method that needs to be
applied based on the topological information from the routing
protocol, and SHOULD provide the administrator an opportunity to man-
ually override this setting.
2.3 Transition types 2.3 Transition types
Here, we analyse different types of scenarios that a given router may Here, we analyse different types of scenarios that a given router may
find itself in after learning about a topology change. find itself in after learning about a topology change.
For each topological change, the network will have three major types For each destination affected by a topological change, the network
of nodes categorized by the degree of safety of their old primary, will have three major types of nodes categorized by the degree of
new primary, and other neighbors. safety of their old primary, new primary, and other neighbors. (Note
that we do not yet consider ECMP, which will be discussed in section
3.2.)
Type A Type A
Routers whose new primary next-hops after the topology change Routers whose new primary next-hops after the topology change
are safe and transition to them will not create a microloop. are safe and transition to them will not create a microloop.
Two subtypes are recognized: Two subtypes are recognized:
A1: Routers whose primaries haven't changed as a result of A1: Routers whose primaries haven't changed as a result of
the topology change the topology change
skipping to change at page 5, line 40 skipping to change at page 6, line 5
do not satisfy the safety condition, but that have at least do not satisfy the safety condition, but that have at least
one other neighbor that does. Note that such a neighbor can be one other neighbor that does. Note that such a neighbor can be
the router's old primary (type B1) or a neighbor that is nei- the router's old primary (type B1) or a neighbor that is nei-
ther old nor new primary (type B2). ther old nor new primary (type B2).
Type C Type C
Routers that have no neighbor that satisfies the safety condi- Routers that have no neighbor that satisfies the safety condi-
tion. tion.
It is clear that type-A routers can immediately switch to their new It is clear that nothing special needs to be done for type-A routers
primary next hops once they are calculated after the topology change. as they either do not need to modify their routes or can immediately
switch to the new primary next hops.
It can also be shown that if type-B routers do not immediately switch It can also be shown that if type-B routers do not immediately switch
to their new primaries, but use their safe next-hops for some time, to their new primaries, but use their safe next-hops for some time,
switching to the new primaries later will not create loops, provided switching to the new primaries later will not create loops, provided
that their downstream routers have also switched to the safe hops or that their downstream routers have also switched to the safe hops or
have already switched to the new primaries. have already switched to the new primaries.
NOTE: The above analysis applies to single-hop loops. Multi-hop
loops, possible in networks with asymmetric link costs could be
prevented by using a tighter safety condition. However, as shown
by simulations on real-life network topologies, doing so would
decrease micro-loop coverage and thus result in increased number of
unprevented single-hop loops.
The following section formally defines the mechanism. The following section formally defines the mechanism.
3. Loop prevention mechanism 3. Loop prevention mechanism
3.1 Basic procedures 3.1 Basic procedures
The essense of the mechanism defined here, also known as "path lock-
ing via safe neighbors" (PLSN), can be informally summarized as fol-
lows. Upon a topology change, for each destination:
- Each router in the network assesses safety of its new primary
next-hops.
- If the new primaries are safe, they are used immediately, oth-
erwise, partial
ordering of updates is introduced:
o If non-primary safe neighbors are found, they are used
for a period of time, thus locking traffic to a safe path
while the new primaries complete their transition to the
new routes
o If no safe neighbors are found, the forwarding path is
locked on the old next-hop for some time to give the new
primary enough time to complete route updates.
For a description of several architectural constants used in this For a description of several architectural constants used in this
document (named as "DELAY_xxx"), refer to section 3.4. document (named as "DELAY_xxx"), refer to section 3.4.
On receiving a topology update, the router delays its SPF calculation On receiving a topology update, the router delays its SPF calculation
by DELAY_SPF time in order to collect the remaining updates that by DELAY_SPF time in order to collect the remaining updates that
relate to the same topological event (e.g. update from the router relate to the same topological event (e.g. update from the router
connected to the second end of a point-to-point link). connected to the second end of a point-to-point link in case of a
link failure, or updates from other neighbors of a failed node).
Upon expiration of DELAY_SPF, the router calculates the new SPT, the Upon expiration of DELAY_SPF, the router calculates the new SPT, the
new routes, checks the safety status of each neighbor using the con- new routes, checks the safety status of each neighbor relative to
ditions in section 3.1, and applies the following logic for each each affected destination using the conditions in section 3.1, and
route depending on the type of role it finds itself in: applies the following logic for each route depending on the type of
role it finds itself in:
Type A: Type A:
The route SHALL be updated with the new primary next-hops The route SHALL be updated with the new primary next-hops
without an additional delay. without an additional delay.
Type B: Type B:
Without an additional delay, the route SHALL be updated with The route SHALL be updated with one or more temporary next-
one or more temporary next-hops that satisfy the safety condi- hops that satisfy the safety condition without an additional
tion. These temporary next-hops SHALL be used for the duration delay. These temporary next-hops SHALL be used for the dura-
of DELAY_TYPEB. After DELAY_TYPEB, the route SHALL be updated tion of DELAY_TYPEB. After DELAY_TYPEB, the route SHALL be
with the new primary next-hops. updated with the new primary next-hops.
Type C: Type C:
The route's old (primary) next-hops SHALL continue to be used The route's old (primary) next-hops SHALL continue to be used
for DELAY_TYPEC. After DELAY_TYPEC, the route SHALL be for DELAY_TYPEC. After DELAY_TYPEC, the route SHALL be
updated with the new primary next-hops. updated with the new primary next-hops.
If, after expiration of DELAY_SPF, the router receives a topology If, after expiration of DELAY_SPF, the router receives a topology
update sooner than DELAY_STABLE after the previous one, the router update sooner than DELAY_STABLE after the previous one, the router
MUST fall back to the regular convergence mechanisms (immediate MUST fall back to the regular convergence mechanisms by prematurely
installation of the new primary next-hops) aborting any transition expiring DELAY_TYPEB or DELAY_TYPEC timers if they are still running
processes initiated as part of procedures described here (i.e., if (thus causing immediate installation of the new primary next-hops),
DELAY_TYPEB or DELAY_TYPEC timers are still running), MUST recalcu- MUST recalculate its routing table as soon as practical, and MUST
late its routing table as soon as practical, and MUST refrain from refrain from using the mechanisms described here until it has seen no
using the mechanisms described here until it has seen no topological topological updates for at least DELAY_STABLE. This is a safeguard
updates for at least DELAY_STABLE. This is a safeguard mechanism to mechanism to ensure that procedures described here are applied only
ensure that procedures described here are applied only when a single when a single failure is experienced and that the network converges
failure is experienced and that the network converges in a situation in a situation where multiple topological events or network instabil-
where multiple topological events or network instabilities are expe- ities are experienced.
rienced.
[ISIS] includes the concept of an Overload bit (OL) that indicates a
node in the network that shouldn't be used as transit. A similar
notion is introduced in OSPF by [STUB] using LSInfinity link costs.
Honoring these conventions, implementations of this document MUST NOT
use neighbors with the OL bit set in IS-IS or announcing links to the
calculating router with LSInfinity cost in OSPF as temporary safe
neighbors.
NOTE: In OSPF, if S's neighbor N is a stub router, the S->N link,
visited first by the SPF algorithm, will normally have a real link
cost, and it is the backwards link N->S announced by N that will
have its cost set to LSInfinity. Implementations have to account
for this details when satisfying the above requirement.
3.2 Equal Cost Multipath Considerations 3.2 Equal Cost Multipath Considerations
In situations where more than one primary next-hop is available after In situations where more than one primary next-hop is available after
the topology change, there are several possible combination of their the topology change, there are several possible combination of their
safety properties: safety properties:
1) All new next-hops satisfy the safery condition (a pure type-A 1) All new next-hops satisfy the safery condition (a pure type-A
situation) situation)
2) Some of the new next-hops satisfy the safety condition, some 2) Some of the new next-hops satisfy the safety condition, some
of them do not (a combination of type-A and type-B, or type-A of them do not (a combination of type-A and type-B)
and type-C)
3) None of the new next-hops satisfy the safety condition, how- 3) None of the new next-hops satisfy the safety condition, how-
ever, there's at least one other neighbor that satisfies it (a ever, there's at least one other neighbor that satisfies it (a
type-B situation) safe non-primary next-hop, causing new primaries to be type-B)
4) None of the new next-hops satisfy the safety condition, and 4) None of the new next-hops satisfy the safety condition, and
there is no other neighbor that satisfies it (a pure type-C there is no other neighbor that satisfies it (a pure type-C
situation). situation).
For situations 1, 3, and 4 above, the implementation merely follows For situations 1, 3, and 4 above, the implementation merely follows
the basic procedures described in section 3.1 the basic procedures described in section 3.1
For situation 2 (an A/B or an A/C combination), the implementation: For situation 2 (an A/B combination), the implementation:
1) SHALL update the route with the new next-hops that satisfy the 1) SHALL update the route with the new next-hops that satisfy the
safety condition without an additional delay safety condition without an additional delay
2) SHALL add the remaining new next-hops after DELAY_TYPEB. 2) SHALL add the remaining new next-hops after DELAY_TYPEB.
3.3 IP Fast Reroute Considerations Note that one could potentially use temporary safe neighbors in situ-
ation 2 above, however this specification does not recommend this to
avoid unnessesary traffic rerouting and hence packet reordering.
If the router implements [IPFRR] and performs local failure repair, 3.3 Local Failure and IP Fast Reroute Considerations
procedures describes in this document still need to be applied in
order to prevent micro-loops while reconverging on the new topology.
After initiating the local repair, the router directly attached to After detecting a local failure and initiating the local repair
the point of failure follows the procedures described in this docu- process if IPFRR is supported, the router directly attached to the
point of failure follows the procedures described in this docu-
ment--it delays its SPF calculation to collect updates from other ment--it delays its SPF calculation to collect updates from other
routers, calculates new routes, and classifies the next-hops. routers, calculates new routes, and classifies the next-hops.
The difference with routers that learn about the failure from the For routers implementing IPFRR, the difference with routers that
routing protocol updates, is that one or more of the repairing learn about the failure from the routing protocol updates, is that
router's old next-hops has become unavailable, and hence cannot be one or more of the repairing router's old next-hops has become
considered as the temporary safe next-hops for type-B operation. unavailable, and hence cannot be considered as the temporary safe
Also, if the router was able to locally repair the failure, and the next-hops for type-B operation. Also, if the router was able to
new primary next-hops do not satisfy the safety condition, the router locally repair the failure, and the new primary next-hops do not sat-
should consider itself in the middle of type-B operation with the isfy the safety condition, the router should consider itself in the
temporary safe neighbor engaged as part of IP Fast Reroute operation. middle of type-B operation with the temporary safe neighbor engaged
as part of IP Fast Reroute operation.
Another difference is when the router could not repair the failure, Another distinct situation is when the router does not support IPFRR
the new primary next-hops do not satisfy the safety condition, and or could not repair the failure, the new primary next-hops do not
there's no other neighbor that does, i.e. a type-C situation. Unlike satisfy the safety condition, and there's no other neighbor that
other routers in the network, the router directly connected to the does, i.e. a type-C situation. Unlike other routers in the network,
network does not have the old next-hop any more, and cannot continue the router directly connected to the network does not have the old
using it. In this situation, the router MUST revert to the regular next-hop any more, and cannot continue using it. Immediately switch-
convergence procedures, and update the route with the new next-hops ing to the new next-hops, on the other hand, may result in a micro-
with no additional delay. loop. In this situation, the router MUST discard traffic forwarded
along the affected route for the duration of DELAY_TYPEC, and then
update the routes. Implementations MAY have a configuration option to
allow switching immediately to the new next-hops for situations where
this type of a micro-loop is not a concern. If implemented, this
option MUST be disabled by default.
As a result, there are the following possible scenarios: As a result, there are the following possible scenarios:
1) If the new primary next-hops satisfy the safery condition, the 1) If the new primary next-hops satisfy the safery condition, the
router updates the routes without an additional delay. router updates the routes without an additional delay.
2) Otherwise, if the failure could be repaired locally by IP Fast 2) Otherwise, if the failure could be repaired locally by IP Fast
Reroute, the router continues to use the repair path for Reroute, the router continues to use the repair path for
DELAY_TYPEB and updates the routes with the new primary next- DELAY_TYPEB and updates the routes with the new primary next-
hops after it expires. hops after it expires.
3) Otherwise (new next-hops are not safe, and failure couldn't be 3) Otherwise (new next-hops are not safe, and IPFRR is not sup-
repaired), the router reverts to the regular procedures and ported or the failure couldn't be repaired), the router dis-
updates the route with new next-hops without an additional cards traffic for DELAY_TYPEC and updates the routes with the
delay. new primary next-hops after its expiration.
3.4 Architectural Constants 3.4 Architectural Constants
The following architectural constants have been used in the descrip- The following architectural constants have been used in the descrip-
tion of the algorithm above: tion of the algorithm above:
DELAY_SPF DELAY_SPF
The delay between the moment the router receives a topology The delay between the moment the router receives the first
update after a period of stability and the moment it starts topology update after a period of stability and the moment it
its routing table recalculation. This delay is necessary to starts its routing table recalculation. This delay is
collect multiple updates originated by different routers that necessary to collect multiple updates originated by different
relate to the same topological event. routers that relate to the same topological event.
DELAY_STABLE DELAY_STABLE
Period of time, during which the network topology is consid- Period of time, during which the network topology is consid-
ered to be stable if the router receives no topological ered to be stable if the router receives no topological
updates. When the first update after DELAY_STABLE is received, updates. When the first update after DELAY_STABLE is received,
all other updates that fit within DELAY_SPF are considered as all other updates that fit within DELAY_SPF are considered as
related to a single topological event. related to a single topological event.
DELAY_TYPEB and DELAY_TYPEC DELAY_TYPEB and DELAY_TYPEC
Periods of time used by the router to delay installation of Periods of time used by the router to delay installation of
skipping to change at page 10, line 25 skipping to change at page 11, line 34
The above algorithm minimizes the probability of loop formation. More The above algorithm minimizes the probability of loop formation. More
specifically, loops will only be possible when two neighboring specifically, loops will only be possible when two neighboring
routers both experience the type C condition after the topology routers both experience the type C condition after the topology
change. Appendix A shows that transitions between A-A, A-B, A-C, and change. Appendix A shows that transitions between A-A, A-B, A-C, and
B-C routers are loop-free. B-C routers are loop-free.
While this mechanism does not remove all possible micro-loops, it While this mechanism does not remove all possible micro-loops, it
addresses the majority of them in topologies with a reasonable level addresses the majority of them in topologies with a reasonable level
of physical redundancy. Topologically, micro-loop coverage provided of physical redundancy. Topologically, micro-loop coverage provided
by this algorithm is by this algorithm is very similar to that provided by [IPFRR]. This
is due to the fact that similar construct are used by both mecha-
nisms.
5 Security Considerations 5 Backwards Compatibility Analysis
Effectiveness of the mechanism described here relies on the assump-
tion that all routers in the network support it.
In a situation where some routers do not support the describer mecha-
nism, the network will continue to converge properly fundamentals of
the routing system are not changed. When a topology change event
occurs in such a network, Type-A and Type-B routers will not substan-
tially change the convergence patterns, as they will switch to
routers that are guaranteed to forward traffic correctly after
DELAY_SPF. (Note that routers today already implement a delay
similar to DELAY_SPF.) Type-C routers, when mixed with routers not
supporting this mechanism, may induce longer than usual micro-loops
(up to DELAY_TYPEC), however this delay is in the same order of mag-
nitude as in most deployed networks today.
6 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 modifi- protocol messages, and hence no new threats related to packet modifi-
cations or replay attacks are introduced. The mechanism changes cer- cations or replay attacks are introduced. The mechanism changes cer-
tain delays used in node-local algorithms and introduces partial tain delays used in node-local algorithms and introduces partial
event ordering after a topology change has occured. This, however, event ordering after a topology change has occured. This, however,
does not introduce new security risks. For type-B situations, traffic does not introduce new security risks. For type-B situations, traffic
to certain destinations can be temporarily routed via next-hop to certain destinations can be temporarily routed via next-hop
routers that would not be used with the same topology change if this routers that would not be used with the same topology change if this
mechanism wasn't employed. However, these next-hop routers can be mechanism wasn't employed. However, these next-hop routers can be
used anyway when a different topological change occurs, and hence used anyway when a different topological change occurs, and hence
this can't be viewed as a new security threat. this can't be viewed as a new security threat.
Acknowledgements 7 Acknowledgements
The author would like to thank Don Fedyk, Chris Martin, Mike Shand, The author would like to thank Don Fedyk, Chris Martin, Alex Audu,
Alex Audu, Olivier Bonaventure, Stefano Previdi, and other members of Olivier Bonaventure, Stefano Previdi, and other members of the IETF
the IETF RTGWG for their useful comments. Special thanks go to Alia RTGWG for their useful comments. Special thanks go to Alia Atlas,
Atlas who, among other things, was instrumental in fine-tuning the Mike Shand, and Steward Bryant, who were instrumental in development
safety condition. of this mechanism, such as fine-tuning the safety condition, simulat-
ing the mechanism, proof-reading the document, and without whom this
work wouldn't be possible.
8 References
8.1 Normative References
References
[OSPF] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet [OSPF] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet
Engineering Task Force, 1998. Engineering Task Force, 1998.
[ISIS] ISO, "Intermediate system to Intermediate system routeing [ISIS] ISO, "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with the information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service Protocol for providing the Connectionless-mode Network Service
(ISO 8473)," ISO/IEC 10589:1992. (ISO 8473)," ISO/IEC 10589:1992.
[IPFRR] Atlas, A., "Basic Specification for IP Fast-Reroute: [IPFRR] Atlas, A., "Basic Specification for IP Fast-Reroute:
Loop-free Alternates", Internet Engineering Task Force, Work Loop-free Alternates", Internet Engineering Task Force, Work
in Progress, draft-ietf-rtgwg-ipfrr-spec-base-03.txt in Progress, draft-ietf-rtgwg-ipfrr-spec-base-03.txt
8.2 Informative References
[IPFRR-FW] Shand, M., S. Bryant, "IP Fast Reroute Framework",
Internet Engineering Task Force, Work in Progress, draft-ietf-
rtgwg-ipfrr-framework-04.txt
[STUB] Retana, A., et al, OSPF Stub Router Advertisement, RFC 3137,
Internet Engineering Task Force, 2001.
Author's Address Author's Address
Alex Zinin Alex Zinin
Alcatel Alcatel
701 E Middlefield Rd 701 E Middlefield Rd
Mountain View, CA 94043 Mountain View, CA 94043
E-mail: zinin@psg.com E-mail: zinin@psg.com
Appendix A. Loop formation analysis Appendix A. Loop formation analysis
 End of changes. 42 change blocks. 
122 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/