draft-ietf-rtgwg-remote-lfa-07.txt   draft-ietf-rtgwg-remote-lfa-08.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: March 29, 2015 Cisco Systems Expires: March 30, 2015 Cisco Systems
M. Shand M. Shand
Independent Contributor Independent Contributor
N. So N. So
Vinci Systems Vinci Systems
September 25, 2014 September 26, 2014
Remote LFA FRR Remote LFA FRR
draft-ietf-rtgwg-remote-lfa-07 draft-ietf-rtgwg-remote-lfa-08
Abstract Abstract
This draft describes an extension to the basic IP fast re-route This draft describes an extension to the basic IP fast re-route
mechanism described in RFC5286, that provides additional backup mechanism described in RFC5286, that provides additional backup
connectivity for 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
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 March 29, 2015. This Internet-Draft will expire on March 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6 3.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6
3.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 6 3.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 6
4. Construction of Repair Paths . . . . . . . . . . . . . . . . 7 4. Construction of Repair Paths . . . . . . . . . . . . . . . . 7
4.1. Identifying Required Tunneled Repair Paths . . . . . . . 7 4.1. Identifying Required Tunneled Repair Paths . . . . . . . 7
4.2. Determining Tunnel End Points . . . . . . . . . . . . . . 8 4.2. Determining Tunnel End Points . . . . . . . . . . . . . . 8
4.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 8 4.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 8
4.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 10 4.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 10
4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 11 4.3. A Cost Based RLFA Algorithm . . . . . . . . . . . . . . . 11
4.4. Interactions with IS-IS Overload, RFC 3137, 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 Considerations . . . . . . . . . . . . . . . . . . 24
skipping to change at page 16, line 38 skipping to change at page 16, line 38
if (y.valid_tunnel_endpoint) if (y.valid_tunnel_endpoint)
Compute_and_Store_Forward_SPF(y) Compute_and_Store_Forward_SPF(y)
if ((D_opt(y,dest) < D_opt(self,dest)) if ((D_opt(y,dest) < D_opt(self,dest))
y.valid_tunnel_endpoint = true y.valid_tunnel_endpoint = true
else else
y.valid_tunnel_endpoint = false y.valid_tunnel_endpoint = false
// //
///////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////
4.4. Interactions with IS-IS Overload, RFC 3137, and Costed Out Links 4.4. Interactions with IS-IS Overload, RFC6987, and Costed Out Links
Since normal link state routing takes into account the IS-IS overload Since normal link state routing takes into account the IS-IS overload
bit, [RFC6987], and costing out of links as described in [RFC5286], bit, [RFC6987], and costing out of links as described in Section 3.5
the forward SPFs performed by the PLR rooted at the neighbors of the of [RFC5286], the forward SPFs performed by the PLR rooted at the
PLR also need to take this into account. A repair tunnel path from a neighbors of the PLR also need to take this into account. A repair
neighbor of the PLR to a repair tunnel endpoint will generally avoid tunnel path from a neighbor of the PLR to a repair tunnel endpoint
the nodes and links excluded by the IGP overload/costing out rules. will generally avoid the nodes and links excluded by the IGP
However, there are two situations where this behavior may result in a overload/costing out rules. However, there are two situations where
repair path traversing a link or router that should be excluded: this behavior may result in a repair path traversing a link or router
that should be excluded:
1. When the first hop on the repair tunnel path (from the PLR to a 1. When the first hop on the repair tunnel path (from the PLR to a
direct neighbor) does not follow the IGP shortest path. In this direct neighbor) does not follow the IGP shortest path. In this
case, the PLR MUST NOT use a repair tunnel path whose first hop case, the PLR MUST NOT use a repair tunnel path whose first hop
is along a link whose cost or reverse cost is LSInfinity (for is along a link whose cost or reverse cost is MaxLinkMetric (for
OSPF) or the maximum cost (for IS-IS) or, has the overload bit OSPF) or the maximum cost (for IS-IS) or, has the overload bit
set (for IS-IS). set (for IS-IS).
2. The IS-IS overload bit and the mechanism of [RFC6987] only 2. The IS-IS overload bit and the mechanism of [RFC6987] only
prevent transit traffic from traversing a node. They do not prevent transit traffic from traversing a node. They do not
prevent traffic destined to a node. The per-neighbor forwards prevent traffic destined to a node. The per-neighbor forward
SPFs using the standard IGP overload rules will not prevent a PLR SPFs using the standard IGP overload rules will not prevent a PLR
from choosing a repair tunnel endpoint that is advertising a from choosing a repair tunnel endpoint that is advertising a
desire to not carry transit traffic. Therefore, the PLR MUST NOT desire to not carry transit traffic. Therefore, the PLR MUST NOT
use a repair tunnel endpoint with the IS-IS overload bit set, or use a repair tunnel endpoint with the IS-IS overload bit set, or
where all outgoing interfaces have the cost set to LSInfinity for where all outgoing interfaces have the cost set to MaxLinkMetric
OSPF. for OSPF.
5. Example Application of Remote LFAs 5. Example Application of Remote LFAs
An example of a commonly deployed topology which is not fully An example of a commonly deployed topology which is not fully
protected by LFAs alone is shown in Figure 3. PE1 and PE2 are protected by LFAs alone is shown in Figure 3. PE1 and PE2 are
connected in the same site. P1 and P2 may be geographically connected in the same site. P1 and P2 may be geographically
separated (inter-site). In order to guarantee the lowest latency separated (inter-site). In order to guarantee the lowest latency
path from/to all other remote PEs, normally the shortest path follows path from/to all other remote PEs, normally the shortest path follows
the geographical distance of the site locations. Therefore, to the geographical distance of the site locations. Therefore, to
ensure this, a lower IGP metric (5) is assigned between PE1 and PE2. ensure this, a lower IGP metric (5) is assigned between PE1 and PE2.
skipping to change at page 24, line 37 skipping to change at page 24, line 37
and provides a significant improvement in two of the remaining three and provides a significant improvement in two of the remaining three
cases. In an MPLS network, this is achieved without any scaleability cases. In an MPLS network, this is achieved without any scaleability
impact, as the tunnels to the PQ nodes are always present as a impact, as the tunnels to the PQ nodes are always present as a
property of an LDP-based deployment. 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-rtgwg-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 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.
skipping to change at page 26, line 19 skipping to change at page 26, line 19
[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.
14.2. Informative References 14.2. Informative References
[I-D.bryant-ipfrr-tunnels] [I-D.bryant-ipfrr-tunnels]
Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03 Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03
(work in progress), November 2007. (work in progress), November 2007.
[I-D.filsfils-rtgwg-segment-routing] [I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-rtgwg- "Segment Routing Architecture", draft-filsfils-spring-
segment-routing-01 (work in progress), October 2013. segment-routing-04 (work in progress), July 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-04 (work in progress), August 2014.
[I-D.psarkar-rtgwg-rlfa-node-protection] [I-D.psarkar-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
 End of changes. 13 change blocks. 
21 lines changed or deleted 22 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/