draft-ietf-rtgwg-ipfrr-framework-02.txt   draft-ietf-rtgwg-ipfrr-framework-03.txt 
Network Working Group M. Shand Network Working Group M. Shand
Internet Draft Internet Draft S. Bryant
Expiration Date: April 2005 Cisco Systems Expiration Date: December 2005 Cisco Systems
October 2004 June 2005
IP Fast Reroute Framework IP Fast Reroute Framework
draft-ietf-rtgwg-ipfrr-framework-02.txt draft-ietf-rtgwg-ipfrr-framework-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. 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
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete 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.
Abstract Abstract
skipping to change at page 7, line 19 skipping to change at page 7, line 19
1. Mechanisms where one or more alternate FIBs are pre-computed in 1. Mechanisms where one or more alternate FIBs are pre-computed in
all routers and the repaired packet is instructed to be all routers and the repaired packet is instructed to be
forwarded using a "repair FIB" by some method of signaling such forwarded using a "repair FIB" by some method of signaling such
as detecting a "U-turn" [U-TURNS] or marking the packet. as detecting a "U-turn" [U-TURNS] or marking the packet.
2. Mechanisms functionally equivalent to a loose source route which 2. Mechanisms functionally equivalent to a loose source route which
is invoked using the normal FIB. These include tunnels [TUNNELS] is invoked using the normal FIB. These include tunnels [TUNNELS]
and label based mechanisms. and label based mechanisms.
3. Mechanisms employing special addresses or labels which are
installed in the FIBs of all routers with routes pre-computed to
avoid certain components of the network. For example [NOT-VIA].
In many cases a repair path which reaches two hops away from the In many cases a repair path which reaches two hops away from the
router detecting the failure will suffice, and it is anticipated that router detecting the failure will suffice, and it is anticipated that
around 98% of failures (see section 3.2.2) can be repaired by this around 98% of failures (see section 3.2.2) can be repaired by this
method. However, to provide complete repair coverage some use of method. However, to provide complete repair coverage some use of
longer multi-hop repair paths is generally necessary. longer multi-hop repair paths is generally necessary.
3.2.1. Scope of repair paths 3.2.1. Scope of repair paths
A particular repair path may be valid for all destinations which A particular repair path may be valid for all destinations which
require repair or may only be valid for a subset of destinations. If require repair or may only be valid for a subset of destinations. If
skipping to change at page 7, line 47 skipping to change at page 7, line 51
the repair coverage can be determined and reported via network the repair coverage can be determined and reported via network
management. management.
There is a tradeoff to be achieved between minimizing the number of There is a tradeoff to be achieved between minimizing the number of
repair paths to be computed, and minimizing the overheads incurred in repair paths to be computed, and minimizing the overheads incurred in
using higher order multi-hop repair paths for destinations for which using higher order multi-hop repair paths for destinations for which
they are not strictly necessary. However, the computational cost of they are not strictly necessary. However, the computational cost of
determining repair paths on an individual destination basis can be determining repair paths on an individual destination basis can be
very high. very high.
It will frequently be the case that the majority of destinations can
be repaired using only the "basic" repair mechanism, leaving a
smaller subset of the destinations to be repaired using one of the
more complex multi-hop methods. Such a hybrid approach may go some
way to resolving the conflict between completeness and complexity.
The use of repair paths may result in excessive traffic passing over The use of repair paths may result in excessive traffic passing over
a link, resulting in congestion discard. This reduces the a link, resulting in congestion discard. This reduces the
effectiveness of IPFRR. Mechanisms to influence the distribution of effectiveness of IPFRR. Mechanisms to influence the distribution of
repaired traffic to minimize this effect are therefore desirable. repaired traffic to minimize this effect are therefore desirable.
3.2.2. Analysis of repair coverage 3.2.2. Analysis of repair coverage
In some cases the repair strategy will permit the repair of all In some cases the repair strategy will permit the repair of all
single link or node failures in the network for all possible single link or node failures in the network for all possible
destinations. This can be defined as 100% coverage. However, where destinations. This can be defined as 100% coverage. However, where
skipping to change at page 9, line 49 skipping to change at page 10, line 6
3.3. Mechanisms for micro-loop prevention 3.3. Mechanisms for micro-loop prevention
Control of micro-loops is important not only because they can cause Control of micro-loops is important not only because they can cause
packet loss in traffic which is affected by the failure, but because packet loss in traffic which is affected by the failure, but because
by saturating a link with looping packets they can also cause by saturating a link with looping packets they can also cause
congestion loss of traffic flowing over that link which would congestion loss of traffic flowing over that link which would
otherwise be unaffected by the failure. otherwise be unaffected by the failure.
A number of solutions to the problem of micro-loop formation have A number of solutions to the problem of micro-loop formation have
been proposed [MICROLOOP, ZININ]. The following factors are been proposed and are summarized in [MICROLOOP]. The following
significant in their classification: factors are significant in their classification:
1. Partial or complete protection against micro-loops. 1. Partial or complete protection against micro-loops.
2. Delay imposed upon convergence. 2. Delay imposed upon convergence.
3. Tolerance of multiple failures (from node failures, and in 3. Tolerance of multiple failures (from node failures, and in
general). general).
4. Computational complexity (pre-computed or real time). 4. Computational complexity (pre-computed or real time).
skipping to change at page 11, line 44 skipping to change at page 11, line 49
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.
9. Normative References 9. Acknowledgements
The authors would like to acknowledge contributions made by Alia
Atlas and Alex Zinin.
10. Normative References
Internet-drafts are works in progress available from Internet-drafts are works in progress available from
http://www.ietf.org/internet-drafts/ http://www.ietf.org/internet-drafts/
10. Informative References 11. Informative References
Internet-drafts are works in progress available from Internet-drafts are works in progress available from
http://www.ietf.org/internet-drafts/ http://www.ietf.org/internet-drafts/
BASE Atlas, A., "Basic Specification for IP BASE Atlas, A., "Basic Specification for IP
Fast-Reroute: Loop-free Alternates", Fast-Reroute: Loop-free Alternates",
draft-ietf-rtgwg-ipfrr-spec-base-01.txt, draft-ietf-rtgwg-ipfrr-spec-base-03.txt,
(work in progress) (work in progress)
BFD Katz, D. and Ward, D., "Bidirectional BFD Katz, D. and Ward, D., "Bidirectional
Forwarding Detection", Forwarding Detection",
draft-ietf-bfd-base-00.txt, (work in draft-ietf-bfd-base-02.txt, (work in
progress). progress).
MPLSFRR Pan, P. et al, "Fast Reroute Extensions to MPLSFRR Pan, P. et al, "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels", RSVP-TE for LSP Tunnels", RFC 4090.
draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt
MICROLOOP Bryant, S. and Shand, M., "A Framework for MICROLOOP Bryant, S. and Shand, M., "A Framework for
Loop-free Convergence", Loop-free Convergence",
draft-bryant-shand-lf-conv-frmwk-00.txt, draft-bryant-shand-lf-conv-frmwk-01.txt,
(work in progress). (work in progress).
NOT-VIA Bryant, S. and Shand, M., "IP Fast Reroute
Using Notvia Addresses",
draft-bryant-shand-ipfrr-notvia-addresses-
00.txt, (work in progress).
TUNNELS Bryant, S. et al, "IP Fast Reroute using TUNNELS Bryant, S. et al, "IP Fast Reroute using
tunnels", draft-bryant-ipfrr-tunnels-01.txt, tunnels", draft-bryant-ipfrr-tunnels-01.txt,
(work in progress). (work in progress).
U-TURNS Atlas, A. et al, "IP/LDP Local Protection", U-TURNS Atlas, A. et al, "IP/LDP Local Protection",
draft-atlas-ip-local-protect-01.txt, (work in draft-atlas-ip-local-protect-01.txt, (work in
progress). progress).
ZININ Zinin, A., "Analysis and Minimization of 12. Authors' Addresses
Microloops in Link-state Routing Protocols",
draft-zinin-microloop-analysis-00.txt, (work
in progress).
11. Author's Address Stewart Bryant
Cisco Systems,
250, Longwater,
Green Park,
Reading, RG2 6GB,
United Kingdom. Email: stbryant@cisco.com
Mike Shand Mike Shand
Cisco Systems, Cisco Systems,
250, Longwater Avenue, 250, Longwater Avenue,
Green Park, Green Park,
Reading, RG2 6GB, Reading, RG2 6GB,
United Kingdom. Email: mshand@cisco.com United Kingdom. Email: mshand@cisco.com
Full copyright statement Full copyright statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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