draft-ietf-rtgwg-remote-lfa-09.txt   draft-ietf-rtgwg-remote-lfa-10.txt 
Network Working Group S. Bryant Network Working Group S. Bryant
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track S. Previdi Intended status: Standards Track S. Previdi
Expires: June 19, 2015 Cisco Systems Expires: July 10, 2015 Cisco Systems
M. Shand M. Shand
Independent Contributor Independent Contributor
N. So N. So
Vinci Systems Vinci Systems
December 16, 2014 January 6, 2015
Remote LFA FRR Remote Loop-Free Alternate Fast Re-Route
draft-ietf-rtgwg-remote-lfa-09 draft-ietf-rtgwg-remote-lfa-10
Abstract Abstract
This draft describes an extension to the basic IP fast re-route This document describes an extension to the basic IP fast re-route
mechanism described in RFC5286, that provides additional backup mechanism described in RFC5286, that provides additional backup
connectivity for point to point link failures when none can be connectivity for point to point link failures when none can be
provided by the basic mechanisms. provided by the basic mechanisms.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 19, 2015. This Internet-Draft will expire on July 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 43 skipping to change at page 2, line 43
4.4. Interactions with IS-IS Overload, RFC6987, and Costed 4.4. Interactions with IS-IS Overload, RFC6987, and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 16 Out Links . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Example Application of Remote LFAs . . . . . . . . . . . . . 17 5. Example Application of Remote LFAs . . . . . . . . . . . . . 17
6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Operation in an LDP environment . . . . . . . . . . . . . . . 19 7. Operation in an LDP environment . . . . . . . . . . . . . . . 19
8. Analysis of Real World Topologies . . . . . . . . . . . . . . 20 8. Analysis of Real World Topologies . . . . . . . . . . . . . . 20
8.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21 8.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21
8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. LFA only . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 23 8.4. Comparison of LFA an RLFA results . . . . . . . . . . . . 23
9. Management Considerations . . . . . . . . . . . . . . . . . . 24 9. Management and Operational Considerations . . . . . . . . . . 24
10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 25 10. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1. Normative References . . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . 26
14.2. Informative References . . . . . . . . . . . . . . . . . 26 14.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Terminology 1. Terminology
This draft uses the terms defined in [RFC5714]. This section defines This document uses the terms defined in [RFC5714]. This section
additional terms used in this draft. defines additional terms that are used in this document.
FIB Forwarding Information (data)Base. The database used FIB Forwarding Information (data)Base. The database used
by a packet forwarder to determine the actions it by a packet forwarder to determine the actions it
should take on a packet it is processing. should take on a packet it is processing.
Repair tunnel A tunnel established for the purpose of providing a Repair tunnel A tunnel established for the purpose of providing a
virtual neighbor which is a Loop Free Alternate. virtual neighbor which is a Loop Free Alternate.
P-space P-space is the set of routers reachable from a P-space P-space of a router with respect to a protected link
specific router using the normal FIB, without any path is the set of routers reachable from that specific
(including equal cost path splits) transiting the router using the pre-convergence FIB, without any path
(including equal cost path splits) transiting that
protected link. protected link.
For example, the P-space of S with respect to link For example, the P-space of S with respect to link
S-E, is the set of routers that S can reach without S-E, is the set of routers that S can reach without
using the protected link S-E. using the protected link S-E.
Extended P-space Extended P-space
The union of the P-space of the neighbours of a Consider the set of neighbours of a router protecting
specific router with respect to the protected link a link. Exclude from that set of routers the router
(see Section 4.2.1.2). reachable over the protected link. The extended
P-space of the protecting router with respect to the
protected link is the union of the P-spaces of the
neighbours in that set of neighbours with respect to
the protected link (see Section 4.2.1.2).
Q-space Q-space is the set of routers from which a specific Q-space Q-space of a router with respect to a protected link
router can be reached without any path (including is the set of routers from which that specific router
equal cost path splits) transiting the protected link. can be reached without any path (including equal cost
path splits) transiting that protected link.
PQ node A node which is a member of both the P-space and the PQ node A PQ node of a node S with respect to a protected link
Q-space. Where extended P-space is in use it is a S-E is a node which is a member of both the P-space
node which is a member of both the extended P-space (or the extended P-space) of S with respect to that
and the Q-space. In remote LFA this is used as the protected link S-E and the Q-space of E with respect
repair tunnel endpoint. to that protected link S-E. A repair tunnel endpoint
is chosen from the set of PQ-nodes.
Remote LFA (RLFA) The use of a PQ node rather than a neighbour of Remote LFA (RLFA) The use of a PQ node rather than a neighbour of
the repairing node as the next hop in an LFA repair. the repairing node as the next hop in an LFA repair
[RFC5286].
In this document we use the notation X-Y to mean the path from X to Y In this document we use the notation X-Y to mean the path from X to Y
over the link directly connecting X and Y, whilst the notation X->Y over the link directly connecting X and Y, whilst the notation X->Y
refers to the shortest path from X to Y via some set of unspecified refers to the shortest path from X to Y via some set of unspecified
nodes including the null set (i.e. including over a link directly nodes including the null set (i.e. Including over a link directly
connecting X and Y). connecting X and Y).
2. Introduction 2. Introduction
RFC 5714 [RFC5714] describes a framework for IP Fast Re-route and RFC 5714 [RFC5714] describes a framework for IP Fast Re-route (IPFRR)
provides a summary of various proposed IPFRR solutions. A basic and provides a summary of various proposed IPFRR solutions. A basic
mechanism using loop-free alternates (LFAs) is described in [RFC5286] mechanism using loop-free alternates (LFAs) is described in [RFC5286]
that provides good repair coverage in many topologies [RFC6571], that provides good repair coverage in many topologies [RFC6571],
especially those that are highly meshed. However, some topologies, especially those that are highly meshed. However, some topologies,
notably ring based topologies are not well protected by LFAs alone. notably ring based topologies are not well protected by LFAs alone.
This is illustrated in Figure 1 below. This is illustrated in Figure 1 below.
S---E S---E
/ \ / \
A D A D
\ / \ /
B---C B---C
Figure 1: A simple ring topology Figure 1: A simple ring topology
If all link costs are equal, the link S-E cannot be fully protected If all link costs are equal, traffic transiting link S-E cannot be
by LFAs. The destination C is an ECMP from S, and so can be fully protected by LFAs. The destination C is an ECMP from S, and so
protected when S-E fails, but D and E are not protectable using LFAs. traffic to C can be protected when S-E fails, but traffic to D and E
are not protectable using LFAs.
This draft describes extensions to the basic repair mechanism in This document describes extensions to the basic repair mechanism in
which tunnels are used to provide additional logical links which can which tunnels are used to provide additional logical links which can
then be used as loop free alternates where none exist in the original then be used as loop free alternates where none exist in the original
topology. In Figure 1 S can reach A, B, and C without going via E; topology. In Figure 1 S can reach A, B, and C without going via S-E;
these form S's extended P-space. The routers that can reach E these form S's extended P-space with respect to S-E. The routers
without going through S-E will be E's Q-space; these are D and C. B that can reach E without going through S-E will be E's Q-space; these
has equal-cost paths via B-A-S-E and B-C-D-E and so may go through are D and C. B has equal-cost paths via B-A-S-E and B-C-D-E and so
S-E. The single node in both S's extended P-space and E's Q-space is may go through S-E. The single node in both S's extended P-space and
C; thus node C is selected as the repair tunnel's end-point. Thus, E's Q-space is C; thus node C is selected as the repair tunnel's end-
if a tunnel is provided between S and C as shown in Figure 2 then C, point. Thus, if a tunnel is provided between S and C as shown in
now being a direct neighbor of S would become an LFA for D and E. Figure 2 then C, now being a direct neighbor of S would become an LFA
The definition of (extended-)P space and Q space are provided in for D and E. The definition of (extended-)P space and Q space are
Section 1 and details of the calculation of the tunnel end points is provided in Section 1 and details of the calculation of the tunnel
provided in Section 4.2. end points is provided in Section 4.2.
The non-failure traffic distribution is not disrupted by the The non-failure traffic distribution is not disrupted by the
provision of such a tunnel since it is only used for repair traffic provision of such a tunnel since it is only used for repair traffic
and MUST NOT be used for normal traffic. Note that OAM traffic and MUST NOT be used for normal traffic. Note that OAM traffic
specifically to verify the viability of the repair MAY traverse the specifically to verify the viability of the repair MAY traverse the
tunnel prior to a failure. tunnel prior to a failure.
S---E S---E
/ \ \ / \ \
A \ D A \ D
skipping to change at page 15, line 25 skipping to change at page 15, line 25
// Extend P-space to the P-spaces of all reachable // Extend P-space to the P-spaces of all reachable
// neighbours // neighbours
foreach interface intf in self foreach interface intf in self
// Exclude failed interface, noting that // Exclude failed interface, noting that
// the node reachable via that interface may be // the node reachable via that interface may be
// reachable via another interface (parallel path) // reachable via another interface (parallel path)
if (intf != fail_intf) if (intf != fail_intf)
foreach neighbor n in intf.remote_node foreach neighbor n in intf.remote_node
// Apply RFC5286 Inequality 1 // Apply RFC5286 Inequality 1
if ( D_opt(n, y) < if ( D_opt(n, y) <
D_opt(n,self) + D_opt)(self, y) D_opt(n,self) + D_opt(self, y))
y.in_extended_P_space = true y.in_extended_P_space = true
///////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////
// //
// Compute the nodes in Q-space // Compute the nodes in Q-space
// //
Compute_Q_Space(fail_intf) Compute_Q_Space(fail_intf)
// Compute the cost from every node the network to the // Compute the cost from every node the network to the
// node normally reachable across the failed link // node normally reachable across the failed link
skipping to change at page 18, line 15 skipping to change at page 18, line 15
| 100 | | 100 |
-P1---------P2- -P1---------P2-
\ / \ /
1000 \ / 1000 1000 \ / 1000
PE1---PE2 PE1---PE2
5 5
Figure 3: Example SP topology Figure 3: Example SP topology
Clearly, full protection can be provided, using the techniques Clearly, full protection can be provided, using the techniques
described in this draft, by PE1 choosing P2 as the remote LFA repair described in this document, by PE1 choosing P2 as the remote LFA
target node, and PE2 choosing P1 as the remote LFA repair target. repair target node, and PE2 choosing P1 as the remote LFA repair
target.
6. Node Failures 6. Node Failures
When the failure is a node failure rather than a point-to-point link When the failure is a node failure rather than a point-to-point link
failure there is a danger that the RLFA repair will loop. This is failure there is a danger that the RLFA repair will loop. This is
discussed in detail in [I-D.bryant-ipfrr-tunnels]. In summary the discussed in detail in [I-D.bryant-ipfrr-tunnels]. In summary the
problem is that two of more of E's neighbors each with E as the next problem is that two of more of E's neighbors each with E as the next
hop to some destination D may attempt to repair a packet addressed to hop to some destination D may attempt to repair a packet addressed to
destination D via the other neighbor and then E, thus causing a loop destination D via the other neighbor and then E, thus causing a loop
to form. A similar problem exists in the case of a shared risk link to form. A similar problem exists in the case of a shared risk link
skipping to change at page 24, line 39 skipping to change at page 24, line 39
always present as a property of an LDP-based deployment. always present as a property of an LDP-based deployment.
In the small number of cases where there is no intersection between In the small number of cases where there is no intersection between
the (extended)P-space and the Q-space, a number of solutions to the (extended)P-space and the Q-space, a number of solutions to
providing a suitable path between such disjoint regions in the providing a suitable path between such disjoint regions in the
network have been discussed in the working group. For example an network have been discussed in the working group. For example an
explicitly routed LSP between P and Q might be set up using RSVP-TE explicitly routed LSP between P and Q might be set up using RSVP-TE
or using Segment Routing [I-D.filsfils-spring-segment-routing]. Such or using Segment Routing [I-D.filsfils-spring-segment-routing]. Such
extended repair methods are outside the scope of this document. extended repair methods are outside the scope of this document.
9. Management Considerations 9. Management and Operational Considerations
The management of LFA and remote LFA is the subject of ongoing work The management of LFA and remote LFA is the subject of ongoing work
withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the withing the IETF [I-D.ietf-rtgwg-lfa-manageability] to which the
reader is referred. Management considerations may lead to a reader is referred. Management considerations may lead to a
preference for the use of a remote LFA over an available LFA. This preference for the use of a remote LFA over an available LFA. This
preference is a matter for the network operator, and not a matter of preference is a matter for the network operator, and not a matter of
protocol correctness. protocol correctness.
When the network re-converges, microloops [RFC5715] may form due to When the network re-converges, microloops [RFC5715] may form due to
transient inconsistencies in the router FIBs. If it is determined transient inconsistencies in the router FIBs. If it is determined
skipping to change at page 26, line 4 skipping to change at page 26, line 4
security concerns. security concerns.
To prevent their use as an attack vector IP repair tunnel endpoints To prevent their use as an attack vector IP repair tunnel endpoints
(where used) SHOULD be assigned from a set of addresses that are not (where used) SHOULD be assigned from a set of addresses that are not
reachable from outside the routing domain. reachable from outside the routing domain.
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Levente Csikor and Chris Bowers for their The authors wish to thank Levente Csikor and Chris Bowers for their
contribution to the cost based algorithm text. We thank Alia Atlas, contribution to the cost based algorithm text. We thank Alia Atlas,
Ross Callon, Stephane Litkowski, Bharath R, and Pushpasis Sarkar for Ross Callon, Stephane Litkowski, Bharath R, Pushpasis Sarkar and
their review of this document. Adrian Farrel for their review of this document.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008. Reroute: Loop-Free Alternates", RFC 5286, September 2008.
skipping to change at page 26, line 40 skipping to change at page 26, line 40
[I-D.ietf-ospf-routable-ip-address] [I-D.ietf-ospf-routable-ip-address]
Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP
Addresses in OSPF RI LSA", draft-ietf-ospf-routable-ip- Addresses in OSPF RI LSA", draft-ietf-ospf-routable-ip-
address-01 (work in progress), October 2014. address-01 (work in progress), October 2014.
[I-D.ietf-rtgwg-lfa-manageability] [I-D.ietf-rtgwg-lfa-manageability]
Litkowski, S., Decraene, B., Filsfils, C., Raza, K., Litkowski, S., Decraene, B., Filsfils, C., Raza, K.,
Horneffer, M., and p. psarkar@juniper.net, "Operational Horneffer, M., and p. psarkar@juniper.net, "Operational
management of Loop Free Alternates", draft-ietf-rtgwg-lfa- management of Loop Free Alternates", draft-ietf-rtgwg-lfa-
manageability-04 (work in progress), August 2014. manageability-06 (work in progress), January 2015.
[I-D.ietf-rtgwg-rlfa-node-protection] [I-D.ietf-rtgwg-rlfa-node-protection]
psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers, psarkar@juniper.net, p., Gredler, H., Hegde, S., Bowers,
C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node
Protection and Manageability", draft-ietf-rtgwg-rlfa-node- Protection and Manageability", draft-ietf-rtgwg-rlfa-node-
protection-01 (work in progress), December 2014. protection-01 (work in progress), December 2014.
[I-D.litkowski-rtgwg-uloop-delay] [I-D.litkowski-rtgwg-uloop-delay]
Litkowski, S., Decraene, B., Filsfils, C., and P. Litkowski, S., Decraene, B., Filsfils, C., and P.
Francois, "Microloop prevention by introducing a local Francois, "Microloop prevention by introducing a local
 End of changes. 23 change blocks. 
50 lines changed or deleted 60 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/