draft-ietf-rtgwg-remote-lfa-08.txt   draft-ietf-rtgwg-remote-lfa-09.txt 
Network Working Group S. Bryant Network Working Group S. Bryant
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track S. Previdi Intended status: Standards Track S. Previdi
Expires: March 30, 2015 Cisco Systems Expires: June 19, 2015 Cisco Systems
M. Shand M. Shand
Independent Contributor Independent Contributor
N. So N. So
Vinci Systems Vinci Systems
September 26, 2014 December 16, 2014
Remote LFA FRR Remote LFA FRR
draft-ietf-rtgwg-remote-lfa-08 draft-ietf-rtgwg-remote-lfa-09
Abstract Abstract
This draft describes an extension to the basic IP fast re-route This draft describes an extension to the basic IP fast re-route
mechanism described in RFC5286, that provides additional backup mechanism described in RFC5286, that provides additional backup
connectivity for point to point link failures when none can be connectivity for point to point link failures when none can be
provided by the basic mechanisms. provided by the basic mechanisms.
Requirements Language Requirements Language
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 March 30, 2015. This Internet-Draft will expire on June 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6 3.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6
3.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 6 3.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 6
4. Construction of Repair Paths . . . . . . . . . . . . . . . . 7 4. Construction of Repair Paths . . . . . . . . . . . . . . . . 7
4.1. Identifying Required Tunneled Repair Paths . . . . . . . 7 4.1. Identifying Required Tunneled Repair Paths . . . . . . . 7
4.2. Determining Tunnel End Points . . . . . . . . . . . . . . 8 4.2. Determining Tunnel End Points . . . . . . . . . . . . . . 8
4.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 8 4.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 8
4.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 10 4.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 11
4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 11 4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 11
4.4. Interactions with IS-IS Overload, RFC6987, and Costed 4.4. Interactions with IS-IS Overload, RFC6987, and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 16 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Example Application of Remote LFAs . . . . . . . . . . . . . 17 5. Example Application of Remote LFAs . . . . . . . . . . . . . 17
6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Operation in an LDP environment . . . . . . . . . . . . . . . 19 7. Operation in an LDP environment . . . . . . . . . . . . . . . 19
8. Analysis of Real World Topologies . . . . . . . . . . . . . . 20 8. Analysis of Real World Topologies . . . . . . . . . . . . . . 20
8.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21 8.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21
8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 23 8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 23
9. Management Considerations . . . . . . . . . . . . . . . . . . 24 9. Management Considerations . . . . . . . . . . . . . . . . . . 24
10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 25 10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Terminology 1. Terminology
This draft uses the terms defined in [RFC5714]. This section defines This draft uses the terms defined in [RFC5714]. This section defines
additional terms used in this draft. additional terms used in this draft.
FIB Forwarding Information (data)Base. The database used FIB Forwarding Information (data)Base. The database used
by a packet forwarder to determine the actions it by a packet forwarder to determine the actions it
should take on a packet it is processing. should take on a packet it is processing.
skipping to change at page 4, line 34 skipping to change at page 4, line 34
by LFAs. The destination C is an ECMP from S, and so can be by LFAs. The destination C is an ECMP from S, and so can be
protected when S-E fails, but D and E are not protectable using LFAs. protected when S-E fails, but D and E are not protectable using LFAs.
This draft describes extensions to the basic repair mechanism in This draft describes extensions to the basic repair mechanism in
which tunnels are used to provide additional logical links which can which tunnels are used to provide additional logical links which can
then be used as loop free alternates where none exist in the original then be used as loop free alternates where none exist in the original
topology. In Figure 1 S can reach A, B, and C without going via E; topology. In Figure 1 S can reach A, B, and C without going via E;
these form S's extended P-space. The routers that can reach E these form S's extended P-space. The routers that can reach E
without going through S-E will be E's Q-space; these are D and C. B without going through S-E will be E's Q-space; these are D and C. B
has equal-cost paths via B-A-S-E and B-C-D-E and so may go through has equal-cost paths via B-A-S-E and B-C-D-E and so may go through
S-E. The single node in both S's P-space and E's Q-space is C; thus S-E. The single node in both S's extended P-space and E's Q-space is
node C is selected as the repair tunnel's end-point. Thus, if a C; thus node C is selected as the repair tunnel's end-point. Thus,
tunnel is provided between S and C as shown in Figure 2 then C, now if a tunnel is provided between S and C as shown in Figure 2 then C,
being a direct neighbor of S would become an LFA for D and E. The now being a direct neighbor of S would become an LFA for D and E.
definition of (extended-)P space and Q space are provided in The definition of (extended-)P space and Q space are provided in
Section 1 and details of the calculation of the tunnel end points is Section 1 and details of the calculation of the tunnel end points is
provided in Section 4.2. provided in Section 4.2.
The non-failure traffic distribution is not disrupted by the The non-failure traffic distribution is not disrupted by the
provision of such a tunnel since it is only used for repair traffic provision of such a tunnel since it is only used for repair traffic
and MUST NOT be used for normal traffic. and MUST NOT be used for normal traffic. Note that OAM traffic
specifically to verify the viability of the repair MAY traverse the
tunnel prior to a failure.
S---E S---E
/ \ \ / \ \
A \ D A \ D
\ \ / \ \ /
B---C B---C
Figure 2: The addition of a tunnel Figure 2: The addition of a tunnel
The use of this technique is not restricted to ring based topologies, The use of this technique is not restricted to ring based topologies,
skipping to change at page 6, line 13 skipping to change at page 6, line 13
anticipated failure, the traffic will travel to its destination using anticipated failure, the traffic will travel to its destination using
normal forwarding without looping back. This is equivalent to normal forwarding without looping back. This is equivalent to
providing a virtual loop-free alternate to supplement the physical providing a virtual loop-free alternate to supplement the physical
loop-free alternates. Hence the name "Remote LFA FRR". In its loop-free alternates. Hence the name "Remote LFA FRR". In its
simplest form, when a link cannot be entirely protected with local simplest form, when a link cannot be entirely protected with local
LFA neighbors, the protecting router seeks the help of a remote LFA LFA neighbors, the protecting router seeks the help of a remote LFA
staging point. Network manageability considerations may lead to a staging point. Network manageability considerations may lead to a
repair strategy that uses a remote LFA more frequently repair strategy that uses a remote LFA more frequently
[I-D.ietf-rtgwg-lfa-manageability]. [I-D.ietf-rtgwg-lfa-manageability].
Examples of worse failures are node failures (see Section 6 ), and Examples of worse failures are node failures (see Section 6 ), the
through the failure of a shared risk link group (SRLG), the through failure of a shared risk link group (SRLG), the independent
the independent concurrent failure of multiple links, and these are concurrent failures of multiple links, broadcast or non-broadcast
out of scope for this specification. multi-access (NBMA) links Section 2 ; protecting against such worse
failures is out of scope for this specification.
3.1. Tunnels as Repair Paths 3.1. Tunnels as Repair Paths
Consider an arbitrary protected link S-E. In LFA FRR, if a path to Consider an arbitrary protected link S-E. In LFA FRR, if a path to
the destination from a neighbor N of S does not cause a packet to the destination from a neighbor N of S does not cause a packet to
loop back over the link S-E (i.e. N is a loop-free alternate), then loop back over the link S-E (i.e. N is a loop-free alternate), then
S can send the packet to N and the packet will be delivered to the S can send the packet to N and the packet will be delivered to the
destination using the pre-failure forwarding information. If there destination using the pre-failure forwarding information. If there
is no such LFA neighbor, then S may be able to create a virtual LFA is no such LFA neighbor, then S may be able to create a virtual LFA
by using a tunnel to carry the packet to a point in the network which by using a tunnel to carry the packet to a point in the network which
skipping to change at page 8, line 29 skipping to change at page 8, line 29
The properties that are required of repair tunnel end points are The properties that are required of repair tunnel end points are
therefore: therefore:
o The repair tunneled point MUST be reachable from the tunnel source o The repair tunneled point MUST be reachable from the tunnel source
without traversing the failed link; and without traversing the failed link; and
o When released from the tunnel, packets MUST proceed towards their o When released from the tunnel, packets MUST proceed towards their
destination without being attracted back over the failed link. destination without being attracted back over the failed link.
Provided both these requirements are met, packets forwarded over the Provided both these requirements are met, packets forwarded over the
repair tunnel will reach their destination and will not loop. repair tunnel will reach their destination, and will not loop after a
single link failure.
In some topologies it will not be possible to find a repair tunnel In some topologies it will not be possible to find a repair tunnel
endpoint that exhibits both the required properties. For example if endpoint that exhibits both the required properties. For example if
the ring topology illustrated in Figure 1 had a cost of 4 for the the ring topology illustrated in Figure 1 had a cost of 4 for the
link B-C, while the remaining links were cost 1, then it would not be link B-C, while the remaining links were cost 1, then it would not be
possible to establish a tunnel from S to C (without resorting to some possible to establish a tunnel from S to C (without resorting to some
form of source routing). form of source routing).
4.2.1. Computing Repair Paths 4.2.1. Computing Repair Paths
skipping to change at page 9, line 29 skipping to change at page 9, line 32
both extended P-space and Q-space is provided in Section 4.3. both extended P-space and Q-space is provided in Section 4.3.
4.2.1.1. P-space 4.2.1.1. P-space
The set of routers which can be reached from S on the shortest path The set of routers which can be reached from S on the shortest path
tree without traversing S-E is termed the P-space of S with respect tree without traversing S-E is termed the P-space of S with respect
to the link S-E. The P-space can be obtained by computing a shortest to the link S-E. The P-space can be obtained by computing a shortest
path tree (SPT) rooted at S and excising the sub-tree reached via the path tree (SPT) rooted at S and excising the sub-tree reached via the
link S-E (including those routers which are members of an ECMP that link S-E (including those routers which are members of an ECMP that
includes link S-E). The exclusion of routers reachable via an ECMP includes link S-E). The exclusion of routers reachable via an ECMP
that includes S-E prevents the forwarding subsystem attempting to a that includes S-E prevents the forwarding subsystem from attempting
repair endpoint via the failed link S-E. Thus for example, if the to a repair endpoint via the failed link S-E. Thus for example, if
SPF computation stores at each node the next-hops to be used to reach the SPF computation stores at each node the next-hops to be used to
that node from S, then the node can be added to P-space if none of reach that node from S, then the node can be added to P-space if none
its next-hops are S-E. In the case of Figure 1 the P-space comprises of its next-hops are S-E. In the case of Figure 1 the P-space
nodes A and B only. Expressed in cost terms the set of routers {P} comprises nodes A and B only. Expressed in cost terms the set of
are those for which the shortest path cost S->P is strictly less than routers {P} are those for which the shortest path cost S->P is
the shortest path cost S->E->P. strictly less than the shortest path cost S->E->P.
4.2.1.2. Extended P-space 4.2.1.2. Extended P-space
The description in Section 4.2.1.1 calculated router S's P-space The description in Section 4.2.1.1 calculated router S's P-space
rooted at S itself. However, since router S will only use a repair rooted at S itself. However, since router S will only use a repair
path when it has detected the failure of the link S-E, the initial path when it has detected the failure of the link S-E, the initial
hop of the repair path need not be subject to S's normal forwarding hop of the repair path need not be subject to S's normal forwarding
decision process. Thus we introduce the concept of extended P-space. decision process. Thus we introduce the concept of extended P-space.
Router S's extended P-space is the union of the P-spaces of each of Router S's extended P-space is the union of the P-spaces of each of
S's neighbours (N). This may be calculated by computing an SPT at S's neighbours (N). This may be calculated by computing an SPT at
each of S's neighbors (excluding E) and excising the subtree reached each of S's neighbors (excluding E) and excising the subtree reached
via the path N->S->E. The use of extended P-space may allow router S via the path N->S->E. Note this will excise those routers which are
to reach potential repair tunnel end points that were otherwise reachable through all ECMPs that includes link S-E. The use of
unreachable. In cost terms a router (P) is in extended P-space if extended P-space may allow router S to reach potential repair tunnel
the shortest path cost N->P is strictly less than the shortest path end points that were otherwise unreachable. In cost terms a router
cost N->S->E->P. In other words, once the packet it forced to N by (P) is in extended P-space if the shortest path cost N->P is strictly
S, it is lower cost for it to continue on to P by any path except one less than the shortest path cost N->S->E->P. In other words, once
that takes it back to S and then across the S->E link. the packet it forced to N by S, it is lower cost for it to continue
on to P by any path except one that takes it back to S and then
across the S->E link.
Since in the case of Figure 1 node A is a per-prefix LFA for the Since in the case of Figure 1 node A is a per-prefix LFA for the
destination node C, the set of extended P-space nodes comprises nodes destination node C, the set of extended P-space nodes comprises nodes
A, B and C. Since node C is also in E's Q-space, there is now a node A, B and C. Since node C is also in E's Q-space, there is now a node
common to both extended P-space and Q-space which can be used as a common to both extended P-space and Q-space which can be used as a
repair tunnel end-point to protect the link S-E. repair tunnel end-point to protect the link S-E.
4.2.1.3. Q-space 4.2.1.3. Q-space
The set of routers from which the node E can be reached, by normal The set of routers from which the node E can be reached, by normal
skipping to change at page 11, line 25 skipping to change at page 11, line 33
P. In the event of a tie the router with the lowest node identifier P. In the event of a tie the router with the lowest node identifier
SHOULD be selected. SHOULD be selected.
It is a local matter whether the repair path selection policy used by It is a local matter whether the repair path selection policy used by
the router favours LFA repairs over RLFA repairs. An LFA repair has the router favours LFA repairs over RLFA repairs. An LFA repair has
the advantage of not requiring the use of tunnel, however network the advantage of not requiring the use of tunnel, however network
manageability considerations may lead to a repair strategy that uses manageability considerations may lead to a repair strategy that uses
a remote LFA more frequently [I-D.ietf-rtgwg-lfa-manageability]. a remote LFA more frequently [I-D.ietf-rtgwg-lfa-manageability].
As described in [RFC5286], always selecting a PQ node that is As described in [RFC5286], always selecting a PQ node that is
downstream with respect to the repairing node, prevents the formation downstream to the destination with respect to the repairing node,
of loops when the failure is worse than expected. The use of prevents the formation of loops when the failure is worse than
downstream nodes reduces the repair coverage, and operators are expected. The use of downstream nodes reduces the repair coverage,
advised to determine whether adequate coverage is achieved before and operators are advised to determine whether adequate coverage is
enabling this selection feature. achieved before enabling this selection feature.
4.3. A Cost Based RLFA Algorithm 4.3. A Cost Based RLFA Algorithm
The preceding text has mostly described the computation of the remote The preceding text has mostly described the computation of the remote
LFA repair target (PQ) in terms of the intersection of two LFA repair target (PQ) in terms of the intersection of two
reachability graphs computed using SPFs. This section describes a reachability graphs computed using SPFs. This section describes a
method of computing the remote LFA repair target for a specific method of computing the remote LFA repair target for a specific
failed link using a cost based algorithm. The pseudo-code provided failed link using a cost based algorithm. The pseudo-code provided
in this section avoids unnecessary SPF computations, but for the sake in this section avoids unnecessary SPF computations, but for the sake
of readability, it does not otherwise try to optimize the code. The of readability, it does not otherwise try to optimize the code. The
algorithm covers the case where the repair first hop is reached via a algorithm covers the case where the repair first hop is reached via a
broadcast or non-broadcast multi-access (NBMA) link such as a LAN. broadcast or non-broadcast multi-access (NBMA) link such as a LAN.
It also covers the case where the P or Q node is attached via such a It also covers the case where the P or Q node is attached via such a
link. It does not cover the case where the failed interface is a link. It does not cover the case where the failed interface is a
broadcast or non-broadcast multi-access (NBMA) link. To address that broadcast or non-broadcast multi-access (NBMA) link. To address that
case it is necessary to compute the Q space of each neighbor of the case it is necessary to compute the Q space of each neighbor of the
repairing router reachable though the LAN, i.e. to treat the repairing router reachable though the LAN, i.e. to treat the
pseudonode as a node failure. This is because the Q spaces of the pseudonode as a node failure. This is because the Q spaces of the
neighbors of the pseudonode may be disjoint requiring use of a neighbors of the pseudonode may be disjoint requiring use of a
neighbor specific PQ node. The reader is referred to neighbor specific PQ node. The reader is referred to
[I-D.psarkar-rtgwg-rlfa-node-protection] for further information on [I-D.ietf-rtgwg-rlfa-node-protection] for further information on the
the use of RLFA for node repairs. use of RLFA for node repairs.
The following notation is used: The following notation is used:
o D_opt(a,b) is the shortest distance from node a to node b as o D_opt(a,b) is the shortest distance from node a to node b as
computed by the SPF. computed by the SPF.
o dest is the packet destination o dest is the packet destination
o fail_intf is the failed interface (S-E in the example) o fail_intf is the failed interface (S-E in the example)
skipping to change at page 18, line 20 skipping to change at page 18, line 20
5 5
Figure 3: Example SP topology Figure 3: Example SP topology
Clearly, full protection can be provided, using the techniques Clearly, full protection can be provided, using the techniques
described in this draft, by PE1 choosing P2 as the remote LFA repair described in this draft, by PE1 choosing P2 as the remote LFA repair
target node, and PE2 choosing P1 as the remote LFA repair target. target node, and PE2 choosing P1 as the remote LFA repair target.
6. Node Failures 6. Node Failures
When the failure is a node failure rather than a link failure there When the failure is a node failure rather than a point-to-point link
is a danger that the RLFA repair will loop. This is discussed in failure there is a danger that the RLFA repair will loop. This is
detail in [I-D.bryant-ipfrr-tunnels]. In summary the problem is that discussed in detail in [I-D.bryant-ipfrr-tunnels]. In summary the
two of more of E's neighbors each with E as the next hop to some problem is that two of more of E's neighbors each with E as the next
destination D may attempt to repair a packet addressed to destination hop to some destination D may attempt to repair a packet addressed to
D via the other neighbor and then E, thus causing a loop to form. A destination D via the other neighbor and then E, thus causing a loop
similar problem exists in the case of a shared risk link group to form. A similar problem exists in the case of a shared risk link
failure where the PLR for each failure attempts to repair via the group failure where the PLR for each failure attempts to repair via
other failure. As will be noted from [I-D.bryant-ipfrr-tunnels], the other failure. As will be noted from [I-D.bryant-ipfrr-tunnels],
this can rapidly become a complex problem to address. this can rapidly become a complex problem to address.
There are a number of ways to minimize the probability of a loop There are a number of ways to minimize the probability of a loop
forming when a node failure occurs and there exists the possibility forming when a node failure occurs and there exists the possibility
that two of E's neighbors may form a mutual repair. that two of E's neighbors may form a mutual repair.
1. Detect when a packet has arrived on some interface I that is also 1. Detect when a packet has arrived on some interface I that is also
the interface used to reach the first hop on the RLFA path to the the interface used to reach the first hop on the RLFA path to the
remote LFA repair target, and drop the packet. This is useful in remote LFA repair target, and drop the packet. This is useful in
the case of a ring topology. the case of a ring topology.
skipping to change at page 19, line 12 skipping to change at page 19, line 12
repair via some other neighbor of E (Y), but Y cannot repair via repair via some other neighbor of E (Y), but Y cannot repair via
X. X.
Case 1 accepts that loops may form and suppresses them by dropping Case 1 accepts that loops may form and suppresses them by dropping
packets. Dropping packets may be considered less detrimental than packets. Dropping packets may be considered less detrimental than
looping packets. This approach may also lead to dropping some looping packets. This approach may also lead to dropping some
legitimate packets. Cases 2 and 3 above prevent the formation of a legitimate packets. Cases 2 and 3 above prevent the formation of a
loop, but at the expense of a reduced repair coverage and at the cost loop, but at the expense of a reduced repair coverage and at the cost
of additional complexity in the algorithm to compute the repair path. of additional complexity in the algorithm to compute the repair path.
Alternatively one might choose to assume that the probability of a Alternatively one might choose to assume that the probability of a
node failure and microloops forming is sufficiently rare that the node failure is sufficiently rare that the issue of looping RLFA
case can be ignored. repairs can be ignored.
The probability of a node failure and the consequences of node The probability of a node failure and the consequences of node
failure in any particular topology will depend on the node design, failure in any particular topology will depend on the node design,
the particular topology in use, and the strategy adopted under node the particular topology in use, and the strategy adopted under node
failure. It is recommended that a network operator perform an failure. It is recommended that a network operator perform an
analysis of the consequences and probability of node failure in their analysis of the consequences and probability of node failure in their
network, and determine whether the incidence and consequence of network, and determine whether the incidence and consequence of
occurrence are acceptable. occurrence are acceptable.
This topic is further discussed in This topic is further discussed in
[I-D.psarkar-rtgwg-rlfa-node-protection]. [I-D.ietf-rtgwg-rlfa-node-protection].
7. Operation in an LDP environment 7. Operation in an LDP environment
Where this technique is used in an MPLS network using LDP [RFC5036], Where this technique is used in an MPLS network using LDP [RFC5036],
and S is a transit node, S will need to swap the top label in the and S is a transit node, S will need to swap the top label in the
stack for the remote LFA repair target's (PQ's) label to the stack for the remote LFA repair target's (PQ's) label to the
destination, and to then push its own label for the remote LFA repair destination, and to then push its own label for the remote LFA repair
target. target.
In the example Figure 2 S already has the first hop (A) label for the In the example Figure 2 S already has the first hop (A) label for the
skipping to change at page 20, line 34 skipping to change at page 20, line 34
address that the remote LFA repair target is willing to use for address that the remote LFA repair target is willing to use for
targeted LDP sessions. Ideally this is provided by the remote LFA targeted LDP sessions. Ideally this is provided by the remote LFA
repair target advertising this address in the IGP in use. Which repair target advertising this address in the IGP in use. Which
address is used, how this is advertised in the IGP, and whether this address is used, how this is advertised in the IGP, and whether this
is a special IP address or an IP address also used for some other is a special IP address or an IP address also used for some other
purpose is out of scope for this document and must be specified in an purpose is out of scope for this document and must be specified in an
IGP specific RFC. IGP specific RFC.
In the absence of a protocol to learn the preferred IP address for In the absence of a protocol to learn the preferred IP address for
targeted LDP, an LSR should attempt a targeted LDP session with the targeted LDP, an LSR should attempt a targeted LDP session with the
Router ID [RFC2328] [RFC5305] [RFC5340], unless it is configured Router ID [RFC2328] [RFC5305] [RFC5340] [RFC6119]
[I-D.ietf-ospf-routable-ip-address], unless it is configured
otherwise. otherwise.
No protection is available until the TLDP session has been No protection is available until the TLDP session has been
established and a label for the destination has been learned from the established and a label for the destination has been learned from the
remote LFA repair target. If for any reason the TLDP session cannot remote LFA repair target. If for any reason the TLDP session cannot
not be established, an implementation SHOULD advise the operator not be established, an implementation SHOULD advise the operator
about the protection setup issue using any well known mechanism such about the protection setup issue using any well known mechanism such
as Syslog [RFC5424] or SNMP [RFC3411]. as Syslog [RFC5424] or SNMP [RFC3411].
8. Analysis of Real World Topologies 8. Analysis of Real World Topologies
skipping to change at page 24, line 28 skipping to change at page 24, line 28
| 10 | 98.5 | 99.6 | 14.9 | 14.1 | | 10 | 98.5 | 99.6 | 14.9 | 14.1 |
| 11 | 99.6 | 99.9 | 24.8 | 24.9 | | 11 | 99.6 | 99.9 | 24.8 | 24.9 |
| 12 | 99.5 | 99.999 | 62.4 | 62.8 | | 12 | 99.5 | 99.999 | 62.4 | 62.8 |
| 13 | 92.4 | 97.5 | 51.6 | 54.6 | | 13 | 92.4 | 97.5 | 51.6 | 54.6 |
| 14 | 99.3 |100 | 48.6 | 48.6 | | 14 | 99.3 |100 | 48.6 | 48.6 |
+------+--------+--------+---------+---------+ +------+--------+--------+---------+---------+
As shown in the table, remote LFA provides close to 100% prefix As shown in the table, remote LFA provides close to 100% prefix
protection against link failure in 11 of the 14 topologies studied, protection against link failure in 11 of the 14 topologies studied,
and provides a significant improvement in two of the remaining three and provides a significant improvement in two of the remaining three
cases. In an MPLS network, this is achieved without any scaleability cases. Note that in an MPLS network the tunnels to the PQ nodes are
impact, as the tunnels to the PQ nodes are always present as a always present as a property of an LDP-based deployment.
property of an LDP-based deployment.
In the small number of cases where there is no intersection between In the small number of cases where there is no intersection between
the (extended)P-space and the Q-space, a number of solutions to the (extended)P-space and the Q-space, a number of solutions to
providing a suitable path between such disjoint regions in the providing a suitable path between such disjoint regions in the
network have been discussed in the working group. For example an network have been discussed in the working group. For example an
explicitly routed LSP between P and Q might be set up using RSVP-TE explicitly routed LSP between P and Q might be set up using RSVP-TE
or using Segment Routing [I-D.filsfils-spring-segment-routing]. Such or using Segment Routing [I-D.filsfils-spring-segment-routing]. Such
extended repair methods are outside the scope of this document. extended repair methods are outside the scope of this document.
9. Management Considerations 9. Management Considerations
The management of LFA and remote LFA is the subject of ongoing work The management of LFA and remote LFA is the subject of ongoing work
withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the
reader is referred. Management considerations may lead to a reader is referred. Management considerations may lead to a
preference for the use of a remote LFA over an available LFA. This preference for the use of a remote LFA over an available LFA. This
preference is a matter for the network operator, and not a matter of preference is a matter for the network operator, and not a matter of
protocol correctness. protocol correctness.
When the network re-converges, microloops [RFC5715] may form due to
transient inconsistencies in the router FIBs. If it is determined
that microloops are a significant issue in the deployment, then a
suitable loop free convergence methods such as one of those described
in [RFC5715], [RFC6976], or [I-D.litkowski-rtgwg-uloop-delay] should
be implemented.
10. Historical Note 10. Historical Note
The basic concepts behind Remote LFA were invented in 2002 and were The basic concepts behind Remote LFA were invented in 2002 and were
later included in [I-D.bryant-ipfrr-tunnels], submitted in 2004. later included in [I-D.bryant-ipfrr-tunnels], submitted in 2004.
[I-D.bryant-ipfrr-tunnels], targeted a 100% protection coverage and [I-D.bryant-ipfrr-tunnels], targeted a 100% protection coverage and
hence included additional mechanisms on top of the Remote LFA hence included additional mechanisms on top of the Remote LFA
concept. The addition of these mechanisms made the proposal very concept. The addition of these mechanisms made the proposal very
complex and computationally intensive and it was therefore not complex and computationally intensive and it was therefore not
pursued as a working group item. pursued as a working group item.
As explained in [RFC6571], the purpose of the LFA FRR technology is As explained in [RFC6571], the purpose of the LFA FRR technology is
not to provide coverage at any cost. A solution for this already not to provide coverage at any cost. A solution for this already
exists with MPLS TE FRR. MPLS TE FRR is a mature technology which is exists with MPLS TE FRR. MPLS TE FRR is a mature technology which is
able to provide protection in any topology thanks to the explicit able to provide protection in any topology thanks to the explicit
routing capability of MPLS TE. routing capability of MPLS TE.
The purpose of LFA FRR technology is to provide for a simple FRR The purpose of LFA FRR technology is to provide for a simple FRR
solution when such a solution is possible. The first step along this solution when such a solution is possible. The first step along this
simplicity approach was "local" LFA [RFC5286]. We propose "Remote simplicity approach was "local" LFA [RFC5286]. This specification of
LFA" as a natural second step. "Remote LFA" is a natural second step.
11. IANA Considerations 11. IANA Considerations
There are no IANA considerations that arise from this architectural There are no IANA considerations that arise from this architectural
description of IPFRR. The RFC Editor may remove this section on description of IPFRR. The RFC Editor may remove this section on
publication. publication.
12. Security Considerations 12. Security Considerations
The security considerations of RFC 5286 also apply. The security considerations of [RFC5286] also apply.
To prevent their use as an attack vector the repair tunnel endpoints Targeted LDP sessions and MPLS tunnels are normal features of an MPLS
SHOULD be assigned from a set of addresses that are not reachable network and their use in this application raises no additional
from outside the routing domain. security concerns.
To prevent their use as an attack vector IP repair tunnel endpoints
(where used) SHOULD be assigned from a set of addresses that are not
reachable from outside the routing domain.
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Levente Csikor and Chris Bowers for their The authors wish to thank Levente Csikor and Chris Bowers for their
contribution to the cost based algorithm text. We thank Alia Atlas, contribution to the cost based algorithm text. We thank Alia Atlas,
Ross Callon, Stephane Litkowski, Bharath R, and Pushpasis Sarkar for Ross Callon, Stephane Litkowski, Bharath R, and Pushpasis Sarkar for
their review of this document. their review of this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008. Reroute: Loop-Free Alternates", RFC 5286, September 2008.
14.2. Informative References 14.2. Informative References
skipping to change at page 26, line 26 skipping to change at page 26, line 31
Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03
(work in progress), November 2007. (work in progress), November 2007.
[I-D.filsfils-spring-segment-routing] [I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-spring- "Segment Routing Architecture", draft-filsfils-spring-
segment-routing-04 (work in progress), July 2014. segment-routing-04 (work in progress), July 2014.
[I-D.ietf-ospf-routable-ip-address]
Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP
Addresses in OSPF RI LSA", draft-ietf-ospf-routable-ip-
address-01 (work in progress), October 2014.
[I-D.ietf-rtgwg-lfa-manageability] [I-D.ietf-rtgwg-lfa-manageability]
Litkowski, S., Decraene, B., Filsfils, C., Raza, K., Litkowski, S., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and p. psarkar@juniper.net, "Operational Horneffer, M., and p. psarkar@juniper.net, "Operational
management of Loop Free Alternates", draft-ietf-rtgwg-lfa- management of Loop Free Alternates", draft-ietf-rtgwg-lfa-
manageability-04 (work in progress), August 2014. manageability-04 (work in progress), August 2014.
[I-D.psarkar-rtgwg-rlfa-node-protection] [I-D.ietf-rtgwg-rlfa-node-protection]
psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers, psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers,
C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node
Protection and Manageability", draft-psarkar-rtgwg-rlfa- Protection and Manageability", draft-ietf-rtgwg-rlfa-node-
node-protection-05 (work in progress), June 2014. protection-01 (work in progress), December 2014.
[I-D.litkowski-rtgwg-uloop-delay]
Litkowski, S., Decraene, B., Filsfils, C., and P.
Francois, "Microloop prevention by introducing a local
convergence delay", draft-litkowski-rtgwg-uloop-delay-03
(work in progress), February 2014.
[ISOCORE2010] [ISOCORE2010]
So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates) So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates)
Case Studies in Verizon's LDP Network", 2010. Case Studies in Verizon's LDP Network", 2010.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
skipping to change at page 27, line 24 skipping to change at page 27, line 45
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
5714, January 2010. 5714, January 2010.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, February 2011.
[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,
Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP) Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, June 2012. Networks", RFC 6571, June 2012.
[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
Francois, P., and O. Bonaventure, "Framework for Loop-Free
Convergence Using the Ordered Forwarding Information Base
(oFIB) Approach", RFC 6976, July 2013.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 6987, McPherson, "OSPF Stub Router Advertisement", RFC 6987,
September 2013. September 2013.
Authors' Addresses Authors' Addresses
Stewart Bryant Stewart Bryant
Cisco Systems Cisco Systems
250, Longwater, Green Park, 250, Longwater, Green Park,
Reading RG2 6GB, UK Reading RG2 6GB, UK
 End of changes. 30 change blocks. 
65 lines changed or deleted 105 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/