draft-ietf-rtgwg-lfa-applicability-04.txt   draft-ietf-rtgwg-lfa-applicability-05.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: June 10, 2012 Institute IMDEA Networks Expires: July 14, 2012 Institute IMDEA Networks
December 8, 2011 January 11, 2012
LFA applicability in SP networks LFA applicability in SP networks
draft-ietf-rtgwg-lfa-applicability-04 draft-ietf-rtgwg-lfa-applicability-05
Abstract Abstract
In this draft, we analyze the applicability of LoopFree Alternates in In this document, we analyze the applicability of -Loop-Free
both core and access parts of Service Provider networks. We provide Alternates in both core and access parts of Service Provider
design guides to favor their applicability where relevant, typically networks. We provide design guides to favor their applicability
in the access part of the network. where relevant, typically in the access part of the network.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 10, 2012. This Internet-Draft will expire on July 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Access Network . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Access Network . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Triangle . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Triangle . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. E1C1 failure . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. E1C1 failure . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. C1E1 failure . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. C1E1 failure . . . . . . . . . . . . . . . . . . . . . 9
3.1.3. uLoop . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. uLoop . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Full-Mesh . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Full-Mesh . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 13
3.2.5. uLoop . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5. uLoop . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . 12 3.2.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Square . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Square . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 14
3.3.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 14 3.3.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 15
3.3.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 14 3.3.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 15
3.3.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 15 3.3.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 16
3.3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 16 3.3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 17
3.3.6. A square might become a full-mesh . . . . . . . . . . 17 3.3.6. A square might become a full-mesh . . . . . . . . . . 18
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 . . 18
3.4. Extended U . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Extended U . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 19 3.4.1. E1A1 failure . . . . . . . . . . . . . . . . . . . . . 20
3.4.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 19 3.4.2. A1E1 failure . . . . . . . . . . . . . . . . . . . . . 20
3.4.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 20 3.4.3. A1C1 failure . . . . . . . . . . . . . . . . . . . . . 21
3.4.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 20 3.4.4. C1A1 failure . . . . . . . . . . . . . . . . . . . . . 21
3.4.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 21 3.4.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . 21 analysis . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6. Two-tiered IGP metric allocation . . . . . . . . . . . . . 21 3.6. Two-tiered IGP metric allocation . . . . . . . . . . . . . 22
3.7. uLoop analysis . . . . . . . . . . . . . . . . . . . . . . 21 3.7. uLoop analysis . . . . . . . . . . . . . . . . . . . . . . 22
3.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Core Network . . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Core Network . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Simulation Framework . . . . . . . . . . . . . . . . . . . 24 4.1. Simulation Framework . . . . . . . . . . . . . . . . . . . 25
4.2. Data Set . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2. Data Set . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Simulation results . . . . . . . . . . . . . . . . . . . . 25 4.3. Simulation results . . . . . . . . . . . . . . . . . . . . 26
5. Core and Access protection schemes are independent . . . . . . 26 5. Core and Access protection schemes are independent . . . . . . 27
6. Simplicity and other LFA benefits . . . . . . . . . . . . . . 26 6. Simplicity and other LFA benefits . . . . . . . . . . . . . . 27
7. Capacity Planning with LFA in mind . . . . . . . . . . . . . . 27 7. Capacity Planning with LFA in mind . . . . . . . . . . . . . . 28
7.1. Coverage Estimation - Default Topology . . . . . . . . . . 27 7.1. Coverage Estimation - Default Topology . . . . . . . . . . 28
7.2. Coverage estimation in relation to traffic . . . . . . . . 28 7.2. Coverage estimation in relation to traffic . . . . . . . . 29
7.3. Coverage verification for a given set of demands . . . . . 28 7.3. Coverage verification for a given set of demands . . . . . 29
7.4. Modeling - What-if Scenarios - Coverage impact . . . . . . 28 7.4. Modeling - What-if Scenarios - Coverage impact . . . . . . 29
7.5. Modeling - What-if Scenarios - Load impact . . . . . . . . 29 7.5. Modeling - What-if Scenarios - Load impact . . . . . . . . 30
7.6. Discussion on metric recommendations . . . . . . . . . . . 29 7.6. Discussion on metric recommendations . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
12. Informative References . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
In this document, we analyze the applicability of LoopFree Alternates In this document, we analyze the applicability of Loop-Free
in both core and access parts of Service Provider networks. We Alternates (LFA) [RFC5714] [RFC5286] in both core and access parts of
provide design guides to favor their applicability where relevant, Service Provider (SP) networks. We provide design guides to favor
typically in the access part of the network. their applicability where relevant, 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
and we analyze them for LFA applicability. In Section 4, we describe and we analyze them for LFA applicability. In Section 4, we describe
a simulation framework for the study of LFA applicability in SP core a simulation framework for the study of LFA applicability in SP core
networks, and present results based on various SP networks. We then networks, and present results based on various SP networks. We then
emphasize the independence between protection schemes used in the emphasize the independence between protection schemes used in the
core and at the access level of the network. Finally we discuss the core and at the access level of the network. Finally we discuss the
key benefits of LFA which stem from its simplicity and we draw some key benefits of LFA which stem from its simplicity and we draw some
conclusions. conclusions.
2. Terminology 2. Terminology
In this document, we assume that all links to be protected are point- We use IS-IS [RFC1195] as reference. It is assumed that normal
to-point. routing (i.e., when traffic not being fast re-routed around a
failure) occurs along the shortest path. The analysis is equally
We use ISIS as reference. It is assumed that normal routing (i.e., applicable to OSPF [RFC2328] [RFC5340].
when traffic not being fast re-routed around a failure) occurs along
the shortest path. The analysis is equally applicable to OSPF.
A per-prefix LFA for a destination D at a node S is a precomputed A per-prefix LFA for a destination D at 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. In this document, we assume
that all links to be protected with LFAs are point-to-point.
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].
eq1 == ND < NS + SD
Equation eq1
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
and equation eq2 is satisfied, with eq2 == ND < NF + FD. This is in and equation eq2 is satisfied, with eq2 == ND < NF + FD. This is in
line with the definition of a Node-Protecting Alternate Next-Hop in line with the definition of a Node-Protecting Alternate Next-Hop in
[RFC5714]. [RFC5714].
eq2 == ND < NF + FD
Equation eq2
De facto node-protecting LFA: this is a link-protecting LFA that De facto node-protecting LFA: this is a link-protecting LFA that
turns out to be node-protecting. This occurs in cases illustrated by turns out to be node-protecting. This occurs in cases illustrated by
the following examples : the following examples :
o The LFA candidate that is picked by S actually satisfies Equation o The LFA candidate that is picked by S actually satisfies Equation
eq2 but S did not verify that property. The show command issued eq2 but S did not verify that property. The show command issued
by the operator would not indicate this LFA as "node protecting" by the operator would not indicate this LFA as "node protecting"
while in practice (de facto) it is. while in practice (de facto) it is.
o A cascading effect of multiple LFA's can also provide de facto o A cascading effect of multiple LFA's can also provide de facto
node protection. Equation eq2 is not satisfied, but the combined node protection. Equation eq2 is not satisfied, but the combined
activation of LFAs by some other neighbors of the failing node F activation of LFAs by some other neighbors of the failing node F
skipping to change at page 7, line 4 skipping to change at page 7, line 34
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 IS-IS level2 domain (OSPF area 0) while each access region is
in an ISIS level1 domain (OSPF non 0 area). Very often, the network confined in an IS-IS level1 domain (OSPF non 0 area). Very often,
topology within each access region is derived from a unique template the network topology within each access region is derived from a
common across the whole access network. Within an access region unique template common across the whole access network. Within an
itself, the network is made of several aggregation regions, each access region itself, the network is made of several aggregation
following the same interconnection topologies. regions, each following the same interconnection topologies.
For these reasons, in the next sections, we base the analysis of the For these reasons, in the next sections, we base the analysis of the
LFA applicability in a single access region, with the following LFA applicability in a single access region, with the following
assumptions: 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
skipping to change at page 18, line 37 skipping to change at page 19, line 37
It is guaranteed that there is a path from C1LO 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 IS-IS 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 Level1, we configure C1 (C2) with a Level1 LFA extended Within Level1, we configure C1 (C2) with a Level1 LFA 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
skipping to change at page 20, line 40 skipping to change at page 21, line 40
3.4.4. C1A1 failure 3.4.4. C1A1 failure
3.4.4.1. Per-Prefix LFA 3.4.4.1. Per-Prefix LFA
Three destinations are impacted by C1A1 link failure: A1, E1 and E2. Three destinations are impacted by C1A1 link failure: A1, E1 and E2.
E2's analysis is the same as E1 and hence is omitted. E2's analysis is the same as E1 and hence is omitted.
C1L1 has an LFA for A1 via the extended neighbor C2L1 reachable via C1L1 has an LFA for A1 via the extended neighbor C2L1 reachable via
tunnel T. Indeed, eq1 is true: d + a < d + a + u + d. From the tunnel T. Indeed, eq1 is true: d + a < d + a + u + d. From the
viewpoint of C1L1, C2L1's path to C1L1 is C2L1-A2-A1-C1L1. Remember viewpoint of C1L1, C2L1's path to C1L1 is C2L1-A2-A1-C1L1. Remember
the tunnel is not seen by ISIS for computing primary paths! Node the tunnel is not seen by IS-IS for computing primary paths! Node
protection is not applicable for traffic to A1 when A1 fails. protection is not applicable for traffic to A1 when A1 fails.
C1L1's LFA for E1 is via extended neighbor C2L1 (over tunnel T) C1L1's LFA for E1 is via extended neighbor C2L1 (over tunnel T)
because eq1 == d + d < d + a + u + d + d. Node protection is because eq1 == d + d < d + a + u + d + d. Node protection is
guaranteed because eq2 == d + d < d + a + d. guaranteed because eq2 == d + d < d + a + d.
3.4.4.2. Per-Link LFA 3.4.4.2. Per-Link LFA
C1 has a per-prefix LFA for destination A1 and hence there is a per- C1 has a per-prefix LFA for destination A1 and hence there is a per-
link LFA for the link C1A1. Node resistance is applicable for link LFA for the link C1A1. Node resistance is applicable for
skipping to change at page 24, line 40 skipping to change at page 25, line 40
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
In order to perform an analysis of LFA applicability in the core, we In order to perform an analysis of LFA applicability in the core, we
usually receive the complete ISIS/OSPF linkstate database taken on a usually receive the complete IS-IS/OSPF linkstate database taken on a
core router. We parse it to obtain the topology. During this 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.
skipping to change at page 30, line 39 skipping to change at page 31, line 39
routed backup capability of MPLS TE FRR to provide 100% protection routed backup capability of MPLS TE FRR to provide 100% protection
while ensuring no congestion along the backup paths during while ensuring no congestion along the backup paths during
protection. protection.
But when LFA provides 100% link and node protection without any But when LFA provides 100% link and node protection without any
uLoop, then clearly LFA seems a technology to consider to drastically uLoop, then clearly LFA seems a technology to consider to drastically
simplify the operation of a large-scale network. simplify the operation of a large-scale network.
8. Security Considerations 8. Security Considerations
This document does not introduce any new security considerations. The security considerations applicable to LFAs are described in
[RFC5286]. This document does not introduce any new security
considerations.
9. IANA considerations 9. IANA considerations
This draft does not require any IANA considerations. This draft does not require any IANA considerations.
10. 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
skipping to change at page 32, line 13 skipping to change at page 33, line 17
DE DE
N.Leymann@telekom.de N.Leymann@telekom.de
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226 Hammer Str. 216-226
48153, Muenster 48153, Muenster
DE DE
Martin.Horneffer@telekom.de Martin.Horneffer@telekom.de
12. Informative References 12. Acknowledgments
We would like to thank Alvaro Retana and Stewart Bryant (in bold) for
their precious comments on this work.
13. References
13.1. Normative References
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
13.2. 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
 End of changes. 20 change blocks. 
79 lines changed or deleted 112 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/