draft-ietf-rtgwg-ipfrr-notvia-addresses-06.txt   draft-ietf-rtgwg-ipfrr-notvia-addresses-07.txt 
Network Working Group M. Shand Network Working Group M. Shand
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Experimental S. Previdi Intended status: Experimental S. Previdi
Expires: April 24, 2011 Cisco Systems Expires: October 22, 2011 Cisco Systems
October 21, 2010 April 20, 2011
IP Fast Reroute Using Not-via Addresses IP Fast Reroute Using Not-via Addresses
draft-ietf-rtgwg-ipfrr-notvia-addresses-06 draft-ietf-rtgwg-ipfrr-notvia-addresses-07
Abstract Abstract
This draft describes a mechanism that provides fast reroute in an IP This draft describes a mechanism that provides fast reroute in an IP
network through encapsulation to "not-via" addresses. A single level network through encapsulation to "not-via" addresses. A single level
of encapsulation is used. The mechanism protects unicast, multicast of encapsulation is used. The mechanism protects unicast, multicast
and LDP traffic against link, router and shared risk group failure, and LDP traffic against link, router and shared risk group failure,
regardless of network topology and metrics. regardless of network topology and metrics.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 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."
This Internet-Draft will expire on April 24, 2011. This Internet-Draft will expire on October 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Not-via Repairs . . . . . . . . . . . . . . . . . 4 2. Overview of Not-via Repairs . . . . . . . . . . . . . . . . . 3
2.1. Use of Equal Cost Multi-Path . . . . . . . . . . . . . . . 6 2.1. Use of Equal Cost Multi-Path . . . . . . . . . . . . . . . 4
2.2. Use of LFA repairs . . . . . . . . . . . . . . . . . . . . 6 2.2. Use of LFA repairs . . . . . . . . . . . . . . . . . . . . 4
3. Not-via Repair Path Computation . . . . . . . . . . . . . . . 6 3. Not-via Repair Path Computation . . . . . . . . . . . . . . . 5
3.1. Computing not-via repairs in routing vector protocols . . 7 3.1. Computing not-via repairs in routing vector protocols . . 6
4. Operation of Repairs . . . . . . . . . . . . . . . . . . . . . 8 4. Operation of Repairs . . . . . . . . . . . . . . . . . . . . . 6
4.1. Node Failure . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Node Failure . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Link Failure . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Link Failure . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Loop Prevention Under Node Failure . . . . . . . . . . 9 4.2.1. Loop Prevention Under Node Failure . . . . . . . . . . 7
4.3. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . . 9 4.3. Multi-homed Prefixes . . . . . . . . . . . . . . . . . . . 7
4.4. Installation of Repair Paths . . . . . . . . . . . . . . . 10 4.4. Installation of Repair Paths . . . . . . . . . . . . . . . 9
5. Compound Failures . . . . . . . . . . . . . . . . . . . . . . 12 5. Compound Failures . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Shared Risk Link Groups . . . . . . . . . . . . . . . . . 12 5.1. Shared Risk Link Groups . . . . . . . . . . . . . . . . . 10
5.1.1. Use of LFAs with SRLGs . . . . . . . . . . . . . . . . 16 5.1.1. Use of LFAs with SRLGs . . . . . . . . . . . . . . . . 14
5.2. Local Area Networks . . . . . . . . . . . . . . . . . . . 16 5.2. Local Area Networks . . . . . . . . . . . . . . . . . . . 14
5.2.1. Simple LAN Repair . . . . . . . . . . . . . . . . . . 17 5.2.1. Simple LAN Repair . . . . . . . . . . . . . . . . . . 15
5.2.2. LAN Component Repair . . . . . . . . . . . . . . . . . 18 5.2.2. LAN Component Repair . . . . . . . . . . . . . . . . . 16
5.2.3. LAN Repair Using Diagnostics . . . . . . . . . . . . . 19 5.2.3. LAN Repair Using Diagnostics . . . . . . . . . . . . . 17
5.3. Multiple Independent Failures . . . . . . . . . . . . . . 19 5.3. Multiple Independent Failures . . . . . . . . . . . . . . 17
5.3.1. Looping Repairs . . . . . . . . . . . . . . . . . . . 20 5.3.1. Looping Repairs . . . . . . . . . . . . . . . . . . . 18
5.3.2. Outline Solution . . . . . . . . . . . . . . . . . . . 21 5.3.2. Outline Solution . . . . . . . . . . . . . . . . . . . 19
5.3.3. Looping Repairs . . . . . . . . . . . . . . . . . . . 22 5.3.3. Looping Repairs . . . . . . . . . . . . . . . . . . . 20
5.3.3.1. Dropping Looping Packets . . . . . . . . . . . . . 22 5.3.3.1. Dropping Looping Packets . . . . . . . . . . . . . 20
5.3.3.2. Computing non-looping Repairs of Repairs . . . . . 23 5.3.3.2. Computing non-looping Repairs of Repairs . . . . . 21
5.3.3.3. N-level Mutual Loops . . . . . . . . . . . . . . . 25 5.3.4. Mixing LFAs and Not-via . . . . . . . . . . . . . . . 23
5.3.4. Mixing LFAs and Not-via . . . . . . . . . . . . . . . 25 6. Optimizing not-via computations using LFAs . . . . . . . . . . 24
6. Optimizing not-via computations using LFAs . . . . . . . . . . 26 7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Fast Reroute in an MPLS LDP Network. . . . . . . . . . . . . . 25
8. Fast Reroute in an MPLS LDP Network. . . . . . . . . . . . . . 27 9. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Routing Extensions . . . . . . . . . . . . . . . . . . . . . . 26
10. Routing Extensions . . . . . . . . . . . . . . . . . . . . . . 28 11. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 26
11. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 28 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13. Security Considerations . . . . . . . . . . . . . . . . . . . 29 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 15. Informative References . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . . 29
15.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
When a link or a router fails, only the neighbors of the failure are When a link or a router fails, only the neighbors of the failure are
initially aware that the failure has occurred. In a network initially aware that the failure has occurred. In a network
operating IP fast reroute [RFC5714], the routers that are the operating IP fast reroute [RFC5714], the routers that are the
neighbors of the failure repair the failure. These repairing routers neighbors of the failure repair the failure. These repairing routers
have to steer packets to their destinations despite the fact that have to steer packets to their destinations despite the fact that
most other routers in the network are unaware of the nature and most other routers in the network are unaware of the nature and
location of the failure. location of the failure.
skipping to change at page 4, line 26 skipping to change at page 3, line 26
indicate the identity of the failure and to explicitly steer the indicate the identity of the failure and to explicitly steer the
repaired packet round the failure. The extent to which this repaired packet round the failure. The extent to which this
limitation affects the repair coverage is topology dependent. The limitation affects the repair coverage is topology dependent. The
mechanism proposed here is to encapsulate the packet to an address mechanism proposed here is to encapsulate the packet to an address
that explicitly identifies the network component that the repair must that explicitly identifies the network component that the repair must
avoid. This produces a repair mechanism, which, provided the network avoid. This produces a repair mechanism, which, provided the network
is not partitioned by the failure, will always achieve a repair. is not partitioned by the failure, will always achieve a repair.
2. Overview of Not-via Repairs 2. Overview of Not-via Repairs
When a link or a router fails, only the neighbors of the failure are This section provides a brief overview of the not-via method of
initially aware that the failure has occurred. In a network IPFRR.
operating IP fast reroute [RFC5714], the routers that are the
neighbors of the failure repair the failure. These repairing routers
have to steer packets to their destinations despite the fact that
most other routers in the network are unaware of the nature and
location of the failure.
A common limitation in most IPFRR mechanisms is an inability to
indicate the identity of the failure and to explicitly steer the
repaired packet round the failure. The extent to which this
limitation affects the repair coverage is topology dependent. The
mechanism proposed here is to encapsulate the packet to an address
that explicitly identifies the network component that the repair must
avoid. This produces a repair mechanism, which, provided the network
is not partitioned by the failure, will always achieve a repair.
A A
| Bp is the address to use to get | Bp is the address to use to get
| a packet to B not-via P | a packet to B not-via P
| |
S----------P----------B. . . . . . . . . .D S----------P----------B. . . . . . . . . .D
\ | Bp^ \ | Bp^
\ | | \ | |
\ | | \ | |
\ C | \ C |
skipping to change at page 6, line 22 skipping to change at page 4, line 33
Cp| Cp|
C C
Figure 2: The set of Not-via P Addresses Figure 2: The set of Not-via P Addresses
2.1. Use of Equal Cost Multi-Path 2.1. Use of Equal Cost Multi-Path
A router can use an equal cost multi-path (ECMP) repair in place of a A router can use an equal cost multi-path (ECMP) repair in place of a
not-via repair. not-via repair.
A router computing a not-via repair path MAY subject the repair to A router computing a not-via repair path may subject the repair to
ECMP. ECMP.
2.2. Use of LFA repairs 2.2. Use of LFA repairs
The not-via approach provides complete repair coverage and therefore The not-via approach provides complete repair coverage and therefore
may be used as the sole repair mechanism. There are, however, may be used as the sole repair mechanism. There are, however,
advantages in using not-via in combination with loop free alternates advantages in using not-via in combination with loop free alternates
(LFA) and or downstream paths as documented in [RFC5286]. (LFA) and or downstream paths as documented in [RFC5286].
LFAs are computed on a per destination basis and in general, only a LFAs are computed on a per destination basis and in general, only a
skipping to change at page 6, line 49 skipping to change at page 5, line 12
that of the equivalent not-via repair for traffic destined to nodes that of the equivalent not-via repair for traffic destined to nodes
close to the far end of the failure, but may be more optimal for some close to the far end of the failure, but may be more optimal for some
other traffic. The description in this document assumes that LFAs other traffic. The description in this document assumes that LFAs
will be used where available, but the distribution of repairs between will be used where available, but the distribution of repairs between
the two mechanisms is a local implementation choice. the two mechanisms is a local implementation choice.
3. Not-via Repair Path Computation 3. Not-via Repair Path Computation
The not-via repair mechanism requires that all routers on the path The not-via repair mechanism requires that all routers on the path
from S to B (Figure 1) have a route to Bp. They can calculate this from S to B (Figure 1) have a route to Bp. They can calculate this
by failing node P, running an SPF, and finding the shortest route to by failing node P, running a Shortest Path First Algorithm (SPF), and
B. finding the shortest route to B.
A router has no simple way of knowing whether it is on the shortest A router has no simple way of knowing whether it is on the shortest
path for any particular repair. It is therefore necessary for every path for any particular repair. It is therefore necessary for every
router to calculate the path it would use in the event of any router to calculate the path it would use in the event of any
possible router failure. Each router therefore "fails" every router possible router failure. Each router therefore "fails" every router
in the network, one at a time, and calculates its own best route to in the network, one at a time, and calculates its own best route to
each of the neighbors of that router. In other words, with reference each of the neighbors of that router. In other words, with reference
to Figure 1, some router X will consider each router in turn to be P, to Figure 1, some router X will consider each router in turn to be P,
fail P, and then calculate its own route to each of the not-via P fail P, and then calculate its own route to each of the not-via P
addresses advertised by the neighbors of P. i.e. X calculates its addresses advertised by the neighbors of P. i.e. X calculates its
skipping to change at page 7, line 27 skipping to change at page 5, line 37
where n is the number of routers in the network. This is expensive where n is the number of routers in the network. This is expensive
to compute. However, the problem is amenable to a solution in which to compute. However, the problem is amenable to a solution in which
each router (X) proceeds as follows. X first calculates the base each router (X) proceeds as follows. X first calculates the base
topology with all routers functional and determines its normal path topology with all routers functional and determines its normal path
to all not-via addresses. This can be performed as part of the to all not-via addresses. This can be performed as part of the
normal SPF computation. For each router P in the topology, X then normal SPF computation. For each router P in the topology, X then
performs the following actions:- performs the following actions:-
1. Removes router P from the topology. 1. Removes router P from the topology.
2. Performs an incremental SPF [ISPF] on the modified topology. The 2. Performs an incremental SPF (iSPF) [ISPF] on the modified
iSPF process involves detaching the sub-tree affected by the topology. The iSPF process involves detaching the sub-tree
removal of router P, and then re-attaching the detached nodes. affected by the removal of router P, and then re-attaching the
However, it is not necessary to run the iSPF to completion. It detached nodes. However, it is not necessary to run the iSPF to
is sufficient to run the iSPF up to the point where all of the completion. It is sufficient to run the iSPF up to the point
nodes advertising not-via P addresses have been re-attached to where all of the nodes advertising not-via P addresses have been
the SPT, and then terminate it. re-attached to the SPT, and then terminate it.
3. Reverts to the base topology. 3. Reverts to the base topology.
This algorithm is significantly less expensive than a set of full This algorithm is significantly less expensive than a set of full
SPFs. Thus, although a router has to calculate the repair paths for SPFs. Thus, although a router has to calculate the repair paths for
n-1 failures, the computational effort is much less than n-1 SPFs. n-1 failures, the computational effort is much less than n-1 SPFs.
Experiments on a selection of real world network topologies with Experiments on a selection of real world network topologies with
between 40 and 400 nodes suggest that the worst-case computational between 40 and 400 nodes suggest that the worst-case computational
complexity using the above optimizations is equivalent to performing complexity using the above optimizations is equivalent to performing
skipping to change at page 16, line 24 skipping to change at page 14, line 24
2. Modifying the design of the network to avoid this possibility. 2. Modifying the design of the network to avoid this possibility.
3. Using some form of SRLG diagnostic (for example, by running BFD 3. Using some form of SRLG diagnostic (for example, by running BFD
over alternate repair paths) to determine which SRLG member(s) over alternate repair paths) to determine which SRLG member(s)
has actually failed and using this information to select an has actually failed and using this information to select an
appropriate pre-computed repair path. However, aside from the appropriate pre-computed repair path. However, aside from the
complexity of performing the diagnostics, this requires multiple complexity of performing the diagnostics, this requires multiple
not-via addresses per interface, which has poor scaling not-via addresses per interface, which has poor scaling
properties. properties.
4. Using the machanism described in Section 5.3 4. Using the mechanism described in Section 5.3
5.1.1. Use of LFAs with SRLGs 5.1.1. Use of LFAs with SRLGs
Section 4.1 above describes the repair of links which are members of Section 4.1 above describes the repair of links which are members of
one or more SRLGs. LFAs can be used for the repair of such links one or more SRLGs. LFAs can be used for the repair of such links
provided that any other link with which S-P shares an SRLG is avoided provided that any other link with which S-P shares an SRLG is avoided
when computing the LFA. This is described for the simple case of when computing the LFA. This is described for the simple case of
"local-SRLGs" in [RFC5286]. "local-SRLGs" in [RFC5286].
5.2. Local Area Networks 5.2. Local Area Networks
skipping to change at page 22, line 33 skipping to change at page 20, line 33
5.3.3. Looping Repairs 5.3.3. Looping Repairs
In case 3, the simplest approach is to simply not install repairs for In case 3, the simplest approach is to simply not install repairs for
repair paths that might loop. In this case, although the potentially repair paths that might loop. In this case, although the potentially
looping traffic is dropped, the traffic is not repaired. If we looping traffic is dropped, the traffic is not repaired. If we
assume that a hold-down is applied before reconvergence in case the assume that a hold-down is applied before reconvergence in case the
link failure was just a short glitch, and if a loop free convergence link failure was just a short glitch, and if a loop free convergence
mechanism further delays convergence, then the traffic will be mechanism further delays convergence, then the traffic will be
dropped for an extended period. In these circumstances it would be dropped for an extended period. In these circumstances it would be
better to "abandon all hope" (AAH) better to "abandon all hope" (AAH) [I-D.ietf-rtgwg-ordered-fib]
[<draft-bryant-francois-shand-ipfrr-aah-00.txt>] and immediately (Appendix A) and immediately invoke normal re-convergence.
invoke normal re-convergence.
Note that it is not sufficient to expedite the issuance of an LSP Note that it is not sufficient to expedite the issuance of an LSP
reporting the failure, since this may be treated as a permitted reporting the failure, since this may be treated as a permitted
simultaneous failure by the oFIB algorithm. It is therefore simultaneous failure by the ordered FIB (oFIB) algorithm
necessary to explicitly trigger an oFIB AAH. [I-D.ietf-rtgwg-ordered-fib]. It is therefore necessary to
explicitly trigger an oFIB AAH.
5.3.3.1. Dropping Looping Packets 5.3.3.1. Dropping Looping Packets
One approach to case 3 is to allow the repair, and to experimentally One approach to case 3 is to allow the repair, and to experimentally
discover the incompatibility of the repairs if and when they occur. discover the incompatibility of the repairs if and when they occur.
With this method we permit the repair in case 3 and trigger AAH when With this method we permit the repair in case 3 and trigger AAH when
a packet drop count on the not-via address has been incremented. a packet drop count on the not-via address has been incremented.
Alternatively, it is possible to wait until the LSP describing the Alternatively, it is possible to wait until the LSP describing the
change is issued normally (i.e. when X announces the failure of X-Y). change is issued normally (i.e. when X announces the failure of X-Y).
When the repairing node A, which has precomputed that X-Y failures When the repairing node A, which has precomputed that X-Y failures
are mutually incompatible with its own repairs receives this LSP it are mutually incompatible with its own repairs receives this LSP it
can then issue the AAH. This has the disadvantage that it doesn't can then issue the AAH. This has the disadvantage that it does not
overcome the hold-down delay, but it requires no "data-driven" overcome the hold-down delay, but it requires no "data-driven"
operation, and it still has the required effect of abandoning the operation, and it still has the required effect of abandoning the
oFIB which is probably the longer of the delays (although with oFIB which is probably the longer of the delays (although with
signalled oFIB this should be sub-second). signalled oFIB this should be sub-second).
Whilst both of the experimental approaches described above are Whilst both of the experimental approaches described above are
feasible, they tend to induce AAH in the presence of otherwise feasible, they tend to induce AAH in the presence of otherwise
feasible repairs, and they are contrary to the philosophy of repair feasible repairs, and they are contrary to the philosophy of repair
pre-determination that has been applied to existing IPFRR solutions. pre-determination that has been applied to existing IPFRR solutions.
skipping to change at page 25, line 5 skipping to change at page 23, line 5
connected. In these cases, repair is clearly impossible - the connected. In these cases, repair is clearly impossible - the
failure of both links partitions the network. It would be failure of both links partitions the network. It would be
advantageous to be able to identify these cases, and inhibit the advantageous to be able to identify these cases, and inhibit the
fruitless advertisement of the secondary SRLG information. This fruitless advertisement of the secondary SRLG information. This
could be achieved by the node detecting the requirement for a could be achieved by the node detecting the requirement for a
secondary SRLG, first running the not-via computation with both links secondary SRLG, first running the not-via computation with both links
removed. If this does not result in a path, it is clear that the removed. If this does not result in a path, it is clear that the
network would be partitioned by such a failure, and so no network would be partitioned by such a failure, and so no
advertisement is required. advertisement is required.
5.3.3.3. N-level Mutual Loops
[Editors' Note: This section needs to be reviewed before final
publication]
It is tempting to conclude that the mechanism described above can be
applied to the general case of N failures. If we use the approach of
assuming that repairs are not mutual, and catching the loops and
executing AAH when they occur, then we can attempt repairs in the
case of N failures.
If we use the approach of avoiding potentially mutual repairs and
creating secondary SRLG, then we have to explore N levels of repair,
where N is the number of simultaneous failures we wish to repair.
5.3.4. Mixing LFAs and Not-via 5.3.4. Mixing LFAs and Not-via
So far in this section we have assumed that all repairs use not-via So far in this section we have assumed that all repairs use not-via
tunnels. However, in practise we may wish to use LFAs or downstream tunnels. However, in practise we may wish to use LFAs or downstream
routes where available. This complicates the issue, because their routes where available. This complicates the issue, because their
use results in packets which are being repaired, but NOT addressed to use results in packets which are being repaired, but NOT addressed to
not-via addresses. If BOTH links are using downstream routes there not-via addresses. If BOTH links are using downstream routes there
is no possibility of looping, since it is impossible to have a pair is no possibility of looping, since it is impossible to have a pair
of nodes which are both downstream of each other [RFC5286]. of nodes which are both downstream of each other [RFC5286].
skipping to change at page 26, line 26 skipping to change at page 24, line 11
encapsulated packets may result in an undetected loop. If it is encapsulated packets may result in an undetected loop. If it is
computationally feasible to check the downstream route in this computationally feasible to check the downstream route in this
topology (i.e. for any not-via address Qp which traverses A-B we must topology (i.e. for any not-via address Qp which traverses A-B we must
perform the downstream calculation for that not-via address in the perform the downstream calculation for that not-via address in the
topology with link Q-P failed.), then the downstream repair for Yx topology with link Q-P failed.), then the downstream repair for Yx
can safely be used. These packets cannot re-visit X-Y, since by can safely be used. These packets cannot re-visit X-Y, since by
definition they will avoid that link. Alternatively, the packet definition they will avoid that link. Alternatively, the packet
could be always repaired in a not-via tunnel. i.e. even though the could be always repaired in a not-via tunnel. i.e. even though the
normal repair for traffic traversing A-B would be to use a downstream normal repair for traffic traversing A-B would be to use a downstream
route, we could insist that such traffic addressed to a not-via route, we could insist that such traffic addressed to a not-via
address MUST use a tunnel to Ba. Such a tunnel would only be address must use a tunnel to Ba. Such a tunnel would only be
installed for an address Qp if it were established that it did not installed for an address Qp if it were established that it did not
traverse Q-P (using the rules described above). traverse Q-P (using the rules described above).
6. Optimizing not-via computations using LFAs 6. Optimizing not-via computations using LFAs
If repairing node S has an LFA to the repair endpoint it is not If repairing node S has an LFA to the repair endpoint it is not
necessary for any router to perform the incremental SPF with the link necessary for any router to perform the incremental SPF with the link
SP removed in order to compute the route to the not-via address Ps. SP removed in order to compute the route to the not-via address Ps.
This is because the correct routes will already have been computed as This is because the correct routes will already have been computed as
a result of the SPF on the base topology. Node S can signal this a result of the SPF on the base topology. Node S can signal this
skipping to change at page 29, line 16 skipping to change at page 26, line 47
12. IANA Considerations 12. IANA Considerations
There are no IANA considerations that arise from this draft. There are no IANA considerations that arise from this draft.
13. Security Considerations 13. Security Considerations
The repair endpoints present vulnerability in that they might be used The repair endpoints present vulnerability in that they might be used
as a method of disguising the delivery of a packet to a point in the as a method of disguising the delivery of a packet to a point in the
network. The primary method of protection should be through the use network. The primary method of protection should be through the use
of a private address space for the not-via addresses. These of a private address space for the not-via addresses. These
addresses MUST NOT be advertised outside the area, and SHOULD be addresses must not be advertised outside the area, and should be
filtered at the network entry points. In addition, a mechanism might filtered at the network entry points. In addition, a mechanism might
be developed that allowed the use of the mild security available be developed that allowed the use of the mild security available
through the use of a key [RFC1701] [RFC3931]. With the deployment of through the use of a key [RFC1701] [RFC3931]. With the deployment of
such mechanisms, the repair endpoints would not increase the security such mechanisms, the repair endpoints would not increase the security
risk beyond that of existing IP tunnel mechanisms. An attacker may risk beyond that of existing IP tunnel mechanisms. An attacker may
attempt to overload a router by addressing an excessive traffic load attempt to overload a router by addressing an excessive traffic load
to the de-capsulation endpoint. Typically, routers take a 50% to the de-capsulation endpoint. Typically, routers take a 50%
performance penalty in decapsulating a packet. The attacker could performance penalty in decapsulating a packet. The attacker could
not be certain that the router would be impacted, and the extremely not be certain that the router would be impacted, and the extremely
high volume of traffic needed, would easily be detected as an high volume of traffic needed, would easily be detected as an
skipping to change at page 29, line 38 skipping to change at page 27, line 25
link, they could cause the network to invoke the not-via repair link, they could cause the network to invoke the not-via repair
mechanism. A network protected by not-via IPFRR is less vulnerable mechanism. A network protected by not-via IPFRR is less vulnerable
to such an attack than a network that undertook a full convergence in to such an attack than a network that undertook a full convergence in
response to a link up/down event. response to a link up/down event.
14. Acknowledgements 14. Acknowledgements
The authors would like to acknowledge contributions made by Alia The authors would like to acknowledge contributions made by Alia
Atlas and John Harper. Atlas and John Harper.
15. References 15. Informative References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References [I-D.ietf-rtgwg-ordered-fib]
Shand, M., Bryant, S., Previdi, S., and C. Filsfils,
"Loop-free convergence using oFIB",
draft-ietf-rtgwg-ordered-fib-05 (work in progress),
April 2011.
[I-D.shen-mpls-ldp-nnhop-label] [I-D.shen-mpls-ldp-nnhop-label]
Shen, N., "Discovering LDP Next-Nexthop Labels", Shen, N., "Discovering LDP Next-Nexthop Labels",
draft-shen-mpls-ldp-nnhop-label-02 (work in progress), draft-shen-mpls-ldp-nnhop-label-02 (work in progress),
May 2005. May 2005.
[ISPF] McQuillan, J., Richer, I., and E. Rosen, "ARPANET Routing [ISPF] McQuillan, J., Richer, I., and E. Rosen, "ARPANET Routing
Algorithm Improvements"", BBN Technical Report 3803, 1978. Algorithm Improvements"", BBN Technical Report 3803, 1978.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
 End of changes. 19 change blocks. 
108 lines changed or deleted 69 lines changed or added

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