draft-ietf-rtgwg-remote-lfa-05.txt   draft-ietf-rtgwg-remote-lfa-06.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: November 14, 2014 Cisco Systems Expires: November 24, 2014 Cisco Systems
M. Shand M. Shand
Independent Contributor Independent Contributor
N. So N. So
Tata Communications Tata Communications
May 13, 2014 May 23, 2014
Remote LFA FRR Remote LFA FRR
draft-ietf-rtgwg-remote-lfa-05 draft-ietf-rtgwg-remote-lfa-06
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. 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 November 14, 2014. This Internet-Draft will expire on November 24, 2014.
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
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . 7 4.2. Determining Tunnel End Points . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . 10
4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 11 4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 11
5. Example Application of Remote LFAs . . . . . . . . . . . . . 15 4.4. Interactions with IS-IS Overload, RFC 3137, and Costed
6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 16 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Operation in an LDP environment . . . . . . . . . . . . . . . 17 5. Example Application of Remote LFAs . . . . . . . . . . . . . . 17
8. Analysis of Real World Topologies . . . . . . . . . . . . . . 18 6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Topology Details . . . . . . . . . . . . . . . . . . . . 19 7. Operation in an LDP environment . . . . . . . . . . . . . . . 18
8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Analysis of Real World Topologies . . . . . . . . . . . . . . 20
8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Topology Details . . . . . . . . . . . . . . . . . . . . . 20
8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 21 8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Management Considerations . . . . . . . . . . . . . . . . . . 22 8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 23 8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Management Considerations . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
14. Informative References . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. Informative References . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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.
Extended P-space Extended P-space
The union of the P-space of the neighbours of a The union of the P-space of the neighbours of a
specific router with respect to the protected link specific router with respect to the protected link
(see Section 4.2.1.2). (see Section 4.2.1.2).
FIB Forwarding Information (data)Base. The database used
by a packet forwarder to determine the actions it
should take on a packet it is processing.
P-space P-space is the set of routers reachable from a P-space P-space is the set of routers reachable from a
specific router without any path (including equal cost specific router using the normal FIB, without any path
path splits) transiting the protected link. (including equal cost path splits) transiting the
protected link.
For example, the P-space of S, is the set of routers For example, the P-space of S with respect to link
that S can reach without using the protected link S-E. S-E, is the set of routers that S can reach without
using the protected link S-E.
PQ node A node which is a member of both the (extended) PQ node A node which is a member of both the P-space and the
P-space and the Q-space. In remote LFA this is used Q-space. Where extended P-space is in use it is a
as the repair tunnel endpoint. node which is a member of both the extended P-space
and the Q-space. In remote LFA this is used as the
repair tunnel endpoint.
Q-space Q-space is the set of routers from which a specific Q-space Q-space is the set of routers from which a specific
router can be reached without any path (including router can be reached without any path (including
equal cost path splits) transiting the protected link. equal cost path splits) transiting the protected link.
Repair tunnel A tunnel established for the purpose of providing a Repair tunnel A tunnel established for the purpose of providing a
virtual neighbor which is a Loop Free Alternate. virtual neighbor which is a Loop Free Alternate.
Remote LFA (RLFA) The use of a PQ node rather than a neighbour of Remote LFA (RLFA) The use of a PQ node rather than a neighbour of
the repairing node as the next hop in an LFA repair. the repairing node as the next hop in an LFA repair.
skipping to change at page 4, line 15 skipping to change at page 4, line 25
S---E S---E
/ \ / \
A D A D
\ / \ /
B---C B---C
Figure 1: A simple ring topology Figure 1: A simple ring topology
If all link costs are equal, the link S-E cannot be fully protected If all link costs are equal, the link S-E cannot be fully protected
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 P-space and E's Q-space is C; thus
node C is selected as the repair tunnel's end-point. Thus, if a node C is selected as the repair tunnel's end-point. Thus, if a
skipping to change at page 5, line 7 skipping to change at page 5, line 15
The use of this technique is not restricted to ring based topologies, The use of this technique is not restricted to ring based topologies,
but is a general mechanism which can be used to enhance the but is a general mechanism which can be used to enhance the
protection provided by LFAs. A study of the protection achieved protection provided by LFAs. A study of the protection achieved
using remote LFA in typical service provider core networks is using remote LFA in typical service provider core networks is
provided in Section 8, and a side by side comparison between LFA and provided in Section 8, and a side by side comparison between LFA and
remote LFA is provided in Section 8.4. remote LFA is provided in Section 8.4.
Remote LFA is suitable for incremental deployment within a network, Remote LFA is suitable for incremental deployment within a network,
including a network that is already deploying LFA. Computation of including a network that is already deploying LFA. Computation of
the repair path is relatively simple, and takes place exclusively on the repair path requires acceptable CPU resources, and takes place
the repairing node. In MPLS networks the targeted LDP protocol exclusively on the repairing node. In MPLS networks the targeted LDP
needed to learn the label binding at the repair tunnel endpoint is a protocol needed to learn the label binding at the repair tunnel
well understood and widely deployed technology. endpoint is a well understood and widely deployed technology.
This technique describes in this document is directed at providing This technique describes in this document is directed at providing
repairs in the case of link failures. Considerations regarding node repairs in the case of link failures. Considerations regarding node
failures are discussed in Section 6. This memo describes a solution failures are discussed in Section 6. This memo describes a solution
to the case where the failure occurs on a point to point link. It to the case where the failure occurs on a point to point link. It
covers the case where the repair first hop is reached via a broadcast covers the case where the repair first hop is reached via a broadcast
or non-broadcast multi-access (NBMA) link such as a LAN, and the case or non-broadcast multi-access (NBMA) link such as a LAN, and the case
where the P or Q node is attached via such a link. It does not where the P or Q node is attached via such a link. It does not
however cover the more complicated case where the failed interface is however cover the more complicated case where the failed interface is
a broadcast or non-nroadcast multi-access (NBMA) link. a broadcast or non-broadcast multi-access (NBMA) link.
This document considers the case when the repair path is confined to
either a single area or to the level two routing domain. In all
other cases, the chosen PQ node should be regarded as a tunnel
adjacency of the repairing node, and the considerations described in
Section 6 of [RFC5286] taken into account.
3. Repair Paths 3. Repair Paths
As with LFA FRR, when a router detects an adjacent link failure, it As with LFA FRR, when a router detects an adjacent link failure, it
uses one or more repair paths in place of the failed link. Repair uses one or more repair paths in place of the failed link. Repair
paths are pre-computed in anticipation of later failures so they can paths are pre-computed in anticipation of later failures so they can
be promptly activated when a failure is detected. be promptly activated when a failure is detected.
A tunneled repair path tunnels traffic to some staging point in the A tunneled repair path tunnels traffic to some staging point in the
network from which it is known that, in the absence of a worse than network from which it is known that, in the absence of a worse than
skipping to change at page 5, line 48 skipping to change at page 6, line 15
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 ), and
through the failure of a shared risk link group (SRLG), the through through the failure of a shared risk link group (SRLG), the through
the independent concurrent failure of multiple links, and these are the independent concurrent failure of multiple links, and these are
out of scope for this specification. 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 S loop back over the link S-E (i.e. N is a loop-free alternate), then
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
is not a direct neighbor of S from which the packet will be delivered is not a direct neighbor of S from which the packet will be delivered
to the destination without looping back to S. In this document such a to the destination without looping back to S. In this document such a
tunnel is termed a repair tunnel. The tail-end of this tunnel (the tunnel is termed a repair tunnel. The tail-end of this tunnel (the
repair tunnel endpoint) is a "PQ node" and the repair mechanism is a repair tunnel endpoint) is a "PQ node" and the repair mechanism is a
"remote LFA". This tunnel MUST NOT traverse the link S-E. "remote LFA". This tunnel MUST NOT traverse the link S-E.
Note that the repair tunnel terminates at some intermediate router Note that the repair tunnel terminates at some intermediate router
skipping to change at page 7, line 32 skipping to change at page 7, line 47
only required for links which do not have a link or per-prefix LFA. only required for links which do not have a link or per-prefix LFA.
It should be noted that using the Q-space of E as a proxy for the It should be noted that using the Q-space of E as a proxy for the
Q-space of each destination can result in failing to identify valid Q-space of each destination can result in failing to identify valid
remote LFAs. The extent to which this reduces the effective remote LFAs. The extent to which this reduces the effective
protection coverage is topology dependent. protection coverage is topology dependent.
4.2. Determining Tunnel End Points 4.2. Determining Tunnel End Points
The repair tunnel endpoint needs to be a node in the network The repair tunnel endpoint needs to be a node in the network
reachable from S without traversing S-E. In addition, the repair reachable from S without traversing S-E. In addition, the repair
tunnel end point needs to be a node from which packets will normally tunnel end point needs to be a node from which packets will normally
flow towards their destination without being attracted back to the flow towards their destination without being attracted back to the
failed link S-E. failed link S-E.
Note that once released from the tunnel, the packet will be Note that once released from the tunnel, the packet will be
forwarded, as normal, on the shortest path from the release point to forwarded, as normal, on the shortest path from the release point to
its destination. This may result in the packet traversing the router its destination. This may result in the packet traversing the router
E at the far end of the protected link S-E., but this is obviously E at the far end of the protected link S-E., but this is obviously
not required. not required.
skipping to change at page 8, line 32 skipping to change at page 8, line 47
The approach described in this memo is as follows: The approach described in this memo is as follows:
o We describe how to compute the set of routers which can be reached o We describe how to compute the set of routers which can be reached
from S on the shortest path tree without traversing S-E. We call from S on the shortest path tree without traversing S-E. We call
this the S's P-space with respect to the failure of link S-E. this the S's P-space with respect to the failure of link S-E.
o We show how to extend the distance of the tunnel endpoint from the o We show how to extend the distance of the tunnel endpoint from the
point of local repair (PLR) by noting that S is able to use the point of local repair (PLR) by noting that S is able to use the
P-Space of its neighbours since S can determine which neighbour it P-Space of its neighbours since S can determine which neighbour it
will use as the next hop for the repair. We call this the S's will use as the next hop for the repair. We call this the S's
Extended P-Space with respect to the failure of link S-E. The use Extended P-Space with respect to the failure of link S-E. The use
of extended P-Space allows greater repair coverage and is the of extended P-Space allows greater repair coverage and is the
preferred approach. preferred approach.
o Finally we how to compute the set of routers from which the node E o Finally we how to compute the set of routers from which the node E
can be reached, by normal forwarding, without traversing the link can be reached, by normal forwarding, without traversing the link
S-E. This is called the Q-space of E with respect to the link S-E. S-E. This is called the Q-space of E with respect to the link
S-E.
The selection of the preferred node from the set of nodes that an in The selection of the preferred node from the set of nodes that an in
both Extended P-Space and Q-Space is described in Section 4.2.2. both Extended P-Space and Q-Space is described in Section 4.2.2.
A suitable cost based algorithm to compute the set of nodes common to A suitable cost based algorithm to compute the set of nodes common to
both extended P-space and Q-space is provide in Section 4.3. both extended P-space and Q-space is provide 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 attempting to a
repair endpoint via the failed link S-E. Thus for example, if the SPF repair endpoint via the failed link S-E. Thus for example, if the
computation stores at each node the next-hops to be used to reach SPF computation stores at each node the next-hops to be used to reach
that node from S, then the node can be added to P-space if none of that node from S, then the node can be added to P-space if none of
its next-hops are S-E. In the case of Figure 1 the P-space comprises its next-hops are S-E. In the case of Figure 1 the P-space comprises
nodes A and B only. Expressed in cost terms the set of routers {P} nodes A and B only. Expressed in cost terms the set of routers {P}
are those for which the shortest path cost S->P is strictly less than are those for which the shortest path cost S->P is strictly less than
the shortest path cost S->E->P. 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
skipping to change at page 9, line 42 skipping to change at page 10, line 10
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
forwarding, without traversing the link S-E is termed the Q-space of forwarding, without traversing the link S-E is termed the Q-space of
E with respect to the link S-E. The Q-space can be obtained by E with respect to the link S-E. The Q-space can be obtained by
computing a reverse shortest path tree (rSPT) rooted at E, with the computing a reverse shortest path tree (rSPT) rooted at E, with the
sub-tree which traverses the failed link excised (including those sub-tree which traverses the failed link excised (including those
which are members of an ECMP). The rSPT uses the cost towards the which are members of an ECMP). The rSPT uses the cost towards the
root rather than from it and yields the best paths towards the root root rather than from it and yields the best paths towards the root
from other nodes in the network. In the case of Figure 1 the Q-space from other nodes in the network. In the case of Figure 1 the Q-space
comprises nodes C and D only. Expressed in cost terms the set of comprises nodes C and D only. Expressed in cost terms the set of
routers {Q} are those for which the shortest path cost Q->E is routers {Q} are those for which the shortest path cost Q->E is
strictly less than the shortest path cost Q->S->E. In Figure 1 the strictly less than the shortest path cost Q->S->E. In Figure 1 the
intersection of the E's Q-space with S's P-space defines the set of intersection of the E's Q-space with S's P-space defines the set of
viable repair tunnel end-points, known as "PQ nodes". As can be viable repair tunnel end-points, known as "PQ nodes". As can be
skipping to change at page 11, line 10 skipping to change at page 11, line 26
of loops when the failure is worse than expected. The use of of loops when the failure is worse than expected. The use of
downstream nodes reduces the repair coverage, and operators are downstream nodes reduces the repair coverage, and operators are
advised to determine whether adequate coverage is achieved before advised to determine whether adequate coverage is achieved before
enabling this selection feature. 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 using a cost based method of computing the remote LFA repair target for a specific
algorithm. The pseudo-code provides in this section avoids failed link using a cost based algorithm. The pseudo-code provides
unnecessary SPF computations, but for the sake of readability, it in this section avoids unnecessary SPF computations, but for the sake
does not otherwise try to optimize the code. The algorithm covers of readability, it does not otherwise try to optimize the code. The
the case where the repair first hop is reached via a broadcast or algorithm covers the case where the repair first hop is reached via a
non-broadcast multi-access (NBMA) link such as a LAN. It also covers broadcast or non-broadcast multi-access (NBMA) link such as a LAN.
the case where the P or Q node is attached via such a link. It does It also covers the case where the P or Q node is attached via such a
not cover the case where the failed interface is a broadcast or non- link. It does not cover the case where the failed interface is a
nroadcast multi-access (NBMA) link. To address that case it is broadcast or non-broadcast multi-access (NBMA) link. To address that
necessary to compute the Q space of each neighbor of the repairing case it is necessary to compute the Q space of each neighbor of the
router reachable though the LAN, i.e. to treat the pseudonode as a repairing router reachable though the LAN, i.e. to treat the
node failure. This is because the Q spaces of the neighbors of the pseudonode as a node failure. This is because the Q spaces of the
pseudonode may be disjoint requiring use of a neighbor specific PQ neighbors of the pseudonode may be disjoint requiring use of a
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.psarkar-rtgwg-rlfa-node-protection] for further information on
the use of RLFA for node repairs. the 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
skipping to change at page 15, line 38 skipping to change at page 16, line 38
if (y.valid_tunnel_endpoint) if (y.valid_tunnel_endpoint)
Compute_and_Store_Forward_SPF(y) Compute_and_Store_Forward_SPF(y)
if ((D_opt(y,dest) < D_opt(self,dest)) if ((D_opt(y,dest) < D_opt(self,dest))
y.valid_tunnel_endpoint = true y.valid_tunnel_endpoint = true
else else
y.valid_tunnel_endpoint = false y.valid_tunnel_endpoint = false
// //
///////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////
4.4. Interactions with IS-IS Overload, RFC 3137, and Costed Out Links
The consideration concerning interactions with IS-IS Overload,
[RFC3137], and costed out links as described in [RFC5286] apply. In
selecting a PQ node a PLR MUST exclude any candidate that is
reachable (including via ECMP) from the PLR via a path subject to one
of the above exclusions. The method of determining the exclusion is
a local matter.
5. Example Application of Remote LFAs 5. Example Application of Remote LFAs
An example of a commonly deployed topology which is not fully An example of a commonly deployed topology which is not fully
protected by LFAs alone is shown in Figure 3. PE1 and PE2 are protected by LFAs alone is shown in Figure 3. PE1 and PE2 are
connected in the same site. P1 and P2 may be geographically connected in the same site. P1 and P2 may be geographically
separated (inter-site). In order to guarantee the lowest latency separated (inter-site). In order to guarantee the lowest latency
path from/to all other remote PEs, normally the shortest path follows path from/to all other remote PEs, normally the shortest path follows
the geographical distance of the site locations. Therefore, to the geographical distance of the site locations. Therefore, to
ensure this, a lower IGP metric (5) is assigned between PE1 and PE2. ensure this, a lower IGP metric (5) is assigned between PE1 and PE2.
A high metric (1000) is set on the P-PE links to prevent the PEs A high metric (1000) is set on the P-PE links to prevent the PEs
skipping to change at page 20, line 43 skipping to change at page 22, line 4
8.3. RLFA 8.3. RLFA
The figure below shows the percentage of protected destinations (% The figure below shows the percentage of protected destinations (%
prot) and % guaranteed node protected destinations ( % gtd N) for prot) and % guaranteed node protected destinations ( % gtd N) for
RLFA protection in the topologies studies. In addition, it show the RLFA protection in the topologies studies. In addition, it show the
percentage of destinations using an RLFA repair (% PQ) together with percentage of destinations using an RLFA repair (% PQ) together with
the total number of unidirectional RLFA targeted LDP session the total number of unidirectional RLFA targeted LDP session
established (# PQ), the number of PQ sessions which would be required established (# PQ), the number of PQ sessions which would be required
for complete protection, but which could not be established (no PQ). for complete protection, but which could not be established (no PQ).
It also shows the 50 (p50), 90 (p90) and 100 (p100) percentiles for It also shows the 50 (p50), 90 (p90) and 100 (p100) percentiles for
the number of individual LDP sessions terminating at an individual the number of individual LDP sessions terminating at an individual
node (whether used for TX, RX or both). node (whether used for TX, RX or both).
For example, if there were LDP sessions required A->B, A->C, C->A, For example, if there were LDP sessions required A->B, A->C, C->A,
C->D, these would be counted as 2, 1, 2, 1 at nodes A,B,C and D C->D, these would be counted as 2, 1, 2, 1 at nodes A,B,C and D
respectively because:- respectively because:-
A has two sessions (to nodes B and C) A has two sessions (to nodes B and C)
B has one session (to node A) B has one session (to node A)
C has two sessions (to nodes A and D) C has two sessions (to nodes A and D)
D has one session (to node D) D has one session (to node D)
In this study, remote LFA is only used when necessary. i.e. when In this study, remote LFA is only used when necessary. i.e. when
there is at least one destination which is not reparable by a per there is at least one destination which is not reparable by a per
destination LFA, and a single remote LFA tunnel is used (if destination LFA, and a single remote LFA tunnel is used (if
available) to repair traffic to all such destinations. The remote available) to repair traffic to all such destinations. The remote
LFA repair target points are computed using extended P space and LFA repair target points are computed using extended P space and
choosing the PQ node which has the lowest metric cost from the choosing the PQ node which has the lowest metric cost from the
repairing node. repairing node.
+------+--------+--------+------+------+-------+-----+-----+------+ +------+--------+--------+------+------+-------+-----+-----+------+
| topo | % prot |% gtd N | % PQ | # PQ | no PQ | p50 | p90 | p100 | | topo | % prot |% gtd N | % PQ | # PQ | no PQ | p50 | p90 | p100 |
+------+--------+--------+------+------+-------+-----+-----+------+ +------+--------+--------+------+------+-------+-----+-----+------+
skipping to change at page 23, line 46 skipping to change at page 25, line 9
The security considerations of RFC 5286 also apply. The security considerations of RFC 5286 also apply.
To prevent their use as an attack vector the repair tunnel endpoints To prevent their use as an attack vector the repair tunnel endpoints
SHOULD be assigned from a set of addresses that are not reachable SHOULD be assigned from a set of addresses that are not reachable
from outside the routing domain. 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 Stephane contribution to the cost based algorithm text. We thank Alia Atlas,
Litkowski for his review of this work. Ross Callon, Stephane Litkowski, Bharath R, and Pushpasis Sarkarfor
their review of this document.
14. Informative References 14. Informative References
[I-D.bryant-ipfrr-tunnels] [I-D.bryant-ipfrr-tunnels]
Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
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-rtgwg-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg-
segment-routing-use-cases-02 (work in progress), October
2013.
[I-D.filsfils-rtgwg-segment-routing] [I-D.filsfils-rtgwg-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-rtgwg- "Segment Routing Architecture",
segment-routing-01 (work in progress), October 2013. draft-filsfils-rtgwg-segment-routing-01 (work in
progress), October 2013.
[I-D.filsfils-rtgwg-segment-routing-use-cases]
Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases",
draft-filsfils-rtgwg-segment-routing-use-cases-02 (work in
progress), October 2013.
[I-D.gredler-rtgwg-igp-label-advertisement] [I-D.gredler-rtgwg-igp-label-advertisement]
Gredler, H., Amante, S., Scholl, T., and L. Jalil, Gredler, H., Amante, S., Scholl, T., and L. Jalil,
"Advertising MPLS labels in IGPs", draft-gredler-rtgwg- "Advertising MPLS labels in IGPs",
igp-label-advertisement-05 (work in progress), May 2013. draft-gredler-rtgwg-igp-label-advertisement-05 (work in
progress), May 2013.
[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",
manageability-03 (work in progress), February 2014. draft-ietf-rtgwg-lfa-manageability-03 (work in progress),
February 2014.
[I-D.psarkar-rtgwg-rlfa-node-protection] [I-D.psarkar-rtgwg-rlfa-node-protection]
psarkar@juniper.net, p., Gredler, H., Hegde, S., psarkar@juniper.net, p., Gredler, H., Hegde, S.,
Raghuveer, H., cbowers@juniper.net, c., and S. Litkowski, Raghuveer, H., Bowers, C., and S. Litkowski, "Remote-LFA
"Remote-LFA Node Protection and Manageability", draft- Node Protection and Manageability",
psarkar-rtgwg-rlfa-node-protection-04 (work in progress), draft-psarkar-rtgwg-rlfa-node-protection-04 (work in
April 2014. progress), April 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.
[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.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[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.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
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",
5714, January 2010. RFC 5714, January 2010.
[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,
Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, June 2012.
[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.
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
UK UK
Email: stbryant@cisco.com Email: stbryant@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
skipping to change at page 26, line 24 skipping to change at page 27, line 33
De Kleetlaan 6a De Kleetlaan 6a
1831 Diegem 1831 Diegem
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
URI:
Mike Shand Mike Shand
Independent Contributor Independent Contributor
Email: imc.shand@gmail.com Email: imc.shand@gmail.com
Ning So Ning So
Tata Communications Tata Communications
Mobile Broadband Services Mobile Broadband Services
 End of changes. 37 change blocks. 
97 lines changed or deleted 130 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/