draft-ietf-rtgwg-ipfrr-spec-base-10.txt   draft-ietf-rtgwg-ipfrr-spec-base-11.txt 
Routing Area Working Group A. Atlas, Ed. Routing Area Working Group A. Atlas, Ed.
Internet-Draft BT Internet-Draft BT
Intended status: Standards Track A. Zinin, Ed. Intended status: Standards Track A. Zinin, Ed.
Expires: May 19, 2008 Alcatel Expires: August 27, 2008 Alcatel
Nov 16, 2007 Feb 24, 2008
Basic Specification for IP Fast-Reroute: Loop-free Alternates Basic Specification for IP Fast-Reroute: Loop-free Alternates
draft-ietf-rtgwg-ipfrr-spec-base-10 draft-ietf-rtgwg-ipfrr-spec-base-11
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 May 19, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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
packet loss that happens while routers converge after a topology packet loss that happens while routers converge after a topology
change due to a failure. Rapid failure repair is achieved through change due to a failure. Rapid failure repair is achieved through
use of precalculated backup next-hops that are loop-free and safe to use of precalculated backup next-hops that are loop-free and safe to
skipping to change at page 12, line 5 skipping to change at page 12, line 5
provide link protection. This requirement is described in provide link protection. This requirement is described in
Inequality 4 below. Inequality 4 below.
D_opt(N, D) < D_opt(N, PN) + D_opt(PN, D) D_opt(N, D) < D_opt(N, PN) + D_opt(PN, D)
Inequality 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. Because S reach the alternate neighbor N via the same pseudo-node. Since this
can direct the traffic away from the shortest path to use the is the only case for which a node-protecting LFA is not link-
alternate N, traffic might pass through the same broadcast link as it protecting, this implies that for point-to-point interfaces, an LFA
would when S sent the traffic to the primary E. Thus, an LFA from N that is node-protecting is always link-protecting. Because S can
that is node-protecting is not automatically link-protecting. direct the traffic away from the shortest path to use the 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 for a broadcast
or NBMA link.
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. To clarify, consider the protection during the alternate selection. To clarify, consider the
topology in Figure 3. For N to provide link-protection, it is first topology in Figure 3. For N to provide link-protection, it is first
necessary that N's shortest path to D does not traverse the pseudo- necessary that N's shortest path to D does not traverse the pseudo-
skipping to change at page 23, line 17 skipping to change at page 23, line 17
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
path to reach the prefix p is via E. The prefix p will have the link path to reach the prefix p is via E. The prefix p will have the link
to E as its primary next-hop. If the alternate next-hop for the to E as its primary next-hop. If the alternate next-hop for the
prefix p is simply inherited from the router advertising it on the prefix p is simply inherited from the router advertising it on the
shortest path to p, then the prefix p's alternate next-hop would be shortest path to p, then the prefix p's alternate next-hop would be
the link to C. This would provide link protection, but not the node the link to C. This would provide link protection, but not the node
protection that is possible via A. protection that is possible via A.
5 +---+ 4 +---+ 5 +---+ 5 +---+ 8 +---+ 5 +---+
------| S |------| A |-----| B | ------| S |------| A |-----| B |
| +---+ +---+ +---+ | +---+ +---+ +---+
| | | | | |
| 5 | 5 | | 5 | 5 |
| | | | | |
+---+ 5 +---+ 5 7 +---+ +---+ 5 +---+ 5 7 +---+
| C |---| E |------ p -------| F | | C |---| E |------ p -------| F |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 6: Multi-homed prefix Figure 6: Multi-homed prefix
skipping to change at page 27, line 7 skipping to change at page 27, line 7
IS-IS", draft-ietf-isis-wg-multi-topology-12 (work in IS-IS", draft-ietf-isis-wg-multi-topology-12 (work in
progress), November 2007. progress), November 2007.
[I-D.ietf-ospf-mt-ospfv3] [I-D.ietf-ospf-mt-ospfv3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in
progress), July 2007. progress), July 2007.
[I-D.ietf-ospf-ospfv3-update] [I-D.ietf-ospf-ospfv3-update]
Ferguson, D., "OSPF for IPv6", Ferguson, D., "OSPF for IPv6",
draft-ietf-ospf-ospfv3-update-17 (work in progress), draft-ietf-ospf-ospfv3-update-18 (work in progress),
August 2007. November 2007.
[I-D.ietf-rtgwg-ipfrr-framework] [I-D.ietf-rtgwg-ipfrr-framework]
Shand, M. and S. Bryant, "IP Fast Reroute Framework", Shand, M. and S. Bryant, "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-framework-07 (work in progress), draft-ietf-rtgwg-ipfrr-framework-07 (work in progress),
July 2007. July 2007.
[I-D.ietf-rtgwg-microloop-analysis] [I-D.ietf-rtgwg-microloop-analysis]
Zinin, A., "Analysis and Minimization of Microloops in Zinin, A., "Analysis and Minimization of Microloops in
Link-state Routing Protocols", Link-state Routing Protocols",
draft-ietf-rtgwg-microloop-analysis-01 (work in progress), draft-ietf-rtgwg-microloop-analysis-01 (work in progress),
skipping to change at page 31, line 7 skipping to change at page 31, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. 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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 8 change blocks. 
14 lines changed or deleted 18 lines changed or added

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