draft-ietf-rtgwg-remote-lfa-04.txt   draft-ietf-rtgwg-remote-lfa-05.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: May 26, 2014 Cisco Systems Expires: November 14, 2014 Cisco Systems
M. Shand M. Shand
Independent Contributor Independent Contributor
N. So N. So
Tata Communications Tata Communications
November 22, 2013 May 13, 2014
Remote LFA FRR Remote LFA FRR
draft-ietf-rtgwg-remote-lfa-04 draft-ietf-rtgwg-remote-lfa-05
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 link failures when none can be provided by the basic connectivity for point to point link failures when none can be
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
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 May 26, 2014. This Internet-Draft will expire on November 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 5 3.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 5
3.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 5 3.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 6
4. Construction of Repair Paths . . . . . . . . . . . . . . . . 6 4. Construction of Repair Paths . . . . . . . . . . . . . . . . 7
4.1. Identifying Required Tunneled Repair Paths . . . . . . . 6 4.1. Identifying Required Tunneled Repair Paths . . . . . . . 7
4.2. Determining Tunnel End Points . . . . . . . . . . . . . . 6 4.2. Determining Tunnel End Points . . . . . . . . . . . . . . 7
4.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 7 4.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 8
4.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 9 4.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 10
4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 10 4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 11
5. Example Application of Remote LFAs . . . . . . . . . . . . . 14 5. Example Application of Remote LFAs . . . . . . . . . . . . . 15
6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Operation in an LDP environment . . . . . . . . . . . . . . . 16 7. Operation in an LDP environment . . . . . . . . . . . . . . . 17
8. Analysis of Real World Topologies . . . . . . . . . . . . . . 17 8. Analysis of Real World Topologies . . . . . . . . . . . . . . 18
8.1. Topology Details . . . . . . . . . . . . . . . . . . . . 17 8.1. Topology Details . . . . . . . . . . . . . . . . . . . . 19
8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 20 8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 21
9. Management Considerations . . . . . . . . . . . . . . . . . . 21 9. Management Considerations . . . . . . . . . . . . . . . . . . 22
10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 21 10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. Informative References . . . . . . . . . . . . . . . . . . . 22 14. Informative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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).
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 without any path (including equal cost
path splits) transiting the protected link. 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, is the set of routers
that S can reach without using the protected link S-E. that S can reach without using the protected link S-E.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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. For example if a tunnel is provided between S and C as topology. In Figure 1 S can reach A, B, and C without going via E;
shown in Figure 2 then C, now being a direct neighbor of S would these form S's extended P-space. The routers that can reach E
become an LFA for D and E. The non-failure traffic distribution is without going through S-E will be E's Q-space; these are D and C. B
not disrupted by the provision of such a tunnel since it is only used has equal-cost paths via B-A-S-E and B-C-D-E and so may go through
for repair traffic and MUST NOT be used for normal traffic. 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
tunnel is provided between S and C as shown in Figure 2 then C, now
being a direct neighbor of S would become an LFA for D and E. 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
provided in Section 4.2.
S---E The non-failure traffic distribution is not disrupted by the
/ \ \ provision of such a tunnel since it is only used for repair traffic
A \ D and MUST NOT be used for normal traffic.
\ \ /
B---C S---E
/ \ \
A \ D
\ \ /
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,
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 is relatively simple, and takes place exclusively on
the repairing node. In MPLS networks the targeted LDP protocol the repairing node. In MPLS networks the targeted LDP protocol
needed to learn the label binding at the repair tunnel endpoint is a needed to learn the label binding at the repair tunnel endpoint is a
well understood and widely deployed technology. 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. 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
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
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
a broadcast or non-nroadcast multi-access (NBMA) link.
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 assumed that, in the absence of multiple network from which it is known that, in the absence of a worse than
failures, it will travel to its destination using normal forwarding anticipated failure, the traffic will travel to its destination using
without looping back. This is equivalent to providing a virtual normal forwarding without looping back. This is equivalent to
loop-free alternate to supplement the physical loop-free alternates. providing a virtual loop-free alternate to supplement the physical
Hence the name "Remote LFA FRR". In its simplest form, when a link loop-free alternates. Hence the name "Remote LFA FRR". In its
cannot be entirely protected with local LFA neighbors, the protecting simplest form, when a link cannot be entirely protected with local
router seeks the help of a remote LFA staging point. Network LFA neighbors, the protecting router seeks the help of a remote LFA
manageability considerations may lead to a repair strategy that uses staging point. Network manageability considerations may lead to a
a remote LFA more frequently [I-D.ietf-rtgwg-lfa-manageability].] repair strategy that uses a remote LFA more frequently
[I-D.ietf-rtgwg-lfa-manageability].]
Examples of worse failures are node failures (see Section 6 ), and
through the failure of a shared risk link group (SRLG), the through
the independent concurrent failure of multiple links, and these are
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 S
can send the packet to N and the packet will be delivered to the 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". "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
between S and E, and not E itself. This is clearly the case, since between S and E, and not E itself. This is clearly the case, since
if it were possible to construct a tunnel from S to E then a if it were possible to construct a tunnel from S to E then a
conventional LFA would have been sufficient to effect the repair. conventional LFA would have been sufficient to effect the repair.
3.2. Tunnel Requirements 3.2. Tunnel Requirements
There are a number of IP in IP tunnel mechanisms that may be used to There are a number of IP in IP tunnel mechanisms that may be used to
fulfil the requirements of this design, such as IP-in-IP [RFC1853] fulfil the requirements of this design, such as IP-in-IP [RFC1853]
and GRE[RFC1701] . and GRE[RFC1701] .
In an MPLS enabled network using LDP[RFC5036], a simple label In an MPLS enabled network using LDP[RFC5036], a simple label
stack[RFC3032] may be used to provide the required repair tunnel. In stack[RFC3032] may be used to provide the required repair tunnel. In
this case the outer label is S's neighbor's label for the repair this case the outer label is S's neighbor's label for the repair
tunnel end point, and the inner label is the repair tunnel end tunnel end point, and the inner label is the repair tunnel end
point's label for the packet destination. In order for S to obtain point's label for the packet destination. In order for S to obtain
the correct inner label it is necessary to establish a directed LDP the correct inner label it is necessary to establish a targeted LDP
session[RFC5036] to the tunnel end point. session[RFC5036] to the tunnel end point.
The selection of the specific tunnelling mechanism (and any necessary The selection of the specific tunnelling mechanism (and any necessary
enhancements) used to provide a repair path is outside the scope of enhancements) used to provide a repair path is outside the scope of
this document. The deployment in an MPLS/LDP environment is this document. The deployment in an MPLS/LDP environment is
relatively simple in the data plane as an LDP LSP from S to the relatively simple in the data plane as an LDP LSP from S to the
repair tunnel endpoint (the selected PQ node) is readily available, repair tunnel endpoint (the selected PQ node) is readily available,
and hence does not require any new protocol extension or design and hence does not require any new protocol extension or design
change. This LSP is automatically established as a basic property of change. This LSP is automatically established as a basic property of
LDP behavior. The performance of the encapsulation and decapsulation LDP behavior. The performance of the encapsulation and decapsulation
is efficient as encapsulation is just a push of one label (like is efficient as encapsulation is just a push of one label (like
conventional MPLS TE FRR) and the decapsulation occurs naturally at conventional MPLS TE FRR) and the decapsulation is normally
the penultimate hop before the repair tunnel endpoint. In the configured to occur at the penultimate hop before the repair tunnel
control plane, a targeted LDP (TLDP) session is needed between the endpoint. In the control plane, a targeted LDP (TLDP) session is
repairing node and the repair tunnel endpoint, which will need to be needed between the repairing node and the repair tunnel endpoint,
established and the labels processed before the tunnel can be used. which will need to be established and the labels processed before the
The time to establish the TLDP session and acquire labels will limit tunnel can be used. The time to establish the TLDP session and
the speed at which a new tunnel can be put into service, but this acquire labels will limit the speed at which a new tunnel can be put
will not be a problem in normal operation. into service. This is not anticipated to be a problem in normal
operation since the managed introduction and removal of links is
relatively rare as is the incidence of failure in a well managed
network.
When a failure is detected, it is necessary to immediately redirect When a failure is detected, it is necessary to immediately redirect
traffic to the repair path. Consequently, the repair tunnel used traffic to the repair path. Consequently, the repair tunnel used
must be provisioned beforehand in anticipation of the failure. Since MUST be provisioned beforehand in anticipation of the failure. Since
the location of the repair tunnels is dynamically determined it is the location of the repair tunnels is dynamically determined it is
necessary to automatically establish the repair tunnels. Multiple necessary to automatically establish the repair tunnels. Multiple
repairs may share a tunnel end point repairs MAY share a tunnel end point.
4. Construction of Repair Paths 4. Construction of Repair Paths
4.1. Identifying Required Tunneled Repair Paths 4.1. Identifying Required Tunneled Repair Paths
Not all links will require protection using a tunneled repair path. Not all links will require protection using a tunneled repair path.
Referring to Figure 1, if E can already be protected via an LFA, S-E Referring to Figure 1, if E can already be protected via an LFA, S-E
does not need to be protected using a repair tunnel, since all does not need to be protected using a repair tunnel, since all
destinations normally reachable through E must therefore also be destinations normally reachable through E must therefore also be
protectable by an LFA. Such an LFA is frequently termed a "link protectable by an LFA. Such an LFA is frequently termed a "link
LFA". Tunneled repair paths are only required for links which do not LFA". Tunneled repair paths (which may be calculated per-prefix) are
have a link 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
skipping to change at page 7, line 42 skipping to change at page 8, line 22
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
To compute the repair path for link S-E we need to determine the set To compute the repair path for link S-E we need to determine the set
of routers which can be reached from S without traversing S-E, and of routers which can be reached from S without traversing S-E, and
match this with the set of routers from which the node E can be match this with the set of routers from which the node E can be
reached, by normal forwarding, without traversing the link S-E. reached, by normal forwarding, without traversing the link S-E.
We will proceed as follows: we will describe how to compute the set The approach described in this memo is as follows:
of routers which can be reached from S without traversing S-E. We
call this the S's P-space with respect to the failure of link S-E. We o We describe how to compute the set of routers which can be reached
will then note that S is able to use P-Space of its neighbours since from S on the shortest path tree without traversing S-E. We call
S can determine which neighbour it will use as the next hop for the this the S's P-space with respect to the failure of link S-E.
repair. We call this the S's Extended P-Space with respect to the
failure of link S-E. The use of extended P-Space allows greater o We show how to extend the distance of the tunnel endpoint from the
repair coverage and is the preferred approach. Finally we will show point of local repair (PLR) by noting that S is able to use the
how to compute the set of routers from which the node E can be P-Space of its neighbours since S can determine which neighbour it
reached, by normal forwarding, without traversing the link S-E. This will use as the next hop for the repair. We call this the S's
is called the Q-space of E with respect to the link S-E. The Extended P-Space with respect to the failure of link S-E. The use
selection of the preferred node from the set of nodes that an in both of extended P-Space allows greater repair coverage and is the
Extended P-Space and Q-Space is described in Section 4.2.2. preferred approach.
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
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
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 without traversing S-E The set of routers which can be reached from S on the shortest path
is termed the P-space of S with respect to the link S-E. The P-space tree without traversing S-E is termed the P-space of S with respect
can be obtained by computing a shortest path tree (SPT) rooted at S to the link S-E. The P-space can be obtained by computing a shortest
and excising the sub-tree reached via the link S-E (including those path tree (SPT) rooted at S and excising the sub-tree reached via the
which are members of an ECMP). In the case of Figure 1 the P-space link S-E (including those routers which are members of an ECMP that
comprises nodes A and B only. Expressed in cost terms the set of includes link S-E). The exclusion of routers reachable via an ECMP
routers {P} are those for which the shortest path cost S->P is that includes S-E prevents the forwarding subsystem attempting to a
strictly less than the shortest path cost S->E->P. repair endpoint via the failed link S-E. Thus for example, if the 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
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}
are those for which the shortest path cost S->P is 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
skipping to change at page 9, line 42 skipping to change at page 10, line 34
correctly so, arguably, it does not matter which is chosen. However, correctly so, arguably, it does not matter which is chosen. However,
one repair tunnel end point may be preferred over the others on the one repair tunnel end point may be preferred over the others on the
basis of path cost or some other selection criteria. basis of path cost or some other selection criteria.
There is no technical requirement for the selection criteria to be There is no technical requirement for the selection criteria to be
consistent across all routers, but such consistency may be desirable consistent across all routers, but such consistency may be desirable
from an operational point of view. In general there are advantages from an operational point of view. In general there are advantages
in choosing the repair tunnel end point closest (shortest metric) to in choosing the repair tunnel end point closest (shortest metric) to
S. Choosing the closest maximises the opportunity for the traffic to S. Choosing the closest maximises the opportunity for the traffic to
be load balanced once it has been released from the tunnel. For be load balanced once it has been released from the tunnel. For
consistency in behavior, is RECOMMENDED that member of the set of consistency in behavior, it is RECOMMENDED that member of the set of
routers {PQ} with the lowest cost S->P be the default choice for P. routers {PQ} with the lowest cost S->P be the default choice for P.
In the event of a tie the router with the lowest node identifier 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].
skipping to change at page 10, line 20 skipping to change at page 11, line 13
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 using a cost based
algorithm. The pseudo-code provides in this section avoids algorithm. The pseudo-code provides in this section avoids
unnecessary SPF computations, but for the sake of readability, it unnecessary SPF computations, but for the sake of readability, it
does not otherwise try to optimize the code. In this description does not otherwise try to optimize the code. The algorithm covers
D_opt(a,b) is the shortest distance from node a to node b as computed the case where the repair first hop is reached via a broadcast or
by the SPF. 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 link. It does
not cover the case where the failed interface is a broadcast or non-
nroadcast multi-access (NBMA) link. To address that 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 pseudonode as a
node failure. This is because the Q spaces of the neighbors of the
pseudonode may be disjoint requiring use of a neighbor specific PQ
node. The reader is referred to
[I-D.psarkar-rtgwg-rlfa-node-protection] for further information on
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
o fail_intf is the failed interface (S-E in the example) o fail_intf is the failed interface (S-E in the example)
o fail_intf.remote_node is the node reachable over interface o fail_intf.remote_node is the node reachable over interface
fail_intf (node E in the example) fail_intf (node E in the example)
o intf.remote_node is the node reachable over interface intf o intf.remote_node is the set of nodes reachable over interface intf
o root is the root of the SPF calculation o root is the root of the SPF calculation
o self is the node carrying out the computation o self is the node carrying out the computation
o y is the node in the network under consideration o y is the node in the network under consideration
o y.pseudonode is true if y is a pseudonode
////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////
// //
// Main Function // Main Function
////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////
// //
// We have already computed the forward SPF from self to all nodes // We have already computed the forward SPF from self to all nodes
// y in network and thus we know D_opt (self, y). This is needed // y in network and thus we know D_opt (self, y). This is needed
// for normal forwarding. // for normal forwarding.
// However for completeness. // However for completeness.
skipping to change at page 12, line 45 skipping to change at page 14, line 18
// //
// Note the strictly less than operator is needed to // Note the strictly less than operator is needed to
// avoid ECMP issues. // avoid ECMP issues.
Compute_Extended_P_Space(fail_intf) Compute_Extended_P_Space(fail_intf)
foreach node y in network foreach node y in network
y.in_extended_P_space = false y.in_extended_P_space = false
// Extend P-space to the P-spaces of all reachable // Extend P-space to the P-spaces of all reachable
// neighbours // neighbours
foreach interface intf in self foreach interface intf in self
if (intf.remote_node != fail_intf.remote_node) // Exclude failed interface, noting that
if ( D_opt(intf.remote_node, y) < // the node reachable via that interface may be
D_opt(intf.remote_node, self) + // reachable via another interface (parallel path)
D_opt(self,fail_intf.remote_node) + if (intf != fail_intf)
D_opt(fail_intf.remote_node,y) ) foreach neighbor n in intf.remote_node
y.in_extended_P_space = true // Apply RFC5286 Inequality 1
if ( D_opt(n, y) <
D_opt(n,self) + D_opt)(self, y)
y.in_extended_P_space = true
///////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////
// //
// Compute the nodes in Q-space // Compute the nodes in Q-space
// //
Compute_Q_Space(fail_intf) Compute_Q_Space(fail_intf)
// Compute the cost from every node the network to the // Compute the cost from every node the network to the
// node normally reachable across the failed link // node normally reachable across the failed link
Compute_and_Store_Reverse_SPF(fail_intf.remote_node) Compute_and_Store_Reverse_SPF(fail_intf.remote_node)
skipping to change at page 13, line 33 skipping to change at page 15, line 11
y.in_Q_space = true y.in_Q_space = true
else else
y.in_Q_space = false y.in_Q_space = false
///////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////
// //
// Compute set of nodes in both extended P-space and in Q-space // Compute set of nodes in both extended P-space and in Q-space
Intersect_Extended_P_and_Q_Space() Intersect_Extended_P_and_Q_Space()
foreach node y in network foreach node y in network
if ( y.in_extended_P_space && y.in_Q_space ) if ( y.in_extended_P_space && y.in_Q_space &&
y.pseudonode == False)
y.valid_tunnel_endpoint = true y.valid_tunnel_endpoint = true
else else
y.valid_tunnel_endpoint = false y.valid_tunnel_endpoint = false
///////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////
// //
// A downstream route is one where the next hop is strictly // A downstream route is one where the next hop is strictly
// closer to the destination. By sending the packet to a // closer to the destination. By sending the packet to a
// PQ node that is downstream, we know that if the PQ node // PQ node that is downstream, we know that if the PQ node
// detects a failure, it will not loop the packet back to self. // detects a failure, it will not loop the packet back to self.
skipping to change at page 14, line 38 skipping to change at page 16, line 18
When a failure occurs on the link between PE1 and P2, PE1 does not When a failure occurs on the link between PE1 and P2, PE1 does not
have an LFA for traffic reachable via P1. Similarly, by symmetry, if have an LFA for traffic reachable via P1. Similarly, by symmetry, if
the link between PE2 and P1 fails, PE2 does not have an LFA for the link between PE2 and P1 fails, PE2 does not have an LFA for
traffic reachable via P2. traffic reachable via P2.
Increasing the metric between PE1 and PE2 to allow the LFA would Increasing the metric between PE1 and PE2 to allow the LFA would
impact the normal traffic performance by potentially increasing the impact the normal traffic performance by potentially increasing the
latency. latency.
| 100 | | 100 |
-P2---------P1- -P1---------P2-
\ / \ /
1000 \ / 1000 1000 \ / 1000
PE1---PE2 PE1---PE2
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 P1 as the remote LFA repair described in this draft, by PE1 choosing P1 as the remote LFA repair
target node, and PE2 choosing P2 as the remote LFA repair target. target node, and PE2 choosing P2 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 link failure there
is a danger that the RLFA repair will loop. This is discussed in is a danger that the RLFA repair will loop. This is discussed in
detail in [I-D.bryant-ipfrr-tunnels]. In summary problem is that two detail in [I-D.bryant-ipfrr-tunnels]. In summary problem is that two
of more of E's neighbors each with E as the next hop to some of more of E's neighbors each with E as the next hop to some
destination D may attempt to repair a packet addressed to destination destination D may attempt to repair a packet addressed to destination
D via the other neighbor and then E, thus causing a loop to form. As D via the other neighbor and then E, thus causing a loop to form. A
will be noted from [I-D.bryant-ipfrr-tunnels], this can rapidly similar problem exists in the case of a shared risk link group
become a complex problem to address. failure where the PLR for each failure attempts to repair via the
other failure. As will be noted from [I-D.bryant-ipfrr-tunnels],
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 16, line 18 skipping to change at page 17, line 43
[I-D.psarkar-rtgwg-rlfa-node-protection]. [I-D.psarkar-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 emote LFA repair target's (PQ's) label to the stack for the emote 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 Section 2 S already has the first hop (A) label for In the example Figure 2 S already has the first hop (A) label for the
the remote LFA repair target (C) as a result of the ordinary remote LFA repair target (C) as a result of the ordinary operation of
operation of LDP. To get the remote LFA repair target's label (C's LDP. To get the remote LFA repair target's label (C's label) for the
label) for the destination (D), S needs to establish a targeted LDP destination (D), S needs to establish a targeted LDP session with C.
session with C. The label stack for normal operation and RLFA The label stack for normal operation and RLFA operation is shown
operation is shown below in Figure 4. below in Figure 4.
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
| datalink | | datalink | | datalink | | datalink | | datalink | | datalink |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
| S's label for D | | E's label for D | | A's label for C | | S's label for D | | E's label for D | | A's label for C |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
| Payload | | Payload | | C's label for D | | Payload | | Payload | | C's label for D |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
X Y | Payload | X Y | Payload |
+-----------------+ +-----------------+
skipping to change at page 17, line 30 skipping to change at page 18, line 47
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
This section gives the results of analysing a number of real world This section gives the results of analysing a number of real world
service provider topologies collected between October 2012 and the service provider topologies collected between the end of 2012 and
date of this draft. early 2013
8.1. Topology Details 8.1. Topology Details
The figure below characterises each topology (topo) studied in terms The figure below characterises each topology (topo) studied in terms
of : of :
o The number of nodes (# nodes) excluding pseudonodes. o The number of nodes (# nodes) excluding pseudonodes.
o The number of bidirectional links ( # links) including parallel o The number of bidirectional links ( # links) including parallel
links and links to and from pseudonodes. links and links to and from pseudonodes.
o The number of node pairs that are connected by one or more links o The number of node pairs that are connected by one or more links
(# pairs). (# pairs).
o The number of node pairs that are connected by more than one (i.e. o The number of node pairs that are connected by more than one (i.e.
parallel) link ( # para). parallel) link ( # para).
o The number of links (excluding pseudonode links, which are by o The number of links (excluding pseudonode links, which are by
definition asymmetric) that have asymmetric metrics (#asym). definition asymmetric) that have asymmetric metrics (#asym).
+------+---------+---------+---------+--------+--------+ +------+---------+---------+---------+--------+--------+
| topo | # nodes | # links | # pairs | # para | # asym | | topo | # nodes | # links | # pairs | # para | # asym |
+------+---------+---------+---------+--------+--------+ +------+---------+---------+---------+--------+--------+
| 1 | 315 | 570 | 560 | 10 | 3 | | 1 | 315 | 570 | 560 | 10 | 3 |
| 2 | 158 | 373 | 312 | 33 | 0 | | 2 | 158 | 373 | 312 | 33 | 0 |
| 3 | 655 | 1768 | 1314 | 275 | 1195 | | 3 | 655 | 1768 | 1314 | 275 | 1195 |
| 4 | 1281 | 2326 | 2248 | 70 | 10 | | 4 | 1281 | 2326 | 2248 | 70 | 10 |
| 5 | 364 | 811 | 659 | 80 | 86 | | 5 | 364 | 811 | 659 | 80 | 86 |
| 6 | 114 | 318 | 197 | 101 | 4 | | 6 | 114 | 318 | 197 | 101 | 4 |
| 7 | 55 | 237 | 159 | 67 | 2 | | 7 | 55 | 237 | 159 | 67 | 2 |
| 8 | 779 | 1848 | 1441 | 199 | 437 | | 8 | 779 | 1848 | 1441 | 199 | 437 |
| 9 | 263 | 482 | 413 | 41 | 12 | | 9 | 263 | 482 | 413 | 41 | 12 |
| 10 | 86 | 375 | 145 | 64 | 22 | | 10 | 86 | 375 | 145 | 64 | 22 |
| 11 | 162 | 1083 | 351 | 201 | 49 | | 11 | 162 | 1083 | 351 | 201 | 49 |
| 12 | 380 | 1174 | 763 | 231 | 0 | | 12 | 380 | 1174 | 763 | 231 | 0 |
| 13 | 1051 | 2087 | 2037 | 48 | 64 | | 13 | 1051 | 2087 | 2037 | 48 | 64 |
| 14 | 92 | 291 | 204 | 64 | 2 | | 14 | 92 | 291 | 204 | 64 | 2 |
+------+---------+---------+---------+--------+--------+ +------+---------+---------+---------+--------+--------+
8.2. LFA only 8.2. LFA only
The figure below shows the percentage of protected destinations (% The figure below shows the percentage of protected destinations (%
prot) and percentage of guaranteed node protected destinations ( % prot) and percentage of guaranteed node protected destinations ( %
gtd N) for the set of topologies characterized in Section 8.1 gtd N) for the set of topologies characterized in Section 8.1
achieved using only LFA repairs. achieved using only LFA repairs.
+------+--------+---------+ These statistics were generated by considering each node and then
| topo | % prot | % gtd N | considering each link to each next hop to each destination. The
+------+--------+---------+ percentage of such links across the entire network that are protected
| 1 | 78.5 | 36.9 | against link failure was determined. This is the percentage of
| 2 | 97.3 | 52.4 | protected destinations. If a link is protected against the failure
| 3 | 99.3 | 58 | of the next hop node, this is considered guaranteed node protecting
| 4 | 83.1 | 63.1 | (GNP) and percentage of guaranteed node protected destinations is
| 5 | 99 | 59.1 | calculated using the same method used for calculating the link
| 6 | 86.4 | 21.4 | protection coverage.
| 7 | 93.9 | 35.4 |
| 8 | 95.3 | 48.1 | GNP is identical to Node-protecting as defined in [RFC5714] and does
| 9 | 82.2 | 49.5 | not include the additional node protection coverage obtained by the
| 10 | 98.5 | 14.9 | de facto node-protecting condition described in [RFC6571].
| 11 | 99.6 | 24.8 |
| 12 | 99.5 | 62.4 | +------+--------+---------+
| 13 | 92.4 | 51.6 | | topo | % prot | % gtd N |
| 14 | 99.3 | 48.6 | +------+--------+---------+
+------+--------+---------+ | 1 | 78.5 | 36.9 |
| 2 | 97.3 | 52.4 |
| 3 | 99.3 | 58 |
| 4 | 83.1 | 63.1 |
| 5 | 99 | 59.1 |
| 6 | 86.4 | 21.4 |
| 7 | 93.9 | 35.4 |
| 8 | 95.3 | 48.1 |
| 9 | 82.2 | 49.5 |
| 10 | 98.5 | 14.9 |
| 11 | 99.6 | 24.8 |
| 12 | 99.5 | 62.4 |
| 13 | 92.4 | 51.6 |
| 14 | 99.3 | 48.6 |
+------+--------+---------+
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).
skipping to change at page 20, line 41 skipping to change at page 22, 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 saleability cases. In an MPLS network, this is achieved without any scaleability
impact, as the tunnels to the PQ nodes are always present as a impact, as the tunnels to the PQ nodes are always present as a
property of an LDP-based deployment. In the very few cases where P property of an LDP-based deployment. In the very few cases where P
and Q spaces have an empty intersection, one could select the closest and Q spaces have an empty intersection, a possible solution is to
node in the Q space and signal an explicitly-routed RSVP TE LSP to select the closest node in the Q space and signal an explicitly-
that Q node. A directed LDP session is then established with the routed RSVP TE LSP to that Q node. A targeted LDP session is then
selected Q node and the rest of the solution is identical to that established with the selected Q node and the rest of the solution is
described elsewhere in this document. Alternatively the segment identical to that described elsewhere in this document.
routing technology being defined in the IETF may be used to carry the Alternatively the segment routing technology being defined in the
traffic between non-collocated P and Q nodes IETF may be used to carry the traffic between non-collocated P and Q
[I-D.filsfils-rtgwg-segment-routing-use-cases], nodes [I-D.filsfils-rtgwg-segment-routing-use-cases],
[I-D.filsfils-rtgwg-segment-routing], [I-D.filsfils-rtgwg-segment-routing],
[I-D.gredler-rtgwg-igp-label-advertisement]. [I-D.gredler-rtgwg-igp-label-advertisement].
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
skipping to change at page 22, line 44 skipping to change at page 24, line 33
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", draft-filsfils-rtgwg-
segment-routing-01 (work in progress), October 2013. segment-routing-01 (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", draft-gredler-rtgwg-
igp-label-advertisement-05 (work in progress), May 2013. 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., and K. Raza, Litkowski, S., Decraene, B., Filsfils, C., Raza, K.,
"Operational management of Loop Free Alternates", draft- Horneffer, M., and p. psarkar@juniper.net, "Operational
ietf-rtgwg-lfa-manageability-00 (work in progress), May management of Loop Free Alternates", draft-ietf-rtgwg-lfa-
2013. 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., cbowers@juniper.net, c., and S. Litkowski,
"Remote-LFA Node Protection and Manageability", draft- "Remote-LFA Node Protection and Manageability", draft-
psarkar-rtgwg-rlfa-node-protection-02 (work in progress), psarkar-rtgwg-rlfa-node-protection-04 (work in progress),
November 2013. 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.
skipping to change at page 24, line 5 skipping to change at page 25, line 41
[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.
[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 [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.
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
 End of changes. 41 change blocks. 
167 lines changed or deleted 243 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/