draft-ietf-rtgwg-lfa-manageability-08.txt   draft-ietf-rtgwg-lfa-manageability-09.txt 
Routing Area Working Group S. Litkowski Routing Area Working Group S. Litkowski, Ed.
Internet-Draft B. Decraene Internet-Draft B. Decraene
Intended status: Standards Track Orange Intended status: Standards Track Orange
Expires: September 5, 2015 C. Filsfils Expires: December 21, 2015 C. Filsfils
K. Raza K. Raza
Cisco Systems Cisco Systems
M. Horneffer M. Horneffer
Deutsche Telekom Deutsche Telekom
P. Sarkar P. Sarkar
Juniper Networks Juniper Networks
March 4, 2015 June 19, 2015
Operational management of Loop Free Alternates Operational management of Loop Free Alternates
draft-ietf-rtgwg-lfa-manageability-08 draft-ietf-rtgwg-lfa-manageability-09
Abstract Abstract
Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic
(and MPLS LDP traffic by extension). Following first deployment (and MPLS LDP traffic by extension). Following first deployment
experiences, this document provides operational feedback on LFA, experiences, this document provides operational feedback on LFA,
highlights some limitations, and proposes a set of refinements to highlights some limitations, and proposes a set of refinements to
address those limitations. It also proposes required management address those limitations. It also proposes required management
specifications. specifications.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 September 5, 2015. This Internet-Draft will expire on December 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operational issues with default LFA tie breakers . . . . . . 4 3. Operational issues with default LFA tie breakers . . . . . . 4
3.1. Case 1: PE router protecting failures within core network 4 3.1. Case 1: PE router protecting failures within core network 4
3.2. Case 2: PE router choosen to protect core failures while 3.2. Case 2: PE router choosen to protect core failures while
P router LFA exists . . . . . . . . . . . . . . . . . . . 5 P router LFA exists . . . . . . . . . . . . . . . . . . . 5
3.3. Case 3: suboptimal P router alternate choice . . . . . . 6 3.3. Case 3: suboptimal P router alternate choice . . . . . . 6
3.4. Case 4: IS-IS overload bit on LFA computing node . . . . 7 3.4. Case 4: IS-IS overload bit on LFA computing node . . . . 7
4. Need for coverage monitoring . . . . . . . . . . . . . . . . 8 4. Need for coverage monitoring . . . . . . . . . . . . . . . . 8
5. Need for LFA activation granularity . . . . . . . . . . . . . 9 5. Need for LFA activation granularity . . . . . . . . . . . . . 9
6. Configuration requirements . . . . . . . . . . . . . . . . . 9 6. Configuration requirements . . . . . . . . . . . . . . . . . 9
6.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 9 6.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 9
6.2. Policy based LFA selection . . . . . . . . . . . . . . . 10 6.2. Policy based LFA selection . . . . . . . . . . . . . . . 10
6.2.1. Connected vs remote alternates . . . . . . . . . . . 11 6.2.1. Connected vs remote alternates . . . . . . . . . . . 11
6.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 11 6.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 11
6.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 12 6.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 12
6.2.4. Retrieving alternate path attributes . . . . . . . . 12 6.2.4. Criteria evaluation . . . . . . . . . . . . . . . . . 12
6.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 14 6.2.5. Retrieving alternate path attributes . . . . . . . . 16
6.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.6. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 21
6.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 16 7. Operational aspects . . . . . . . . . . . . . . . . . . . . . 22
6.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 17 7.1. IS-IS overload bit on LFA computing node . . . . . . . . 22
6.2.9. Alternate preference/Node coloring . . . . . . . . . 18 7.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 23
7. Operational aspects . . . . . . . . . . . . . . . . . . . . . 19 7.3. Required local information . . . . . . . . . . . . . . . 24
7.1. IS-IS overload bit on LFA computing node . . . . . . . . 19 7.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 24
7.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 20 7.5. LFA and network planning . . . . . . . . . . . . . . . . 25
7.3. Required local information . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 21 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
7.5. LFA and network planning . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Definitions 1. Introduction
Following the first deployments of Loop Free Alternates (LFA), this
document provides feedback to the community about the management of
LFA.
Section 3 provides real uses cases illustrating some limitations
and suboptimal behavior.
Section 5 proposes requirements for activation granularity and
policy based selection of the alternate.
Section 6 express requirements for the operational management of
LFA.
2. Definitions
o Per-prefix LFA : LFA computation, and best alternate evaluation is o Per-prefix LFA : LFA computation, and best alternate evaluation is
done for each destination prefix. As opposed to "Per-next hop" done for each destination prefix. As opposed to "Per-next hop"
simplification also proposed in [RFC5286] Section 3.8. simplification also proposed in [RFC5286] Section 3.8.
o PE router : Provider Edge router. These routers are connecting o PE router : Provider Edge router. These routers are connecting
customers customers
o P router : Provider router. These routers are core routers, o P router : Provider router. These routers are core routers,
without customer connections. They provide transit between PE without customer connections. They provide transit between PE
skipping to change at page 3, line 43 skipping to change at page 4, line 8
o Node-protecting LFA : alternate providing protection against node o Node-protecting LFA : alternate providing protection against node
failure. failure.
o Connected alternate : alternate adjacent (at IGP level) to the o Connected alternate : alternate adjacent (at IGP level) to the
point of local repair (i.e. an IGP neighbor). point of local repair (i.e. an IGP neighbor).
o Remote alternate : alternate which is does not share an IGP o Remote alternate : alternate which is does not share an IGP
adjacency with the point of local repair. adjacency with the point of local repair.
2. Introduction
Following the first deployments of Loop Free Alternates (LFA), this
document provides feedback to the community about the management of
LFA.
Section 3 provides real uses cases illustrating some limitations
and suboptimal behavior.
Section 5 proposes requirements for activation granularity and
policy based selection of the alternate.
Section 6 express requirements for the operational management of
LFA.
3. Operational issues with default LFA tie breakers 3. Operational issues with default LFA tie breakers
[RFC5286] introduces the notion of tie breakers when selecting the [RFC5286] introduces the notion of tie breakers when selecting the
LFA among multiple candidate alternate next-hops. When multiple LFA LFA among multiple candidate alternate next-hops. When multiple LFA
exist, RFC 5286 has favored the selection of the LFA providing the exist, RFC 5286 has favored the selection of the LFA providing the
best coverage of the failure cases. While this is indeed a goal, best coverage of the failure cases. While this is indeed a goal,
this is one among multiple and in some deployment this lead to the this is one among multiple and in some deployment this lead to the
selection of a suboptimal LFA. The following sections details real selection of a suboptimal LFA. The following sections details real
use cases of such limitations. use cases of such limitations.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
PE1 is thus not considered as an LFA. However thanks to the overload PE1 is thus not considered as an LFA. However thanks to the overload
bit set on PE3, we know that PE1 is loop-free so PE1 is an LFA to bit set on PE3, we know that PE1 is loop-free so PE1 is an LFA to
reach PE2. reach PE2.
In case of overload condition set on a node, LFA behavior must be In case of overload condition set on a node, LFA behavior must be
clarified. clarified.
4. Need for coverage monitoring 4. Need for coverage monitoring
As per [RFC6571], LFA coverage highly depends on the used network As per [RFC6571], LFA coverage highly depends on the used network
topology. Even if remote LFA ([I-D.ietf-rtgwg-remote-lfa]) extends topology. Even if remote LFA ([RFC7490]) extends significantly the
significantly the coverage of the basic LFA specification, there is coverage of the basic LFA specification, there is still some cases
still some cases where protection would not be available. As network where protection would not be available. As network topologies are
topologies are constantly evolving (network extension, capacity constantly evolving (network extension, capacity addings, latency
addings, latency optimization ...), the protection coverage may optimization ...), the protection coverage may change. Fast reroute
change. Fast reroute functionality may be critical for some services functionality may be critical for some services supported by the
supported by the network, a service provider must constantly know network, a service provider must constantly know what protection
what protection coverage is currently available on the network. coverage is currently available on the network. Moreover, predicting
Moreover, predicting the protection coverage in case of network the protection coverage in case of network topology change is
topology change is mandatory. mandatory.
Today network simulation tool associated with whatif scenarios Today network simulation tool associated with whatif scenarios
functionality are often used by service providers for the overall functionality are often used by service providers for the overall
network design (capacity, path optimization ...). Section 7.5, network design (capacity, path optimization ...). Section 7.5,
Section 7.4 and Section 7.3 of this document propose to add LFA Section 7.4 and Section 7.3 of this document propose to add LFA
informations into such tool and within routers, so a service provider informations into such tool and within routers, so a service provider
may be able : may be able :
o to evaluate protection coverage after a topology change. o to evaluate protection coverage after a topology change.
skipping to change at page 11, line 24 skipping to change at page 11, line 24
6.2.1. Connected vs remote alternates 6.2.1. Connected vs remote alternates
In addition to connected LFAs, tunnels (e.g. IP, LDP, RSVP-TE or In addition to connected LFAs, tunnels (e.g. IP, LDP, RSVP-TE or
Segment Routing) to distant routers may be used to complement LFA Segment Routing) to distant routers may be used to complement LFA
coverage (tunnel tail used as virtual neighbor). When a router has coverage (tunnel tail used as virtual neighbor). When a router has
multiple alternate candidates for a specific destination, it may have multiple alternate candidates for a specific destination, it may have
connected alternates and remote alternates (reachable via a tunnel). connected alternates and remote alternates (reachable via a tunnel).
Connected alternates may not always provide an optimal routing path Connected alternates may not always provide an optimal routing path
and it may be preferable to select a remote alternate over a and it may be preferable to select a remote alternate over a
connected alternate. Some usage of tunnels to extend LFA ([RFC5286]) connected alternate. Some usage of tunnels to extend LFA ([RFC5286])
coverage is described in either [I-D.ietf-rtgwg-remote-lfa] or coverage is described in either [RFC7490] or
[I-D.francois-segment-routing-ti-lfa]. These documents present some [I-D.francois-segment-routing-ti-lfa]. These documents present some
use cases of LDP tunnels ([I-D.ietf-rtgwg-remote-lfa]) or Segment use cases of LDP tunnels ([RFC7490]) or Segment Routing tunnels
Routing tunnels ([I-D.francois-segment-routing-ti-lfa]). This ([I-D.francois-segment-routing-ti-lfa]). This document considers any
document considers any type of tunneling techniques to reach remote type of tunneling techniques to reach remote alternates (IP, GRE,
alternates (IP, GRE, LDP, RSVP-TE, L2TP, Segment Routing ...) and LDP, RSVP-TE, L2TP, Segment Routing ...) and does not restrict the
does not restrict the remote alternates to the usage presented in the remote alternates to the usage presented in the referenced document.
referenced document.
In figure 1, there is no P router alternate for P8 to reach PE4 or In figure 1, there is no P router alternate for P8 to reach PE4 or
PE5 , so P8 is using PE2 as alternate, which may generate congestion PE5 , so P8 is using PE2 as alternate, which may generate congestion
when FRR is activated. Instead, we could have a remote alternate for when FRR is activated. Instead, we could have a remote alternate for
P8 to protect traffic to PE4 and PE5. For example, a tunnel from P8 P8 to protect traffic to PE4 and PE5. For example, a tunnel from P8
to P3 (following shortest path) can be setup and P8 would be able to to P3 (following shortest path) can be setup and P8 would be able to
use P3 as remote alternate to protect traffic to PE4 and PE5. In use P3 as remote alternate to protect traffic to PE4 and PE5. In
this scenario, traffic will not use a PE link during FRR activation. this scenario, traffic will not use a PE link during FRR activation.
When selecting the best alternate, the selection algorithm MUST When selecting the best alternate, the selection algorithm MUST
consider all available alternates (connected or tunnel). Especially, consider all available alternates (connected or tunnel). For example
computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be with Remote LFA, computation of PQ set ([RFC7490]) SHOULD be
performed before best alternate selection. performed before best alternate selection.
6.2.2. Mandatory criteria 6.2.2. Mandatory criteria
An implementation of LFA MUST support the following criteria: An implementation of LFA MUST support the following criteria:
o Non candidate link: A link marked as "non candidate" will never be o Non candidate link: A link marked as "non candidate" will never be
used as LFA. used as LFA.
o A primary next hop being protected by another primary next hop of o A primary next hop being protected by another primary next hop of
the same prefix (ECMP case). the same prefix (ECMP case).
o Type of protection provided by the alternate: link protection, o Type of protection provided by the alternate: link protection,
node protection. In case of node protection preference, an node protection. In case of node protection preference, an
implementation SHOULD support fall back to link protection if node implementation SHOULD support fall back to link protection if node
protection is not available. protection is not available.
o Shortest path: lowest IGP metric used to reach the destination. o Shortest path: lowest IGP metric used to reach the destination.
o SRLG (as defined in [RFC5286] Section 3, see also Section 6.2.6 o SRLG (as defined in [RFC5286] Section 3, see also Section 6.2.4.1
for more details). for more details).
6.2.3. Enhanced criteria 6.2.3. Enhanced criteria
An implementation of LFA SHOULD support the following enhanced An implementation of LFA SHOULD support the following enhanced
criteria: criteria:
o Downstreamness of an alternate : preference of a downstream path o Downstreamness of an alternate : preference of a downstream path
over a non downstream path SHOULD be configurable. over a non downstream path SHOULD be configurable.
o Link coloring with : include, exclude and preference based system o Link coloring with : include, exclude and preference based system
(see Section 6.2.7). (see Section 6.2.4.2).
o Link Bandwidth (see Section 6.2.8).
o Alternate preference/Node coloring (see Section 6.2.9).
6.2.4. Retrieving alternate path attributes
The policy to select the best alternate evaluate multiple criterions
(e.g. metric, SRLG, link colors ...) which first need to be computed
for each alternate.. In order to compare the different alternate
path, a router must retrieve the attributes of each alternate path.
The alternate path is composed of two distinct parts : PLR to
alternate and alternate to destination.
6.2.4.1. Connected alternate
For alternate path using a connected alternate :
o attributes from PLR to alternate path are retrieved from the
interface connected to the alternate.
o attributes from alternate to destination path are retrieved from
SPF rooted at the alternate. As the alternate is a connected
alternate, the SPF has already been computed to find the
alternate, so there is no need of additional computation.
6.2.4.2. Remote alternate
For alternate path using a remote alternate (tunnel) :
o attributes from the PLR to alternate path are retrieved using the
PLR's primary SPF if P space is used or using the neighbor's SPF
if extended P space is used, combined with the attributes of the
link(s) to reach that neighbor. In both cases, no additional SPF
is required.
o attributes from alternate to destination path may be retrieved
from SPF rooted at the remote alternate. An additional forward
SPF is required for each remote alternate as indicated in
[I-D.ietf-rtgwg-rlfa-node-protection] section 3.2.. . In some
remote alternate scenarios, like
[I-D.francois-segment-routing-ti-lfa], alternate to destination
path attributes may be obtained using a different technique.
The number of remote alternates may be very high. In case of remote
LFA, simulations of real-world network topologies, reveal that order
of hundreths of PQ ...
To handle this situation, it is needed to limit the number of remote
alternates to be evaluated to a finite number before collecting
alternate path attributes and running the policy evaluation. [I-
D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to
reduce the number of PQ to be evaluated.
Some other remote alternate techniques using static or dynamic
tunnels may not require this pruning.
Link Remote Remote
alternate alternate alternate
------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static/ |
| | | | | Dynamic |
sources | | | | | tunnels |
------------- ------------------ -------------
| | |
| | |
| -------------------------- |
| | Prune some alternates | |
| | (sorting strategy) | |
| -------------------------- |
| | |
| | |
------------------------------------------------
| Collect alternate attributes |
------------------------------------------------
|
|
-------------------------
| Evaluate policy |
-------------------------
|
|
Best alternates
6.2.5. ECMP LFAs
10
PE2 - PE3
| |
50 | 5 | 50
P1----P2
\\ //
50 \\ // 50
PE1
Figure 5
Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are
L3 and L4
In the figure above, primary path from PE1 to PE2 is through P1 using
ECMP on two parallel links L1 and L2. In case of standard ECMP
behavior, if L1 is failing, postconvergence next hop would become L2
and there would be no longer ECMP. If LFA is activated, as stated in
[RFC5286] Section 3.4., "alternate next-hops may themselves also be
primary next-hops, but need not be" and "alternate next-hops should
maximize the coverage of the failure cases". In this scenario there
is no alternate providing node protection, LFA will so prefer L2 as
alternate to protect L1 which makes sense compared to postconvergence
behavior.
Considering a different scenario using figure 5, where L1 and L2 are
configured as a layer 3 bundle using a local feature, as well as L3/
L4 being a second layer 3 bundle. Layer 3 bundles are configured as
if a link in the bundle is failing, the traffic must be rerouted out
of the bundle. Layer 3 bundles are generally introduced to increase
bandwidth between nodes. In nominal situation, ECMP is still
available from PE1 to PE2, but if L1 is failing, postconvergence next
hop would become ECMP on L3 and L4. In this case, LFA behavior
SHOULD be adapted in order to reflect the bandwidth requirement.
We would expect the following FIB entry on PE1 :
On PE1 : PE2 +--> ECMP -> L1
| |
| +----> L2
|
+--> LFA(ECMP) -> L3
|
+---------> L4
If L1 or L2 is failing, traffic must be switched on the LFA ECMP o Link Bandwidth (see Section 6.2.4.3).
bundle rather than using the other primary next hop.
As mentioned in [RFC5286] Section 3.4., protecting a link within an o Alternate preference/Node coloring (see Section 6.2.4.4).
ECMP by another primary next hop is not a MUST. Moreover, we already
presented in this document, that maximizing the coverage of the
failure case may not be the right approach and policy based choice of
alternate may be preferred.
An implementation SHOULD permit to prefer to protect a primary next 6.2.4. Criteria evaluation
hop by another primary next hop. An implementation SHOULD permit to
prefer to protect a primary next hop by a NON primary next hop. An
implementation SHOULD permit to use an ECMP bundle as a LFA.
6.2.6. SRLG 6.2.4.1. SRLG
[RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode [RFC5286] Section 3. proposes to reuse GMPLS IGP extensions to encode
SRLGs ([RFC4205] and [RFC4203]). The section is also describing the SRLGs ([RFC4205] and [RFC4203]). The section is also describing the
algorithm to compute SRLG protection. algorithm to compute SRLG protection.
When SRLG protection is computed, and implementation SHOULD permit to When SRLG protection is computed, and implementation SHOULD permit to
: :
o Exclude alternates violating SRLG. o Exclude alternates violating SRLG.
o Maintain a preference system between alternates based on number of o Maintain a preference system between alternates based on SRLG
SRLG violations : more violations = less preference. violations. How the preference system is implemented is out of
scope of this document but here are few examples :
* Preference based on number of violation. In this case : the
more violation = the less preferred.
* Preference based on violation cost. In this case, each SRLG
violation has an associated cost. The lower violation cost sum
is preferred.
When applying SRLG criteria, the SRLG violation check SHOULD be When applying SRLG criteria, the SRLG violation check SHOULD be
performed on source to alternate as well as alternate to destination performed on source to alternate as well as alternate to destination
paths based on the SRLG set of the primary path. In the case of paths based on the SRLG set of the primary path. In the case of
remote LFA, PQ to destination path attributes would be retrieved from remote LFA, PQ to destination path attributes would be retrieved from
SPT rooted at PQ. SPT rooted at PQ.
6.2.7. Link coloring 6.2.4.2. Link coloring
Link coloring is a powerful system to control the choice of Link coloring is a powerful system to control the choice of
alternates. Protecting interfaces are tagged with colors. Protected alternates. Protecting interfaces are tagged with colors. Protected
interfaces are configured to include some colors with a preference interfaces are configured to include some colors with a preference
level, and exclude others. level, and exclude others.
Link color information SHOULD be signalled in the IGP. How Link color information SHOULD be signalled in the IGP. How
signalling is done is out of scope of the document but it may be signalling is done is out of scope of the document but it may be
useful to reuse existing admin-groups from traffic-engineering useful to reuse existing admin-groups from traffic-engineering
extensions. extensions or link attributes extensions like in
[I-D.ietf-ospf-prefix-link-attr].
PE2 PE2
| +---- P4 | +---- P4
| / | /
PE1 ---- P1 --------- P2 PE1 ---- P1 --------- P2
| 10Gb | 10Gb
1Gb | 1Gb |
| |
P3 P3
Figure 5 Figure 8
Example : P1 router is connected to three P routers and two PEs. Example : P1 router is connected to three P routers and two PEs.
P1 is configured to protect the P1-P4 link. We assume that given the P1 is configured to protect the P1-P4 link. We assume that given the
topology, all neighbors are candidate LFA. We would like to enforce topology, all neighbors are candidate LFA. We would like to enforce
a policy in the network where only a core router may protect against a policy in the network where only a core router may protect against
the failure of a core link, and where high capacity links are the failure of a core link, and where high capacity links are
prefered. prefered.
In this example, we can use the proposed link coloring by: In this example, we can use the proposed link coloring by:
o Marking PEs links with color RED o Marking PEs links with color RED
o Marking 10Gb CORE link with color BLUE
o Marking 10Gb CORE link with color BLUE
o Marking 1Gb CORE link with color YELLOW o Marking 1Gb CORE link with color YELLOW
o Configured the protected interface P1->P4 with : o Configured the protected interface P1->P4 with :
* Include BLUE, preference 200 * Include BLUE, preference 200
* Include YELLOW, preference 100 * Include YELLOW, preference 100
* Exclude RED * Exclude RED
skipping to change at page 17, line 35 skipping to change at page 14, line 33
An implementation of link coloring: An implementation of link coloring:
o SHOULD support multiple include and exclude colors on a single o SHOULD support multiple include and exclude colors on a single
protected interface. protected interface.
o SHOULD provide a level of preference between included colors. o SHOULD provide a level of preference between included colors.
o SHOULD support multiple colors configuration on a single o SHOULD support multiple colors configuration on a single
protecting interface. protecting interface.
6.2.8. Bandwidth 6.2.4.3. Bandwidth
As mentionned in previous sections, not taking into account bandwidth As mentioned in previous sections, not taking into account bandwidth
of an alternate could lead to congestion during FRR activation. We of an alternate could lead to congestion during FRR activation. We
propose to base the bandwidth criteria on the link speed information propose to base the bandwidth criteria on the link speed information
for the following reason : for the following reason :
o if a router S has a set of X destinations primarly forwarded to N, o if a router S has a set of X destinations primarly forwarded to N,
using per prefix LFA may lead to have a subset of X protected by a using per prefix LFA may lead to have a subset of X protected by a
neighbor N1, another subset by N2, another subset by Nx ... neighbor N1, another subset by N2, another subset by Nx ...
o S is not aware about traffic flows to each destination and is not o S is not aware about traffic flows to each destination and is not
able to evaluate how much traffic will be sent to N1,N2, ... Nx in able to evaluate how much traffic will be sent to N1,N2, ... Nx in
case of FRR activation. case of FRR activation.
Based on this, it is not useful to gather available bandwidth on Based on this, it is not useful to gather available bandwidth on
alternate paths, as the router does not know how much bandwidth it alternate paths, as the router does not know how much bandwidth it
requires for protection. The proposed link speed approach provides a requires for protection. The proposed link speed approach provides a
good approximation with a small cost as information is easily good approximation with a small cost as information is easily
available. available.
The bandwidth criteria of the policy framework SHOULD work in two The bandwidth criteria of the policy framework SHOULD work in at
ways : least two ways :
o PRUNE : exclude a LFA if link speed to reach it is lower than the o PRUNE : exclude a LFA if link speed to reach it is lower than the
link speed of the primary next hop interface. link speed of the primary next hop interface.
o PREFER : prefer a LFA based on his bandwidth to reach it compared o PREFER : prefer a LFA based on its bandwidth to reach it compared
to the link speed of the primary next hop interface. to the link speed of the primary next hop interface.
6.2.9. Alternate preference/Node coloring 6.2.4.4. Alternate preference/Node coloring
Rather than tagging interface on each node (using link color) to Rather than tagging interface on each node (using link color) to
identify alternate node type (as example), it would be helpful if identify alternate node type (as example), it would be helpful if
routers could be identified in the IGP. This would permit a grouped routers could be identified in the IGP. This would permit a grouped
processing on multiple nodes. As an implementation need to exclude processing on multiple nodes. As an implementation need to exclude
some specific alternates (see Section 6.2.3), an implementation : some specific alternates (see Section 6.2.3), an implementation :
o SHOULD be able to give a preference to specific alternate. o SHOULD be able to give a preference to specific alternate.
o SHOULD be able to give a preference to a group of alternate. o SHOULD be able to give a preference to a group of alternate.
o SHOULD be able to exclude a group of alternate. o SHOULD be able to exclude a group of alternate.
A specific alternate may be identified by its interface, IP address A specific alternate may be identified by its interface, IP address
or router ID and group of alternates may be identified by a marker or router ID and group of alternates may be identified by a marker
(tag) (for example, in case of IS-IS protocol (tag) (for example, those IGP extensions can be used :
[I-D.ietf-isis-node-admin-tag] can be used). Using a tag is referred [I-D.ietf-isis-node-admin-tag], [I-D.ietf-ospf-node-admin-tag],
as Node coloring in comparison to link coloring option presented in [I-D.ietf-isis-prefix-attributes], [I-D.ietf-ospf-prefix-link-attr]
Section 6.2.7. ). Using a tag is referred as Node coloring in comparison to link
coloring option presented in Section 6.2.4.2.
Consider the following network: Consider the following network:
PE3 PE3
| |
| |
PE2 PE2
| +---- P4 | +---- P4
| / | /
PE1 ---- P1 -------- P2 PE1 ---- P1 -------- P2
| 10Gb | 10Gb
1Gb | 1Gb |
| |
P3 P3
Figure 6 Figure 9
In the example above, each node is configured with a specific tag In the example above, each node is configured with a specific tag
flooded through the IGP. flooded through the IGP.
o PE1,PE3: 200 (non candidate). o PE1,PE3: 200 (non candidate).
o PE2: 100 (edge/core). o PE2: 100 (edge/core).
o P1,P2,P3: 50 (core). o P1,P2,P3: 50 (core).
A simple policy could be configured on P1 to choose the best A simple policy could be configured on P1 to choose the best
alternate for P1->P4 based on router function/role as follows : alternate for P1->P4 based on router function/role as follows :
o criteria 1 -> alternate preference: exclude tag 100 and 200. o criteria 1 -> alternate preference: exclude tag 100 and 200.
o criteria 2 -> bandwidth. o criteria 2 -> bandwidth.
6.2.5. Retrieving alternate path attributes
6.2.5.1. Alternate path
The alternate path is composed of two distinct parts : PLR to
alternate and alternate to destination.
N1 -- R1 ---- R2
/50 \ \
/ R3 --- R4
/ \
S -------- E ------- D
\\ //
\\ //
N2 ---- PQ ---- R5
Figure 5
In the figure above, we consider a primary path from S to D, S using
E as primary nexthop. All metrics are 1 except {S,N1}=50. Two
alternate paths are available:
o {S,N1,R1,R2|R3,R4,D} where N1 is a connected alternate: the path
is composed of PLR to alternate path which is {S,N1} and alternate
to destination path which is {N1,R1,R2|R3,R4,D}.
o {S,N2,PQ,R5,D} where PQ is a remote alternate: the path is
composed of PLR to alternate path which is {S,N2,PQ} and alternate
to destination path which is {PQ,R5,D}.
As displayed in the figure, some part of the alternate path may
fanout in multipath due to ECMP.
6.2.5.2. Alternate path attributes
Some criterions listed in the previous sections are requiring to
retrieve some characteristic of the alternate path (SRLG, bandwidth,
color, tag ...). We call these characteristics "path attributes". A
path attribute can record a list of node properties (e.g. node tag)
or link properties (e.g. link color).
This document defines two types of path attributes:
o Cumulative attribute: when a path attribute is cumulative, the
implementation SHOULD record the value of the attribute on each
element (link and node) along the alternate path. SRLG, link
color, and node color are cumulative attributes.
o Unitary attribute: when a path attribute is unitary, the
implementation SHOULD record the value of the attribute only on
the first element along the alternate path (first node, or first
link). Bandwidth is a unitary attribute.
N1 -- R1 ---- R2
/ \
/ 50 R4
/ \
S -------- E ------- D
In the figure above, N1 is a connected alternate to each D from S.
We consider that all links have a RED color except {R1,R2} which is
BLUE. We consider all links to be 10Gbps, except {N1,R1} which is
2.5Gbps. The bandwidth attribute collected for the alternate path
will be 10Gbps. As the attribute is unitary, only the link speed of
the first link {S,N1} is recorded. The link color attribute
collected for the alternate path will be {RED,RED,BLUE,RED,RED}. As
the attribute is cumulative, the value of the attribute on each link
along the path is recorded.
6.2.5.3. Connected alternate
For alternate path using a connected alternate:
o attributes from PLR to alternate are retrieved from the interface
connected to the alternate. In case the alternate is connected
through multiple interfaces, the evaluation of attributes SHOULD
be done once per interface (each interface is considered as a
separate alternate) and once per ECMP group of interfaces.
o path attributes from alternate to destination are retrieved from
SPF rooted at the alternate. As the alternate is a connected
alternate, the SPF has already been computed to find the
alternate, so there is no need of additional computation.
N1 -- R1 ---- R2
50//50 \
// \
i1//i2 \
S -------- E -------- D
Figure 6
In the figure above, we consider a primary path from S to D, S using
E as primary nexthop. All metrics are considered as 1 expect {S,N1}
links which are using metric of 50. We consider the following SRLG
groups on links:
o {S,N1} using i1 : SRLG1,SRLG10
o {S,N1} using i2 : SRLG2,SRLG20
o {N1,R1} : SRLG3
o {R1,R2} : SRLG4
o {R2,D} : SRLG5
o {S,E} : SRLG10
o {E,D} : SRLG6
S is connected to the alternate using two interfaces i1 and i2.
If i1 and i2 are not part of an ECMP group, the evaluation of
attributes is done once per interface, and each interface is
considered as a separate alternate path. Two alternate paths will be
available with the associated SRLG attributes :
o Alternate path #1 : {S,N1 using if1,R1,R2,D}:
SRLG1,SRLG10,SRLG3,SRLG4,SRLG5.
o Alternate path #2 : {S,N1 using if2,R1,R2,D}:
SRLG2,SRLG20,SRLG3,SRLG4,SRLG5.
Alternate path #1 is sharing risks with primary path and may be
depreferred or pruned by user defined policy.
If i1 and i2 are part of an ECMP group, the evaluation of attributes
is done once per ECMP group, and the implementation considers a
single alternate path {S,N1 using if1|if2,R1,R2,D} with the following
SRLG attributes: SRLG1,SRLG10,SRLG2,SRLG20,SRLG3,SRLG4,SRLG5.
Alternate path is sharing risks with primary path and may be
depreferred or pruned by user defined policy.
6.2.5.4. Remote alternate
For alternate path using a remote alternate (tunnel) :
o attributes from the PLR to alternate path are retrieved using the
PLR's primary SPF if P space is used or using the neighbor's SPF
if extended P space is used, combined with the attributes of the
link(s) to reach that neighbor. In both cases, no additional SPF
is required.
o attributes from alternate to destination path may be retrieved
from SPF rooted at the remote alternate. An additional forward
SPF is required for each remote alternate as indicated in
[I-D.ietf-rtgwg-rlfa-node-protection] section 3.2 . In some remote
alternate scenarios, like [I-D.francois-segment-routing-ti-lfa],
alternate to destination path attributes may be obtained using a
different technique.
The number of remote alternates may be very high. . In case of
remote LFA, simulations of real-world network topologies have shown
that order of hundreths of PQ may be possible. The computational
overhead to collect all path attributes of all PQ to destination
paths may grow beyond practical reason.
To handle this situation, it is needed to limit the number of remote
alternates to be evaluated to a finite number before collecting
alternate path attributes and running the policy evaluation. [I-
D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to
reduce the number of PQ to be evaluated.
Some other remote alternate techniques using static or dynamic
tunnels may not require this pruning.
Link Remote Remote
alternate alternate alternate
------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static/ |
| | | | | Dynamic |
sources | | | | | tunnels |
------------- ------------------ -------------
| | |
| | |
| -------------------------- |
| | Prune some alternates | |
| | (sorting strategy) | |
| -------------------------- |
| | |
| | |
------------------------------------------------
| Collect alternate attributes |
------------------------------------------------
|
|
-------------------------
| Evaluate policy |
-------------------------
|
|
Best alternates
6.2.5.5. Collecting attributes in case of multipath
As described in Section 6.2.5, there may be some situation where an
alternate path or part of an alternate path fans out to multiple
paths (e.g. ECMP). When collecting path attributes in such case, an
implementation SHOULD consider the union of attributes of each sub-
path.
In the figure 5 (in Section 6.2.5), S has two alternates paths to
reach D. Each alternate path fans out into multipath due to ECMP.
Considering the following link color attributes : all links are RED
except {R1,R3} which is BLUE. The user wants to use an alternate
path with only RED links. The first alternate path
{S,N1,R1,R2|R3,R4,D} does not fit the constraint, as {R1,R3} is BLUE.
The second alternate path {S,N2,PQ,R5,D} fits the constraint and will
be preferred as it uses only RED links.
6.2.6. ECMP LFAs
10
PE2 - PE3
| |
50 | 5 | 50
P1----P2
\\ //
50 \\ // 50
PE1
Figure 7
Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are
L3 and L4
In the figure above, primary path from PE1 to PE2 is through P1 using
ECMP on two parallel links L1 and L2. In case of standard ECMP
behavior, if L1 is failing, postconvergence next hop would become L2
and there would be no longer ECMP. If LFA is activated, as stated in
[RFC5286] Section 3.4., "alternate next-hops may themselves also be
primary next-hops, but need not be" and "alternate next-hops should
maximize the coverage of the failure cases". In this scenario there
is no alternate providing node protection, LFA will so prefer L2 as
alternate to protect L1 which makes sense compared to postconvergence
behavior.
Considering a different scenario using figure 7, where L1 and L2 are
configured as a layer 3 bundle using a local feature, as well as L3/
L4 being a second layer 3 bundle. Layer 3 bundles are configured as
if a link in the bundle is failing, the traffic must be rerouted out
of the bundle. Layer 3 bundles are generally introduced to increase
bandwidth between nodes. In nominal situation, ECMP is still
available from PE1 to PE2, but if L1 is failing, postconvergence next
hop would become ECMP on L3 and L4. In this case, LFA behavior
SHOULD be adapted in order to reflect the bandwidth requirement.
We would expect the following FIB entry on PE1 :
On PE1 : PE2 +--> ECMP -> L1
| |
| +----> L2
|
+--> LFA(ECMP) -> L3
|
+---------> L4
If L1 or L2 is failing, traffic must be switched on the LFA ECMP
bundle rather than using the other primary next hop.
As mentioned in [RFC5286] Section 3.4., protecting a link within an
ECMP by another primary next hop is not a MUST. Moreover, we already
presented in this document, that maximizing the coverage of the
failure case may not be the right approach and policy based choice of
alternate may be preferred.
An implementation SHOULD permit to prefer to protect a primary next
hop by another primary next hop. An implementation SHOULD permit to
prefer to protect a primary next hop by a NON primary next hop. An
implementation SHOULD permit to use an ECMP bundle as a LFA.
7. Operational aspects 7. Operational aspects
7.1. IS-IS overload bit on LFA computing node 7.1. IS-IS overload bit on LFA computing node
In [RFC5286], Section 3.5, the setting of the overload bit condition In [RFC5286], Section 3.5, the setting of the overload bit condition
in LFA computation is only taken into account for the case where a in LFA computation is only taken into account for the case where a
neighbor has the overload bit set. neighbor has the overload bit set.
In addition to RFC 5286 inequality 1 Loop-Free Criterion In addition to RFC 5286 inequality 1 Loop-Free Criterion
(Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)), the (Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)), the
skipping to change at page 23, line 39 skipping to change at page 26, line 39
[RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)", of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 5307, October 2008. RFC 5307, October 2008.
[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B., [RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,
Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP) Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, June 2012. Networks", RFC 6571, June 2012.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, April 2015.
12.2. Informative References 12.2. Informative References
[I-D.francois-segment-routing-ti-lfa] [I-D.francois-segment-routing-ti-lfa]
Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,
"Topology Independent Fast Reroute using Segment Routing", "Topology Independent Fast Reroute using Segment Routing",
draft-francois-segment-routing-ti-lfa-00 (work in draft-francois-segment-routing-ti-lfa-00 (work in
progress), November 2013. progress), November 2013.
[I-D.ietf-isis-node-admin-tag] [I-D.ietf-isis-node-admin-tag]
Sarkar, P., Gredler, H., Hegde, S., Litkowski, S., Sarkar, P., Gredler, H., Hegde, S., Litkowski, S.,
Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H. Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H.
Raghuveer, "Advertising Per-node Admin Tags in IS-IS", Raghuveer, "Advertising Per-node Admin Tags in IS-IS",
draft-ietf-isis-node-admin-tag-00 (work in progress), draft-ietf-isis-node-admin-tag-02 (work in progress), June
December 2014. 2015.
[I-D.ietf-rtgwg-remote-lfa] [I-D.ietf-isis-prefix-attributes]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. Ginsberg, L., Decraene, B., Filsfils, C., Litkowski, S.,
So, "Remote Loop-Free Alternate (LFA) Fast Re-Route Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix
(FRR)", draft-ietf-rtgwg-remote-lfa-11 (work in progress), Attributes for Extended IP and IPv6 Reachability", draft-
January 2015. ietf-isis-prefix-attributes-00 (work in progress), May
2015.
[I-D.ietf-ospf-node-admin-tag]
Hegde, S., Raghuveer, H., Gredler, H., Shakir, R.,
Smirnov, A., Li, Z., and B. Decraene, "Advertising per-
node administrative tags in OSPF", draft-ietf-ospf-node-
admin-tag-02 (work in progress), June 2015.
[I-D.ietf-ospf-prefix-link-attr]
Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", draft-ietf-ospf-prefix-link-attr-06 (work
in progress), June 2015.
[I-D.ietf-rtgwg-rlfa-node-protection] [I-D.ietf-rtgwg-rlfa-node-protection]
Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski,
S., and H. Raghuveer, "Remote-LFA Node Protection and S., and H. Raghuveer, "Remote-LFA Node Protection and
Manageability", draft-ietf-rtgwg-rlfa-node-protection-01 Manageability", draft-ietf-rtgwg-rlfa-node-protection-02
(work in progress), December 2014. (work in progress), June 2015.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski (editor)
Orange Orange
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Bruno Decraene Bruno Decraene
Orange Orange
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Kamran Raza Kamran Raza
Cisco Systems Cisco Systems
Email: skraza@cisco.com Email: skraza@cisco.com
 End of changes. 39 change blocks. 
234 lines changed or deleted 389 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/