draft-ietf-rtgwg-lfa-applicability-03.txt   draft-ietf-rtgwg-lfa-applicability-04.txt 
Network Working Group Clarence Filsfils Network Working Group Clarence Filsfils
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational Pierre Francois Intended status: Informational Pierre Francois
Expires: February 18, 2012 UCLouvain Expires: June 10, 2012 Institute IMDEA Networks
Mike Shand December 8, 2011
Cisco Systems
Bruno Decraene
France Telecom
James Uttaro
ATT
Nicolai Leymann
Martin Horneffer
Deutsche Telekom
August 17, 2011
LFA applicability in SP networks LFA applicability in SP networks
draft-ietf-rtgwg-lfa-applicability-03 draft-ietf-rtgwg-lfa-applicability-04
Abstract Abstract
In this draft, we analyze the applicability of LoopFree Alternates in In this draft, we analyze the applicability of LoopFree Alternates in
both core and access parts of Service Provider networks. We provide both core and access parts of Service Provider networks. We provide
design guides to favor their applicability where relevant, typically design guides to favor their applicability where relevant, typically
in the access part of the network. in the access part of the network.
Status of this Memo Status of this Memo
skipping to change at page 1, line 43 skipping to change at page 1, line 34
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 February 18, 2012. This Internet-Draft will expire on June 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 8
7. Capacity Planning with LFA in mind . . . . . . . . . . . . . . 27 7. Capacity Planning with LFA in mind . . . . . . . . . . . . . . 27
7.1. Coverage Estimation - Default Topology . . . . . . . . . . 27 7.1. Coverage Estimation - Default Topology . . . . . . . . . . 27
7.2. Coverage estimation in relation to traffic . . . . . . . . 28 7.2. Coverage estimation in relation to traffic . . . . . . . . 28
7.3. Coverage verification for a given set of demands . . . . . 28 7.3. Coverage verification for a given set of demands . . . . . 28
7.4. Modeling - What-if Scenarios - Coverage impact . . . . . . 28 7.4. Modeling - What-if Scenarios - Coverage impact . . . . . . 28
7.5. Modeling - What-if Scenarios - Load impact . . . . . . . . 29 7.5. Modeling - What-if Scenarios - Load impact . . . . . . . . 29
7.6. Discussion on metric recommendations . . . . . . . . . . . 29 7.6. Discussion on metric recommendations . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Informative References . . . . . . . . . . . . . . . . . . . . 31 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Informative References . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
In this document, we analyze the applicability of LoopFree Alternates In this document, we analyze the applicability of LoopFree Alternates
in both core and access parts of Service Provider networks. We in both core and access parts of Service Provider networks. We
provide design guides to favor their applicability where relevant, provide design guides to favor their applicability where relevant,
typically in the access part of the network. typically in the access part of the network.
We first introduce the terminology used in this document in We first introduce the terminology used in this document in
Section 2. In Section 3, we describe typical access network designs Section 2. In Section 3, we describe typical access network designs
skipping to change at page 7, line 11 skipping to change at page 7, line 11
The access part of the network often represents the majority of the The access part of the network often represents the majority of the
nodes and links. It is organized in several tens or more of regions nodes and links. It is organized in several tens or more of regions
interconnected by the core network. Very often the core acts as an interconnected by the core network. Very often the core acts as an
ISIS level2 domain (OSPF area 0) while each access region is confined ISIS level2 domain (OSPF area 0) while each access region is confined
in an ISIS level1 domain (OSPF non 0 area). Very often, the network in an ISIS level1 domain (OSPF non 0 area). Very often, the network
topology within each access region is derived from a unique template topology within each access region is derived from a unique template
common across the whole access network. Within an access region common across the whole access network. Within an access region
itself, the network is made of several aggregation regions, each itself, the network is made of several aggregation regions, each
following the same interconnection topologies. following the same interconnection topologies.
For these reasons, we base the analysis of the LFA applicability in For these reasons, in the next sections, we base the analysis of the
the access network on the following abstract model: LFA applicability in a single access region, with the following
o We analyze a single access region. assumptions:
o Two routers (C1 and C2) provide connectivity between the access o Two routers (C1 and C2) provide connectivity between the access
region and the rest of the network. If a link connects these two region and the rest of the network. If a link connects these two
routers in the region area, then it has a symmetric IGP metric c. routers in the region area, then it has a symmetric IGP metric c.
o We analyze a single aggregation region within the access region. o We analyze a single aggregation region within the access region.
Two aggregation routers (A1 and A2) interconnect the aggregation Two aggregation routers (A1 and A2) interconnect the aggregation
region to the two routers C1 and C2 for the analyzed access region to the two routers C1 and C2 for the analyzed access
region. If a link connects A1 to A2 then it has a symmetric IGP region. If a link connects A1 to A2 then it has a symmetric IGP
metric a. If a link connects an A to a C router then, for sake of metric a. If a link connects an A to a C router then, for sake of
generality, we will call d the metric for the directed link CA and generality, we will call d the metric for the directed link CA and
u the metric for the AC directed link. u the metric for the AC directed link.
o We analyze two edge routers E1 and E2 in the access region. Each o We analyze two edge routers E1 and E2 in the access region. Each
is either dual-homed directly into C1 and C2 xor into A1 and A2. is either dual-homed directly into C1 and C2 (Section 3.1) or into
The directed link metric between Cx/Ax and Ey is d and u in the A1 and A2 (Section 3.2, Section 3.3, Section 3.4 ). The directed
opposite direction. link metric between Cx/Ax and Ey is d and u in the opposite
direction.
o We assume a multi-level IGP domain. The analyzed access region o We assume a multi-level IGP domain. The analyzed access region
forms a level-1 domain. The core is the level-2 domain. We forms a level-1 (L1) domain. The core is the level-2 (L2) domain.
assume that the link C is L1L2. We assume that the loopbacks of We assume that the link between C1 and C2, if it exists, is
the C routers are part of the L2 topology. L1 routers learn about configured as L1L2. We assume that the loopbacks of the C routers
them as propagated routes (L2=>L1 with Down bit set). We remind are part of the L2 topology. L1 routers learn about them as
that if an L1L2 router learns about X/x as an L1 path P1, an L2 propagated routes (L2=>L1 with Down bit set). We remind that if
path P2 and an L1L2 path P12, then it will prefer path P1. If P1 an L1L2 router learns about X/x as an L1 path P1, an L2 path P2
is lost, then it will prefer path P2. and an L1L2 path P12, then it will prefer path P1. If P1 is lost,
then it will prefer path P2.
o We assume that all the C, A and E routers may be connected to o We assume that all the C, A and E routers may be connected to
customers and hence we analyze LFA coverage for the loopbacks of customers and hence we analyze LFA coverage for the loopbacks of
each type of node. each type of node.
o We assume that no useful traffic is directed to router-to-router o We assume that no useful traffic is directed to router-to-router
subnets and hence we do not analyze LFA applicability for these. subnets and hence we do not analyze LFA applicability for these.
o A prefix P models an important IGP destination that is not present o A prefix P models an important IGP destination that is not present
in the local access region. The igp metric from C1 to P is x and in the local access region. The igp metric from C1 to P is x and
the metric from C2 to P is x+e. the metric from C2 to P is x+e.
o We analyze LFA coverage against all link and node failures within o We analyze LFA coverage against all link and node failures within
the access region. the access region.
o WxYz refers to the link from Wx to Yz. o WxYz refers to the link from Wx to Yz.
o We assume that c < d + u and a < d + u (commonly agreed design o We assume that c < d + u and a < d + u (commonly agreed design
rule). rule).
o In the square access design, we assume that c < a (commonly agreed
design rule).
o In the square access design (Section 3.3), we assume that c < a
(commonly agreed design rule).
o We analyze the most frequent topologies found in an access region. o We analyze the most frequent topologies found in an access region.
o We first analyze per-prefix LFA applicability and then per-link. o We first analyze per-prefix LFA applicability and then per-link.
o The topologies are symmetric with respect to a vertical axe and o The topologies are symmetric with respect to a vertical axe and
hence we only detail the logic for the link and node failures of hence we only detail the logic for the link and node failures of
the left half of the topology. the left half of the topology.
o We do not consider SRLGs. Future revisions of the draft will
address this topic.
3.1. Triangle 3.1. Triangle
We describe the LFA applicability for the failures of each direction We describe the LFA applicability for the failures of each direction
of link C1E1, E1 and C1 (Figure 2), and for the failure of each node. of link C1E1, E1 and C1 (Figure 2), and for the failure of each node.
P P
/ \ / \
x/ \x+e x/ \x+e
/ \ / \
skipping to change at page 14, line 49 skipping to change at page 14, line 49
Four destinations are impacted when A1C1 fails: C1, A3, E3, and P. Four destinations are impacted when A1C1 fails: C1, A3, E3, and P.
A1's LFA to C1 is via A2 because eq1 == u + c < a + u. Node A1's LFA to C1 is via A2 because eq1 == u + c < a + u. Node
protection property is not applicable for traffic to C1 when C1 protection property is not applicable for traffic to C1 when C1
fails. fails.
A1's LFA to A3 is via A2 because eq1 == u + c + d < a + u + d. It is A1's LFA to A3 is via A2 because eq1 == u + c + d < a + u + d. It is
de facto node protecting as a < u + c + d (as we assumed a < u + d). de facto node protecting as a < u + c + d (as we assumed a < u + d).
Indeed A2 forwards traffic destined to A3 to C2, and C2 has a node Indeed A2 forwards traffic destined to A3 to C2, and C2 has a node
protecting LFA for A3 w.r.t the failure of C2C1, being A4, as a < u + protecting LFA for A3, for the failure of C2C1, being A4, as a < u +
c + d. Hence the cascading application of LFAs by A1 and C2 during c + d. Hence the cascading application of LFAs by A1 and C2 during
the failure of C1 provides de facto node protection. the failure of C1 provides de facto node protection.
A1's LFA to E3 is via A2 because eq1 == u + d + d < a + u + d + d. A1's LFA to E3 is via A2 because eq1 == u + d + d < a + u + d + d.
It is node protecting because eq2 == u + d + d < u + c + d + d. It is node protecting because eq2 == u + d + d < u + c + d + d.
A1's primary route to P is via C1 (even if e=0, u+x < u + c + x). A1's primary route to P is via C1 (even if e=0, u+x < u + c + x).
The LFA is via A2 because eq1 == [u + c + x < a + u + x]. This LFA The LFA is via A2 because eq1 == [u + c + x < a + u + x]. This LFA
is node protecting (from the viewpoint of A1 computing eq2) if eq2 == is node protecting (from the viewpoint of A1 computing eq2) if eq2 ==
u + x + e < u + c + x hence if e < c. u + x + e < u + c + x hence if e < c.
skipping to change at page 17, line 43 skipping to change at page 17, line 43
3.4. Extended U 3.4. Extended U
For the Extended U topology, we define the following terminology: For the Extended U topology, we define the following terminology:
C1L1: the node "C1" as seen in topology L1. C1L1: the node "C1" as seen in topology L1.
C1L2: the node "C1" as seen in topology L2. C1L2: the node "C1" as seen in topology L2.
C1LO: the loopback of C1. This loopback is in L2. C1LO: the loopback of C1. This loopback is in L2.
C2LO: the loopback of C2. This loopback is in L2.
Let us also remind that C1 and C2 are L1L2 routers and that their Let us also remind that C1 and C2 are L1L2 routers and that their
loopbacks are in L2 only. loopbacks are in L2 only.
P P
/ \ / \
x/ \x+e x/ \x+e
/ \ / \
C1<...>C2 C1<...>C2
|\ | \ |\ | \
| \ | +-------+ | \ | +-------+
skipping to change at page 18, line 27 skipping to change at page 18, line 27
d/u| \/ |d/u | / d/u| \/ |d/u | /
| / \ | |/ | / \ | |/
E1 E2 E3 E1 E2 E3
Figure 5: Extended U Figure 5: Extended U
There is no L1 link between C1 and C2. There might be an L2 link There is no L1 link between C1 and C2. There might be an L2 link
between C1 and C2. This is not relevant as this is not seen from the between C1 and C2. This is not relevant as this is not seen from the
viewpoint of the L1 topology which is the focus of our analysis. viewpoint of the L1 topology which is the focus of our analysis.
It is guaranteed that there is a path from C1L0 to C2LO within the L2 It is guaranteed that there is a path from C1LO to C2LO within the L2
topology (except if the L2 topology partitions which is very unlikely topology (except if the L2 topology partitions which is very unlikely
and hence not analyzed here). We call "c" its path cost. Once and hence not analyzed here). We call "c" its path cost. Once
again, we assume that c < a. again, we assume that c < a.
We exploit this property to create a tunnel T between C1LO and C2LO. We exploit this property to create a tunnel T between C1LO and C2LO.
Once again, as the source and destination addresses are the loopbacks Once again, as the source and destination addresses are the loopbacks
of C1 and C2 and these loopbacks are in L2 only, it is guaranteed of C1 and C2 and these loopbacks are in L2 only, it is guaranteed
that the tunnel does not transit via the L1 domain. that the tunnel does not transit via the L1 domain.
ISIS does not run over the tunnel and hence the tunnel is not used ISIS does not run over the tunnel and hence the tunnel is not used
for any primary paths within the L1 or L2 topology. for any primary paths within the L1 or L2 topology.
Within topology Level1, we configure C1 (C2) with a Level1 LFA Within Level1, we configure C1 (C2) with a Level1 LFA extended
extended neighbor "C2 via tunnel T" ("C1 via tunnel T"). neighbor "C2 via tunnel T" ("C1 via tunnel T").
A router supporting such extension learns that it has one additional A router supporting such extension learns that it has one additional
potential neighbor in topology Level1 when checking for LFA's. potential neighbor in topology Level1 when checking for LFA's.
The L1 topology learns about C1LO as an L2=>L1 route with Down bit The L1 topology learns about C1LO as an L2=>L1 route with Down bit
set propagated by C1L1 and C2L1. The metric advertised by C2L1 is set propagated by C1L1 and C2L1. The metric advertised by C2L1 is
bigger than the metric advertised by C1L1 by "c". bigger than the metric advertised by C1L1 by "c".
The L1 topology learns about P as an L2=>L1 routes with Down bit set The L1 topology learns about P as an L2=>L1 routes with Down bit set
propagated by C1L1 and C2L1. The metric advertised by C2L1 is bigger propagated by C1L1 and C2L1. The metric advertised by C2L1 is bigger
skipping to change at page 22, line 18 skipping to change at page 22, line 18
consequence, all these routing transitions cannot undergo transient consequence, all these routing transitions cannot undergo transient
forwarding loops. forwarding loops.
For example, in the square topology, the failure of directed link For example, in the square topology, the failure of directed link
A1C1 does not lead to any uLoop. The destinations reached over that A1C1 does not lead to any uLoop. The destinations reached over that
directed link are C1 and P. A1 and E1's shortest paths to these directed link are C1 and P. A1 and E1's shortest paths to these
destinations after the convergence go via A2. A2's path to C1 and P destinations after the convergence go via A2. A2's path to C1 and P
is not using A1C1 before the failure, hence no uLoop may occur. is not using A1C1 before the failure, hence no uLoop may occur.
3.8. Summary 3.8. Summary
In this section, we summarize the applicability of LFAs detailed in
the previous sections. For link protection, we use "Full" to refer
to the applicability of LFAs for each destination, reached via any
link of the topology. For node protection, we use "yes" to refer to
the fact that node protection is achieved for a given node.
1. Intra Area Destinations 1. Intra Area Destinations
Link Protection Link Protection
+ Triangle: Full + Triangle: Full
+ Full-Mesh: Full + Full-Mesh: Full
+ Square: Full, except C1 has no LFA for dest A1 + Square: Full, except C1 has no LFA for dest A1
+ Extended U: Full + Extended U: Full
Node Protection Node Protection
+ Triangle: Full + Triangle: Full
+ Full-Mesh: Full + Full-Mesh: Full
+ Square: Full + Square: Full
skipping to change at page 24, line 34 skipping to change at page 24, line 39
For the reasons explained previously, the backbone applicability For the reasons explained previously, the backbone applicability
should be analyzed on a case by case basis and it is difficult to should be analyzed on a case by case basis and it is difficult to
derive generic rules. derive generic rules.
In order to help the reader to assess the LFA applicability in its In order to help the reader to assess the LFA applicability in its
own case, we provide in the next section some simulation results own case, we provide in the next section some simulation results
based on 11 real backbone topologies. based on 11 real backbone topologies.
4.1. Simulation Framework 4.1. Simulation Framework
We usually receive the complete ISIS/OSPF linkstate database taken on In order to perform an analysis of LFA applicability in the core, we
a core router. We parse it to obtain the topology. During this usually receive the complete ISIS/OSPF linkstate database taken on a
core router. We parse it to obtain the topology. During this
process, we eliminate all nodes connected to the topology with a process, we eliminate all nodes connected to the topology with a
single link and all prefixes except a single "node address" per single link and all prefixes except a single "node address" per
router. We compute the availability of per-prefix LFA's to all these router. We compute the availability of per-prefix LFA's to all these
node addresses which we call "destinations" hereafter. We treat each node addresses which we call "destinations" hereafter. We treat each
link in each direction. link in each direction.
For each (directed) link, we compute whether we have a per-prefix LFA For each (directed) link, we compute whether we have a per-prefix LFA
to the next-hop. If so, we have a per-link LFA for the link. to the next-hop. If so, we have a per-link LFA for the link.
The Per-link-LFA coverage for a topology T is the ratio of the number The Per-link-LFA coverage for a topology T is the fraction of the
of links with a per-link LFA divided by the total number of links. number of links with a per-link LFA divided by the total number of
links.
For each link, we compute the number of destinations whose primary For each link, we compute the number of destinations whose primary
path involves the analyzed link. For each such destination, we path involves the analyzed link. For each such destination, we
compute whether a per-prefix LFA exists. compute whether a per-prefix LFA exists.
The Per-Prefix-LFA coverage for a topology T is the ratio: The Per-Prefix-LFA coverage for a topology T is the fraction:
(the sum across all links of the number of destinations with a (the sum across all links of the number of destinations with a
primary path over the link and a per-prefix LFA) primary path over the link and a per-prefix LFA)
divided by divided by
(the sum across all links of the number of destinations with a (the sum across all links of the number of destinations with a
primary path over the link) primary path over the link)
4.2. Data Set 4.2. Data Set
skipping to change at page 25, line 25 skipping to change at page 25, line 33
Our data set is based on 11 SP core topologies with different Our data set is based on 11 SP core topologies with different
geographical scopes: worldwide, national and regional. The number of geographical scopes: worldwide, national and regional. The number of
nodes range from 600 to 16. The average link-to-node ratio is 2.3 nodes range from 600 to 16. The average link-to-node ratio is 2.3
with a minimum of 1.2 and maximum of 6. with a minimum of 1.2 and maximum of 6.
4.3. Simulation results 4.3. Simulation results
+----------+--------------+----------------+ +----------+--------------+----------------+
| Topology | Per-link LFA | Per-prefix LFA | | Topology | Per-link LFA | Per-prefix LFA |
+----------+--------------+----------------+ +----------+--------------+----------------+
| T1 | 45% | 77% | | T1 | 45% | 76% |
| T2 | 49% | 99% | | T2 | 49% | 98% |
| T3 | 88% | 99% | | T3 | 88% | 99% |
| T4 | 68% | 84% | | T4 | 68% | 84% |
| T5 | 75% | 94% | | T5 | 75% | 94% |
| T6 | 87% | 99% | | T6 | 87% | 98% |
| T7 | 16% | 67% | | T7 | 16% | 67% |
| T8 | 87% | 100% | | T8 | 87% | 99% |
| T9 | 67% | 80% | | T9 | 67% | 79% |
| T10 | 98% | 100% | | T10 | 98% | 99% |
| T11 | 59% | 77% | | T11 | 59% | 77% |
| Average | 67% | 89% | | Average | 67% | 89% |
| Median | 68% | 94% | | Median | 68% | 94% |
+----------+--------------+----------------+ +----------+--------------+----------------+
Table 1: Core LFA Coverages Table 1: Core LFA Coverages
In Table 1, we observe a wide variation in terms of LFA coverage In Table 1, we observe a wide variation in terms of LFA coverage
across topologies; From 67% to 100% for the per-prefix LFA coverage, across topologies; From 67% to 100% for the per-prefix LFA coverage,
and from 16% to 98% for the per-link LFA coverage. Several and from 16% to 98% for the per-link LFA coverage. Several
skipping to change at page 27, line 32 skipping to change at page 27, line 41
7. Capacity Planning with LFA in mind 7. Capacity Planning with LFA in mind
We briefly describe the functionality a designer should expect from a We briefly describe the functionality a designer should expect from a
capacity planning tool supporting LFA and the related capacity capacity planning tool supporting LFA and the related capacity
planning process. planning process.
7.1. Coverage Estimation - Default Topology 7.1. Coverage Estimation - Default Topology
Per-Link LFA Coverage Estimation: the tool would color each Per-Link LFA Coverage Estimation: the tool would color each
unidirectional link in green or red depending on whether per-link LFA unidirectional link in depending on whether per-link LFA is available
is available or not. Per-Prefix LFA Coverage Estimation: the tool or not. Per-Prefix LFA Coverage Estimation: the tool would color
would color each unidirectional link with a colored gradient based on each unidirectional link with a colored gradient based on the % of
the % of destinations which have a per-prefix LFA. destinations which have a per-prefix LFA.
On top of the visual GUI reporting, the tool should provide detailed On top of the visual GUI reporting, the tool should provide detailed
tables listing, on a per interface basis: percentage of LFA, number tables listing, on a per interface basis: percentage of LFA, number
of prefixes with LFA, number without LFA, list of prefixes without of prefixes with LFA, number without LFA, list of prefixes without
LFA. LFA.
Furthermore, the tool should provide the percentage and list the Furthermore, the tool should provide the percentage and list the
traffic matrix demands with less than 100% source-to-destination LFA traffic matrix demands with less than 100% source-to-destination LFA
coverage, and, average coverage (#links this demand has an LFA on/# coverage, and, average coverage (#links this demand has an LFA on/#
links this demands traverses) for every demands (using a threshold). links this demands traverses) for every demands (using a threshold).
skipping to change at page 31, line 14 skipping to change at page 31, line 23
The purpose of this document was to highlight that very frequent The purpose of this document was to highlight that very frequent
access and aggregation topologies benefit from excellent link and access and aggregation topologies benefit from excellent link and
node LFA coverage. node LFA coverage.
A second objective consisted in describing the three different A second objective consisted in describing the three different
profiles of LFA applicability for the IP/MPLS core networks and profiles of LFA applicability for the IP/MPLS core networks and
illustrating them with simulation results based on real SP core illustrating them with simulation results based on real SP core
topologies. topologies.
Future versions of this document will cover additional access 11. Contributors
topologies and will describe multicast applicability.
11. Informative References This work has been realized in tight collaboration with the following
people.
Mike Shand
imc.shand@googlemail.com
Bruno Decraene
France Telecom
38-40 rue du General Leclerc
92794 Issy Moulineaux cedex 9
FR
bruno.decraene@orange.com
James Uttaro
ATT
200 S. Laurel Avenue
07748, Middletown, NJ
US
uttaro@att.com
Nicolai Leymann
Deutsche Telekom
Winterfeldtstrasse 21
10781, Berlin
DE
N.Leymann@telekom.de
Martin Horneffer
Deutsche Telekom
Hammer Str. 216-226
48153, Muenster
DE
Martin.Horneffer@telekom.de
12. Informative References
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, January 2010. RFC 5714, January 2010.
Authors' Addresses Authors' Addresses
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Brussels 1000 Brussels 1000
BE BE
Email: cf@cisco.com Email: cf@cisco.com
Pierre Francois Pierre Francois
UCLouvain Institute IMDEA Networks
Place Ste Barbe, 2 Avda. del Mar Mediterraneo, 22
Louvain-la-Neuve 1348 Leganese 28918
BE ES
Email: pierre.francois@uclouvain.be
URI: http://inl.info.ucl.ac.be/pfr
Mike Shand
Cisco Systems
Green Park, 250, Longwater Avenue,
Reading RG2 6GB
UK
Email: mshand@cisco.com
Bruno Decraene
France Telecom
38-40 rue du General Leclerc
92794 Issy Moulineaux cedex 9
FR
Email: bruno.decraene@orange-ftgroup.com
James Uttaro
ATT
200 S. Laurel Avenue
Middletown, NJ 07748
US
Email: uttaro@att.com
Nicolai Leymann
Deutsche Telekom
Winterfeldtstrasse 21
Berlin 10781
DE
Email: N.Leymann@telekom.de
Martin Horneffer
Deutsche Telekom
Hammer Str. 216-226
Muenster 48153
DE
Email: Martin.Horneffer@telekom.de Email: pierre.francois@imdea.org
 End of changes. 26 change blocks. 
98 lines changed or deleted 93 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/