draft-ietf-rtgwg-lfa-applicability-00.txt   draft-ietf-rtgwg-lfa-applicability-01.txt 
Network Working Group Clarence Filsfils Network Working Group Clarence Filsfils
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: March 1, 2011 Pierre Francois Expires: September 14, 2011 Pierre Francois
UCLouvain UCLouvain
Mike Shand Mike Shand
Cisco Systems Cisco Systems
Bruno Decraene Bruno Decraene
France Telecom France Telecom
James Uttaro James Uttaro
ATT ATT
Nicolai Leymann Nicolai Leymann
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
August 28, 2010 March 13, 2011
LFA applicability in SP networks LFA applicability in SP networks
draft-ietf-rtgwg-lfa-applicability-00 draft-ietf-rtgwg-lfa-applicability-01
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 49 skipping to change at page 1, line 49
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 1, 2011. This Internet-Draft will expire on September 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 28 skipping to change at page 2, line 43
3.2.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 11
3.2.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 12
3.2.5. uLoop . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5. uLoop . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . 12 3.2.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Square . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Square . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 14 3.3.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 14
3.3.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 14 3.3.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 14
3.3.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 15 3.3.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 15
3.3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 16 3.3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 16
3.3.6. A square might become a full-mesh . . . . . . . . . . 16 3.3.6. A square might become a full-mesh . . . . . . . . . . 17
3.3.7. A full-mesh might be more economical than a square . . 17 3.3.7. A full-mesh might be more economical than a square . . 17
3.4. Extended U . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Extended U . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 18 3.4.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 19
3.4.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 19 3.4.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 19
3.4.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 19 3.4.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 20
3.4.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 19 3.4.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 20
3.4.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 20 3.4.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 21
3.5. Dual-plane Core and its impact on the Access LFA 3.5. Dual-plane Core and its impact on the Access LFA
analysis . . . . . . . . . . . . . . . . . . . . . . . . . 20 analysis . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6. Two-tiered IGP metric allocation . . . . . . . . . . . . . 20 3.6. Two-tiered IGP metric allocation . . . . . . . . . . . . . 21
3.7. uLoop analysis . . . . . . . . . . . . . . . . . . . . . . 21 3.7. uLoop analysis . . . . . . . . . . . . . . . . . . . . . . 21
3.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22
4. Core Network . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. Core Network . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Simulation Framework . . . . . . . . . . . . . . . . . . . 23 4.1. Simulation Framework . . . . . . . . . . . . . . . . . . . 24
4.2. Data Set . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2. Data Set . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3. Simulation results . . . . . . . . . . . . . . . . . . . . 24 4.3. Simulation results . . . . . . . . . . . . . . . . . . . . 25
5. Core and Access protection schemes are independent . . . . . . 25 5. Core and Access protection schemes are independent . . . . . . 26
6. Simplicity and other LFA benefits . . . . . . . . . . . . . . 25 6. Simplicity and other LFA benefits . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Capacity Planning with LFA in mind . . . . . . . . . . . . . . 27
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 7.1. Coverage Estimation - Default Topology . . . . . . . . . . 27
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Coverage estimation in relation to traffic . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.3. Coverage verification for a given set of demands . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 7.4. Modeling - What-if Scenarios - Coverage impact . . . . . . 28
7.5. Modeling - What-if Scenarios - Load impact . . . . . . . . 29
7.6. Discussion on metric recommendations . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
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 4, line 30 skipping to change at page 4, line 30
conclusions. conclusions.
2. Terminology 2. Terminology
In this document, we assume that all links to be protected are point- In this document, we assume that all links to be protected are point-
to-point. to-point.
We use ISIS as reference. The analysis is equally applicable to We use ISIS as reference. The analysis is equally applicable to
OSPF. OSPF.
A per-prefix LFA for a destination D for a node S is a precomputed A per-prefix LFA at a destination D for a node S is a precomputed
backup IGP nexthop for that destination. This backup IGP nexthop can backup IGP nexthop for that destination. This backup IGP nexthop can
be link protecting or node protecting. be link protecting or node protecting.
Link-protecting: A neighbor N is a link-protecting per-prefix LFA for Link-protecting: A neighbor N is a link-protecting per-prefix LFA for
S's route to D if equation eq1 is satisfied, with eq1 == ND < NS + SD S's route to D if equation eq1 is satisfied, with eq1 == ND < NS + SD
where XY refers to the IGP distance from X to Y. This is in line with where XY refers to the IGP distance from X to Y. This is in line with
the definition of an LFA in [RFC5714]. the definition of an LFA in [RFC5714].
Node-protecting: A Neighbor N is a node-protecting LFA for S's route Node-protecting: A Neighbor N is a node-protecting LFA for S's route
to D, with initial IGP nexthop F if N is a link-protecting LFA for D to D, with initial IGP nexthop F if N is a link-protecting LFA for D
skipping to change at page 5, line 17 skipping to change at page 5, line 17
activation of LFAs by some other neighbors of the failing node F activation of LFAs by some other neighbors of the failing node F
provides (de facto) node protection. In other words, it puts the provides (de facto) node protection. In other words, it puts the
dataplane in a state such that packets forwarded by S ultimately dataplane in a state such that packets forwarded by S ultimately
reach a neighbor of F that has a node-protecting LFA. Note that reach a neighbor of F that has a node-protecting LFA. Note that
in this case S cannot indicate the node-protecting behavior of the in this case S cannot indicate the node-protecting behavior of the
repair without running additional computations. repair without running additional computations.
Per-Link LFA: a per-link LFA for the link SF is one precomputed Per-Link LFA: a per-link LFA for the link SF is one precomputed
backup IGP nexthop for all the destinations reached through SF. This backup IGP nexthop for all the destinations reached through SF. This
is a neighbor of the repairing node that is a per-Prefix LFA for all is a neighbor of the repairing node that is a per-Prefix LFA for all
the prefixes that the repairing node reaches through SF. Note that the destinations that the repairing node reaches through SF. Note
such a per-link LFA exists if S has a per-prefix LFA for destination that such a per-link LFA exists if S has a per-prefix LFA for
F. destination F.
D D
/ \ / \
10 / \ 10 10 / \ 10
/ \ / \
G H----------. G H----------.
| | | | | |
1 | 1 | | 1 | 1 | |
| | | | | |
B C | 10 B C | 10
skipping to change at page 6, line 31 skipping to change at page 6, line 31
If there were a link between E and F, that E would pick as its LFA If there were a link between E and F, that E would pick as its LFA
for destination D, then E would provide de facto node protection for for destination D, then E would provide de facto node protection for
S, as upon the activation of its LFA, S would deviate traffic S, as upon the activation of its LFA, S would deviate traffic
addressed to D towards E, which in turns deviates that traffic to F, addressed to D towards E, which in turns deviates that traffic to F,
which does not reach D through C. which does not reach D through C.
F is a per-Link LFA for link SC as F reaches C via H. This per-link F is a per-Link LFA for link SC as F reaches C via H. This per-link
LFA is de facto node-protecting for destination D as F reaches D via LFA is de facto node-protecting for destination D as F reaches D via
F-H-D. F-H-D.
MicroLoop (uloop): the occurrence of a transient forwarding loop MicroLoop (uLoop): the occurrence of a transient forwarding loop
during a routing transition (as defined in [RFC5714]). during a routing transition (as defined in [RFC5714]).
In Figure 1, the loss of link SE cannot create any uloop because: In Figure 1, the loss of link SE cannot create any uLoop because:
1/The link is only used to reach destination E and 2/ S is the sole 1/The link is only used to reach destination E and 2/ S is the sole
node changing its path to E upon link SE failure. 3/ S's shortest node changing its path to E upon link SE failure. 3/ S's shortest
path to E after the failure goes via C. 4/C's best path to E (before path to E after the failure goes via C. 4/C's best path to E (before
and after link SC failure) is via CE. and after link SC failure) is via CE.
To the contrary, upon failure of link AB, a microloop may form for To the contrary, upon failure of link AB, a microloop may form for
traffic destined to B. Indeed, if A updates its FIB before S, A will traffic destined to B. Indeed, if A updates its FIB before S, A will
deviate B-destined traffic towards S, while S is still forwarding deviate B-destined traffic towards S, while S is still forwarding
this traffic to A. this traffic to A.
3. Access Network 3. Access Network
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 non0 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, we base the analysis of the LFA applicability in
the access network on the following abstract model: the access network on the following abstract model:
o We analyze a single access region. o We analyze a single access region.
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
skipping to change at page 9, line 35 skipping to change at page 9, line 35
Conclusion: all important routes with primary interface C1E1 benefit Conclusion: all important routes with primary interface C1E1 benefit
from LFA link protection. Node protection is not applicable. from LFA link protection. Node protection is not applicable.
3.1.2.2. Per-Link LFA 3.1.2.2. Per-Link LFA
We have a per-prefix LFA to E1 and hence we have a per-link LFA for We have a per-prefix LFA to E1 and hence we have a per-link LFA for
link C1E1. De facto node protection is not applicable. link C1E1. De facto node protection is not applicable.
3.1.3. uLoop 3.1.3. uLoop
The IGP convergence cannot create any uloop. See Section 3.7. The IGP convergence cannot create any uLoop. See Section 3.7.
3.1.4. Conclusion 3.1.4. Conclusion
All important intra-PoP routes benefit from LFA link and node All important intra-PoP routes benefit from LFA link and node
protection or de facto node protection. All important inter-PoP protection or de facto node protection. All important inter-PoP
routes benefit from LFA link protection. De facto node protection is routes benefit from LFA link protection. De facto node protection is
ensured if e < c (this is particularly the case for dual-plane core ensured if e < c (this is particularly the case for dual-plane core
or two-tiered-igp-metric design, see later sections). or two-tiered-igp-metric design, see later sections).
The IGP convergence does not cause any uLoop. The IGP convergence does not cause any uLoop.
skipping to change at page 10, line 49 skipping to change at page 10, line 49
The LFA to P is via A2: eq1 == u + x < d + u + u + x. Node The LFA to P is via A2: eq1 == u + x < d + u + u + x. Node
protection is guaranteed: eq2 == u+ x < a + u + x. protection is guaranteed: eq2 == u+ x < a + u + x.
Conclusion: all important intra-PoP and inter-PoP routes with primary Conclusion: all important intra-PoP and inter-PoP routes with primary
interface E1A1 benefit from LFA link and node protection. interface E1A1 benefit from LFA link and node protection.
3.2.1.2. Per-Link LFA 3.2.1.2. Per-Link LFA
We have a per-prefix LFA to A1 and hence we have a per-link LFA for We have a per-prefix LFA to A1 and hence we have a per-link LFA for
link E1A1. All impacted destinations are protected for link failure. link E1A1. All impacted destinations are protected for link failure.
De facto node protection is provided for all prefixes (except to A1 De facto node protection is provided for all destinations (except to
which is not applicable). A1 which is not applicable).
3.2.2. A1E1 failure 3.2.2. A1E1 failure
3.2.2.1. Per-Prefix LFA 3.2.2.1. Per-Prefix LFA
A1 has one single primary route via A1E1: the route to E1 (because c A1 has one single primary route via A1E1: the route to E1 (because c
< d + u). < d + u).
A1's LFA to E1 is via A2: eq1 == d < a + d. A1's LFA to E1 is via A2: eq1 == d < a + d.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
from LFA link protection. Node protection is guaranteed where from LFA link protection. Node protection is guaranteed where
applicable. applicable.
3.2.4.2. Per-Link LFA 3.2.4.2. Per-Link LFA
We have a per-prefix LFA to A1 and hence we have a per-link LFA for We have a per-prefix LFA to A1 and hence we have a per-link LFA for
link C1E1. De facto node protection is available. link C1E1. De facto node protection is available.
3.2.5. uLoop 3.2.5. uLoop
The IGP convergence cannot create any uloop. See Section 3.7. The IGP convergence cannot create any uLoop. See Section 3.7.
3.2.6. Conclusion 3.2.6. Conclusion
All important intra-PoP routes benefit from LFA link and node All important intra-PoP routes benefit from LFA link and node
protection. protection.
All important inter-PoP routes benefit from LFA link protection. All important inter-PoP routes benefit from LFA link protection.
They benefit from node protection upon failure of A nodes. They They benefit from node protection upon failure of A nodes. They
benefit from node protections upon failure of C nodes if e < c (this benefit from node protections upon failure of C nodes if e < c (this
is particularly the case for dual-plane core or two-tiered-igp-metric is particularly the case for dual-plane core or two-tiered-igp-metric
skipping to change at page 15, line 50 skipping to change at page 15, line 50
Conclusion: all important intra-PoP routes with primary interface Conclusion: all important intra-PoP routes with primary interface
A1C1 except A1 benefit from LFA link protection and node protection. A1C1 except A1 benefit from LFA link protection and node protection.
3.3.4.2. Per-Link LFA 3.3.4.2. Per-Link LFA
C1 does not have a per-prefix LFA for destination A1 and hence there C1 does not have a per-prefix LFA for destination A1 and hence there
is no per-link LFA for the link C1A1. is no per-link LFA for the link C1A1.
3.3.4.3. Assumptions on the values of c and a 3.3.4.3. Assumptions on the values of c and a
If c > a, then C1 would have a per-prefix LFA for A1 and hence link The commonly agreed design rule (c < a) is especially beneficial for
C1A1 would have a per-link LFA. However, in that case, A1 would no a deployment using per-link LFA: it provides a per-link LFA for the
longer have a per-prefix LFA for C1 and hence A1 would no longer have
a per-link LFA for the link A1C1.
The commonly agreed design rule (c < a) is beneficial for a
deployment using per-link LFA: it provides a per-link LFA for the
most important direction (A1C1). Indeed, there are many more most important direction (A1C1). Indeed, there are many more
prefixes reachable over A1C1 then over C1A1. As the IGP convergence destinations reachable over A1C1 than over C1A1. As the IGP
duration is proportional to the number of routes to update, there is convergence duration is proportional to the number of routes to
a better benefit in leveraging LFA FRR for the link A1C1 than the update, there is a better benefit in leveraging LFA FRR for the link
link C1A1. A1C1 than the link C1A1.
Note as well that the consequence of this assumption is much more Note as well that the consequence of this assumption is much more
important for per-link LFA than for per-prefix LFA. important for per-link LFA than for per-prefix LFA.
For per-prefix LFA, in case of link C1A1 failure, we do have a per- For per-prefix LFA, in case of link C1A1 failure, we do have a per-
prefix LFA for E1, E2 and any node subtended below A1 and A2. prefix LFA for E1, E2 and any node subtended below A1 and A2.
Typically most of the traffic traversing the link C1A1 is directed to Typically most of the traffic traversing the link C1A1 is directed to
these E nodes and hence the lack of per-prefix LFA for the these E nodes and hence the lack of per-prefix LFA for the
destination A1 might be insignificant. This is a good example of the destination A1 might be insignificant. This is a good example of the
coverage benefit of per-prefix LFA over per-link LFA. coverage benefit of per-prefix LFA over per-link LFA.
Finally note that c = a is the worst choice as in this case there C1 In the remainder of this section we analyze the consequence of not
has no per-prefix LFA for A1 (and vice versa) and hence there is no having c < a.
per-link LFA for C1A1 and A1C1.
It definitely has a negative impact upon per-link LFA.
With c >= a, C1A1 has a per-link LFA while A1C1 has no per-link LFA.
The number of destinations impacted by A1C1 failure is much larger
than the direction C1A1 and hence the protection is provided for the
wrong direction.
For per-prefix LFA, the availability of an LFA depends on the
topology and needs to be assessed individually for each per-prefix.
Some backbone topologies will lead to very good protection coverage,
some others might provide very poor coverage.
More specifically, the coverage upon A1C1 failure of a remote
destination P depends on whether e < a. In such case, A2 is a de-
facto node-protecting per-prefix LFA for P.
Such a study likely requires a planning tool as each remote
destination P would have a different e value (exception: all the edge
devices of other aggregation pairs within the same region as for
these e=0 by definition, e.g. E3).
Finally note that c = a is the worst choice as in this case C1 has no
per-prefix LFA for A1 (and vice versa) and hence there is no per-link
LFA for C1A1 and A1C1.
3.3.5. Conclusion 3.3.5. Conclusion
All important intra-PoP routes benefit from LFA link and node All important intra-PoP routes benefit from LFA link and node
protection with one exception: C1 has no per-prefix LFA to A1. protection with one exception: C1 has no per-prefix LFA to A1.
All important inter-PoP routes benefit from LFA link protection. All important inter-PoP routes benefit from LFA link protection.
They benefit from node protection if e < c. They benefit from node protection if e < c.
Per-link LFA provides the same protection coverage as per-prefix LFA Per-link LFA provides the same protection coverage as per-prefix LFA
skipping to change at page 21, line 10 skipping to change at page 21, line 36
3.6. Two-tiered IGP metric allocation 3.6. Two-tiered IGP metric allocation
A Two-tiered IGP metric allocation scheme is defined as follows A Two-tiered IGP metric allocation scheme is defined as follows
o all the link metrics used in the L2 domain are part of range R1 o all the link metrics used in the L2 domain are part of range R1
o all the link metrics used in an L1 domain are part of range R2 o all the link metrics used in an L1 domain are part of range R2
o range R1 << range R2 such that the difference e = C2P - C1P is o range R1 << range R2 such that the difference e = C2P - C1P is
smaller than any link metric within an access region. smaller than any link metric within an access region.
Assuming such an IGP metric allocation, the following properties are Assuming such an IGP metric allocation, the following properties are
guaranteed: c < a and e < c. guaranteed : c < a, e < c, and e < a.
3.7. uLoop analysis 3.7. uLoop analysis
In this section, we analyze a case where the routing transition In this section, we analyze a case where the routing transition
following the failure of a link may have some uLoop potential for one following the failure of a link may have some uLoop potential for one
destination. Then we show that all the other cases do not have uLoop destination. Then we show that all the other cases do not have uLoop
potential. potential.
In the square design, upon the failure of link C1A1, traffic In the square design, upon the failure of link C1A1, traffic
addressed to A1 can undergo a transient forwarding loop as C1 addressed to A1 can undergo a transient forwarding loop as C1
skipping to change at page 21, line 27 skipping to change at page 22, line 4
potential. potential.
In the square design, upon the failure of link C1A1, traffic In the square design, upon the failure of link C1A1, traffic
addressed to A1 can undergo a transient forwarding loop as C1 addressed to A1 can undergo a transient forwarding loop as C1
reroutes traffic to C2, which initially reaches A1 through C1, as c < reroutes traffic to C2, which initially reaches A1 through C1, as c <
a. This loop will actually occur when C1 updates its FIB for a. This loop will actually occur when C1 updates its FIB for
destination A1 before C2. destination A1 before C2.
It can be shown that all the other routing transitions following a It can be shown that all the other routing transitions following a
link failure in the analyzed topologies do not have uLoop potential. link failure in the analyzed topologies do not have uLoop potential.
Indeed, in each case, for all destinations affected by the failure, Indeed, in each case, for all destinations affected by the failure,
the rerouting nodes deviate their traffic directly to adjacent nodes the rerouting nodes deviate their traffic directly to adjacent nodes
whose paths towards these destinations do not change. As a whose paths towards these destinations do not change. As a
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
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
skipping to change at page 22, line 16 skipping to change at page 22, line 40
Link Protection Link Protection
+ Triangle: Full + Triangle: Full
+ Full-Mesh: Full + Full-Mesh: Full
+ Square: Full + Square: Full
+ Extended U: Full + Extended U: Full
Node Protection Node Protection
+ Triangle: yes if e<c + Triangle: yes if e<c
+ Full-Mesh: yes for A failure, if e<c for C failure + Full-Mesh: yes for A failure, if e<c for C failure
+ Square: yes for A failure, if e<c for C failure + Square: yes for A failure, if e<c for C failure
+ Extended U : yes if e<= c and c < a + Extended U : yes if e<= c and c < a
3. ULoops 3. uLoops
* Triangle: None * Triangle: None
* Full-Mesh: None * Full-Mesh: None
* Square: None, except traffic to A1 when C1A1 fails * Square: None, except traffic to A1 when C1A1 fails
* Extended U : None, if a > e * Extended U : None, if a > e
4. Per-Link LFA vs Per-Prefix LFA 4. Per-Link LFA vs Per-Prefix LFA
* Triangle: Same * Triangle: Same
* Full-Mesh: Same * Full-Mesh: Same
* Square: Same except C1A1 has no per-Link LFA. In practice, * Square: Same except C1A1 has no per-Link LFA. In practice,
this means that per-prefix LFAs will be used (hence C1 has no this means that per-prefix LFAs will be used (hence C1 has no
LFA for dest=E1 and dest=A1) LFA for dest=E1 and dest=A1)
skipping to change at page 23, line 4 skipping to change at page 23, line 29
Also, the capacity planning process is already complex in the Also, the capacity planning process is already complex in the
backbone. It needs to make sure that the traffic matrix (demand) is backbone. It needs to make sure that the traffic matrix (demand) is
supported by the underlying network (capacity) under all possible supported by the underlying network (capacity) under all possible
variation of the underlying network (what-if scenario related to one- variation of the underlying network (what-if scenario related to one-
srlg failure). Classically, "supported" means that no congestion be srlg failure). Classically, "supported" means that no congestion be
experienced and that the demands be routed along the appropriate experienced and that the demands be routed along the appropriate
latency paths. Selecting LFA as a deterministic FRR solution for the latency paths. Selecting LFA as a deterministic FRR solution for the
backbone would require to enhance the capacity planning process to backbone would require to enhance the capacity planning process to
add a third constraint: each variation of the underlying network add a third constraint: each variation of the underlying network
should lead to a sufficient LFA coverage. should lead to a sufficient LFA coverage (we detail this aspect in a
following section).
To the contrary, the access network is based on many replications of To the contrary, the access network is based on many replications of
a small number of well-known (well-engineered) topologies. The LFA a small number of well-known (well-engineered) topologies. The LFA
coverage is deterministic and is independent of additions/insertions coverage is deterministic and is independent of additions/insertions
of a new edge device, a new aggregation sub-region or a new access of a new edge device, a new aggregation sub-region or a new access
region. region.
In practice, we believe that there are three profiles for the In practice, we believe that there are three profiles for the
backbone applicability of LFA. backbone applicability of LFA.
skipping to change at page 23, line 26 skipping to change at page 24, line 4
on IGP convergence. In such case, LFA is a free bonus. If an LFA is on IGP convergence. In such case, LFA is a free bonus. If an LFA is
available, then the loss of connectivity is likely reduced by a available, then the loss of connectivity is likely reduced by a
factor 10 (50msec vs 500msec), else the loss of connectivity depends factor 10 (50msec vs 500msec), else the loss of connectivity depends
on IGP convergence which is anyway the initial target. LFA should be on IGP convergence which is anyway the initial target. LFA should be
very successful here as it provides a significant improvement without very successful here as it provides a significant improvement without
any additional cost. any additional cost.
In the second profile, the designer seeks a very high and In the second profile, the designer seeks a very high and
deterministic FRR coverage and he either does not want or cannot deterministic FRR coverage and he either does not want or cannot
engineer the topology. LFA should not be considered in this case. engineer the topology. LFA should not be considered in this case.
MPLS TE FRR would perform much better in this environment. Explicit MPLS TE FRR would perform much better in this environment. Explicit
routing ensures that a backup path exists what-ever the underlying routing ensures that a backup path exists what-ever the underlying
topology. topology.
In the third profile, the designer seeks a very high and In the third profile, the designer seeks a very high and
deterministic FRR coverage and he does engineer the topology. LFA is deterministic FRR coverage and he does engineer the topology. LFA is
appealing in this scenario as it can provide a very simple way to appealing in this scenario as it can provide a very simple way to
obtain protection. obtain protection. Furthermore, in practice, the requirement for FRR
coverage might be limited to a certain part of the network, given by
a sub-topology and/or is likely limited to a subset of the demands
within the traffic matrix. In such case, if the relevant part of the
network natively provides a high degree of LFA protection for the
demands of interest, it might actually be straightforward to improve
the topology and achieve the level of protection required for the
sub-topology and demands which matter. Once again, the practical
problem needs to be considered (which sub-topology, which real
demands need 50msec) as it is often simpler than the theoretical
generic one.
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
skipping to change at page 25, line 47 skipping to change at page 26, line 37
Thanks to this integration, the use of multiple areas in the IGP does Thanks to this integration, the use of multiple areas in the IGP does
not make Fast Restoration more complex to achieve than in a single not make Fast Restoration more complex to achieve than in a single
area IGP design. area IGP design.
There is no requirement for network-wide upgrade as LFAs do not There is no requirement for network-wide upgrade as LFAs do not
require any protocol change and hence can be deployed router by require any protocol change and hence can be deployed router by
router. router.
With LFAs, the backup paths are pre-computed and installed in the With LFAs, the backup paths are pre-computed and installed in the
dataplane in advance of the failure. Assuming a fast enough FIB dataplane in advance of the failure. Assuming a fast enough FIB
update time compared to the total number of (important) prefixes, a update time compared to the total number of (important) destinations,
"<50msec repair" requirement becomes achievable. With a prefix- a "<50msec repair" requirement becomes achievable. With a prefix-
independent implementation, LFAs have a fixed repair time, as it only independent implementation, LFAs have a fixed repair time, as it only
depends on the failure detection time and the time to activate the depends on the failure detection time and the time to activate the
LFA behavior, which does not scale with the number of prefixes to be LFA behavior, which does not scale with the number of destinations to
fast rerouted. be fast rerouted.
Link and node protection are provided together and without Link and node protection are provided together and without
operational difference (as a comparison, MPLS TE FRR link and node operational difference (as a comparison, MPLS TE FRR link and node
protections require different types of backup tunnels and different protections require different types of backup tunnels and different
grades of operational complexity). grades of operational complexity).
Also, compared to MPLS TE FRR, an important simplicity aspect of LFA
is that is does not require the introduction of yet another virtual
layer of topology. Maintaining a virtual topology of explicit MPLS
TE tunnels clearly increases the complexity of the network. MPLS TE
tunnels would have to be represented in a network management system
in order to be monitored and managed. In large networks this may
significantly contribute to the number of network entities polled by
the network management system and monitored by operational staff.
LFA on the other hand only has to be monitored for its operational
status once per router and it needs to be considered in the network
planning process. If the latter is done based on offline simulations
for failure cases anyways, the incremental cost of supporting LFA for
a defined set of demands may be relatively low.
The per-prefix mode of LFAs allows for a simpler and more efficient The per-prefix mode of LFAs allows for a simpler and more efficient
capacity planning. As the backup path of each prefix is optimized capacity planning. As the backup path of each destination is
individually, the load to be fast rerouted can be spread on a set of optimized individually, the load to be fast rerouted can be spread on
shortest-repair-paths (as opposed to one single backup tunnel). This a set of shortest-repair-paths (as opposed to one single backup
leads for a simpler and more efficient capacity planning process that tunnel). This leads for a simpler and more efficient capacity
takes congestion during protection into account. planning process that takes congestion during protection into
account.
7. Security Considerations 7. Capacity Planning with LFA in mind
We briefly describe the functionality a designer should expect from a
capacity planning tool supporting LFA and the related capacity
planning process.
7.1. Coverage Estimation - Default Topology
Per-Link LFA Coverage Estimation: the tool would color each
unidirectional link in green or red depending on whether per-link LFA
is available or not. Per-Prefix LFA Coverage Estimation: the tool
would color each unidirectional link with a colored gradient based on
the % of destinations which have a per-prefix LFA.
On top of the visual GUI reporting, the tool should provide detailed
tables listing, on a per interface basis: percentage of LFA, number
of prefixes with LFA, number without LFA, list of prefixes without
LFA.
Furthermore, the tool should provide the percentage and list the
traffic matrix demands with less than 100% source-to-destination LFA
coverage, and, average coverage (#links this demand has an LFA on/#
links this demands traverses) for every demands (using a threshold).
The user should be able to alter the color scheme to show whether
these LFAs are guaranteed-node-protecting or de-facto node protecting
or only link protecting.
This functionality provides the same level of information as we
described in sections 4.1 to 4.3.
7.2. Coverage estimation in relation to traffic
Instead of reporting the coverage as a ratio of the number of
destinations with a backup, one might prefer a ratio of the amount of
traffic on a link that benefits from protection.
This is likely much more relevant as not all destinations are equal
and it is much more important to have an LFA for a destination
attracting lots of traffic rather than an unpopular destination.
7.3. Coverage verification for a given set of demands
Depending on the requirements on the network it might be more
relevant to verify the complete LFA coverage of a given sub-topology,
or a given set of demands, rather than calculating the relative
coverage of the overall traffic. This is most likely true for the
third engineering profile described in Section 4.
In that case, the tool should be able to separately report the LFA
coverage on a given set of demands and highlight each part of the
network that does not support 100% coverage for any of those demands.
7.4. Modeling - What-if Scenarios - Coverage impact
The tool should be able to compute the coverage for all the possible
topologies that result from a set of expected failures (ie. one-srlg
failure).
Filtering the key information from the huge amount of generated data
should be a key property of the tool.
For example, the user could set a threshold (at least 80% per-prefix
LFA coverage in all one-srlg what-if scenarios) and the tool would
report only the cases where this condition is not met, hopefully with
some assistance on how to remedy the problem (IGP metric
optimization).
As an application example, a designer who is not able to ensure c < a
could leverage such a tool to assess the per-prefix LFA coverage for
square aggregation topologies grafted to its core backbone topology.
The tool would analyze the per-prefix LFA availability for each
remote destination and would help optimize the backbone topology to
increase the LFA protection coverage for failures within the square
aggregation topologies.
7.5. Modeling - What-if Scenarios - Load impact
The tool should be able to compute the link load for all routing
states that result from a set of expected failures (i.e. one-srlg
failure).
The routing states that should be supported are: 1/ network-wide
converged state before the failure, 2/ all the LFA's protecting the
failure are active and 3/ network-wide converged state after the
failure.
Filtering the key information from the huge amount of generated data
should be a key property of the tool.
For example, the user could set a threshold (at most 100% link load
in all one-srlg what-if scenarios) and the tool would report only the
cases where this condition is violated, hopefully with some
assistance on how to remedy the problem (IGP metric optimization).
The tool should be able to do this for the aggregate load and as well
on a per class of service basis.
Note: in case the traffic matrix is unknown, an intermediate solution
consists in identifying the destinations that would attract traffic
(i.e. PE routers), and those that would not (i.e. P routers). You
could achieve this by creating a traffic matrix with equal demands
between the sources/destinations that would attract traffic (Pe to
PE). This will be more relevant than considering all demands between
all prefixes (e.g. when there is no customer traffic from P to P).
7.6. Discussion on metric recommendations
While LFA FRR has many benefits (section 6), LFA FRR's applicability
depends on topology.
The purpose of this document is to show how to introduce a level of
control on this topology parameter.
On the one hand, we wanted to show that by adopting a small set of
igp metric constraints and a repetition of well-behaved patterns, the
designer could deterministically guarantee maximum link and node
protection for the vast majority of the network (the access/
aggregation). Doing so, he would obtain an extremely simple
resiliency solution.
One another side, we also wanted to show that it might not be so bad
to not apply (all) these constraints.
Indeed, we showed in section 3.3.4.3 that the per-prefix LFA coverage
in a square where c > a might still be very good.
We showed in section 4.3 that the median per-prefix LFA coverage for
11 SP backbone topologies still provides for 94% coverage (most of
these topologies were built without any idea of LFA)!
Furthermore, we showed that any topology may be analyzed with an LFA-
aware capacity planning tool. This would readily assess the coverage
of per-prefix LFA and would assist the designer in fine-tuning it to
obtain the level of protection he seeks.
While this document highlighted LFA applicability and benefits for SP
network, it also noted that LFA is not meant to replace MPLS TE FRR.
With a very-LFA-unfriendly topology, a designer seeking a guaranteed
< 50msec protection might be better off leveraging the explicit-
routed backup capability of MPLS TE FRR to provide 100% protection
while ensuring no congestion along the backup paths during
protection.
But when LFA provides 100% link and node protection without any
uLoop, then clearly LFA seems a technology to consider to drastically
simplify the operation of a large-scale network.
8. Security Considerations
This document does not introduce any new security considerations. This document does not introduce any new security considerations.
8. IANA considerations 9. IANA considerations
This draft does not require any IANA considerations. This draft does not require any IANA considerations.
9. Conclusions 10. Conclusions
LFA is an important protection alternative for IP/MPLS networks. LFA is an important protection alternative for IP/MPLS networks.
Its simplicity benefit is significant, in terms of automation and Its simplicity benefit is significant, in terms of automation and
integration with the default IGP behavior and the absence of any integration with the default IGP behavior and the absence of any
requirement for network-wide upgrade. The technology does not requirement for network-wide upgrade. The technology does not
require any protocol change and hence can be deployed router by require any protocol change and hence can be deployed router by
router. router.
At first sight, these significant simplicity benefits are negated by At first sight, these significant simplicity benefits are negated by
skipping to change at page 27, line 8 skipping to change at page 31, line 17
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 Future versions of this document will cover additional access
topologies and will describe multicast applicability. topologies and will describe multicast applicability.
10. References 11. 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
skipping to change at page 27, line 38 skipping to change at page 32, line 4
Email: pierre.francois@uclouvain.be Email: pierre.francois@uclouvain.be
URI: http://inl.info.ucl.ac.be/pfr URI: http://inl.info.ucl.ac.be/pfr
Mike Shand Mike Shand
Cisco Systems Cisco Systems
Green Park, 250, Longwater Avenue, Green Park, 250, Longwater Avenue,
Reading RG2 6GB Reading RG2 6GB
UK UK
Email: mshand@cisco.com Email: mshand@cisco.com
Bruno Decraene Bruno Decraene
France Telecom France Telecom
38-40 rue du General Leclerc 38-40 rue du General Leclerc
92794 Issi Moulineaux cedex 9 92794 Issy Moulineaux cedex 9
FR FR
Email: bruno.decraene@orange-ftgroup.com Email: bruno.decraene@orange-ftgroup.com
James Uttaro James Uttaro
ATT ATT
200 S. Laurel Avenue 200 S. Laurel Avenue
Middletown, NJ 07748 Middletown, NJ 07748
US US
Email: uttaro@att.com Email: uttaro@att.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
skipping to change at page 28, line 18 skipping to change at page 32, line 26
US US
Email: uttaro@att.com Email: uttaro@att.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
Winterfeldtstrasse 21 Winterfeldtstrasse 21
Berlin 10781 Berlin 10781
DE DE
Email: nicolai.leymann@t-systems.com Email: N.Leymann@telekom.de
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226 Hammer Str. 216-226
Muenster 48153 Muenster 48153
DE DE
Email: Martin.Horneffer@t-com.net Email: Martin.Horneffer@telekom.de
 End of changes. 42 change blocks. 
71 lines changed or deleted 274 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/