draft-ietf-rtgwg-lfa-manageability-07.txt   draft-ietf-rtgwg-lfa-manageability-08.txt 
Routing Area Working Group S. Litkowski Routing Area Working Group S. Litkowski
Internet-Draft B. Decraene Internet-Draft B. Decraene
Intended status: Standards Track Orange Intended status: Standards Track Orange
Expires: July 17, 2015 C. Filsfils Expires: September 5, 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
January 13, 2015 March 4, 2015
Operational management of Loop Free Alternates Operational management of Loop Free Alternates
draft-ietf-rtgwg-lfa-manageability-07 draft-ietf-rtgwg-lfa-manageability-08
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 July 17, 2015. This Internet-Draft will expire on September 5, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operational issues with default LFA tie breakers . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Case 1: Edge router protecting core failures . . . . . . 3 3. Operational issues with default LFA tie breakers . . . . . . 4
2.2. Case 2: Edge router choosen to protect core failures 3.1. Case 1: PE router protecting failures within core network 4
while core LFA exists . . . . . . . . . . . . . . . . . . 5 3.2. Case 2: PE router choosen to protect core failures while
2.3. Case 3: suboptimal core alternate choice . . . . . . . . 5 P router LFA exists . . . . . . . . . . . . . . . . . . . 5
2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 6 3.3. Case 3: suboptimal P router alternate choice . . . . . . 6
3. Need for coverage monitoring . . . . . . . . . . . . . . . . 7 3.4. Case 4: IS-IS overload bit on LFA computing node . . . . 7
4. Need for LFA activation granularity . . . . . . . . . . . . . 8 4. Need for coverage monitoring . . . . . . . . . . . . . . . . 8
5. Configuration requirements . . . . . . . . . . . . . . . . . 8 5. Need for LFA activation granularity . . . . . . . . . . . . . 9
5.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 8 6. Configuration requirements . . . . . . . . . . . . . . . . . 9
5.2. Policy based LFA selection . . . . . . . . . . . . . . . 9 6.1. LFA enabling/disabling scope . . . . . . . . . . . . . . 9
5.2.1. Connected vs remote alternates . . . . . . . . . . . 9 6.2. Policy based LFA selection . . . . . . . . . . . . . . . 10
5.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 10 6.2.1. Connected vs remote alternates . . . . . . . . . . . 11
5.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 10 6.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . 11
5.2.4. Retrieving alternate path attributes . . . . . . . . 11 6.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 12
5.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 12 6.2.4. Retrieving alternate path attributes . . . . . . . . 12
5.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 14
5.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 14 6.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 15 6.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 16
5.2.9. Alternate preference . . . . . . . . . . . . . . . . 16 6.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 17
6. Operational aspects . . . . . . . . . . . . . . . . . . . . . 17 6.2.9. Alternate preference/Node coloring . . . . . . . . . 18
6.1. ISIS overload bit on LFA computing node . . . . . . . . . 17 7. Operational aspects . . . . . . . . . . . . . . . . . . . . . 19
6.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 18 7.1. IS-IS overload bit on LFA computing node . . . . . . . . 19
6.3. Required local information . . . . . . . . . . . . . . . 19 7.2. Manual triggering of FRR . . . . . . . . . . . . . . . . 20
6.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 19 7.3. Required local information . . . . . . . . . . . . . . . 21
6.5. LFA and network planning . . . . . . . . . . . . . . . . 20 7.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7.5. LFA and network planning . . . . . . . . . . . . . . . . 22
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Definitions
o Per-prefix LFA : LFA computation, and best alternate evaluation is
done for each destination prefix. As opposed to "Per-next hop"
simplification also proposed in [RFC5286] Section 3.8.
o PE router : Provider Edge router. These routers are connecting
customers
o P router : Provider router. These routers are core routers,
without customer connections. They provide transit between PE
routers and they form the core network.
o Core network : subset of the network composed by P routers and
links between them.
o Core link : network link part of the core network i.e. a P router
to P router link.
o Link-protecting LFA : alternate providing protection against link
failure.
o Node-protecting LFA : alternate providing protection against node
failure.
o Connected alternate : alternate adjacent (at IGP level) to the
point of local repair (i.e. an IGP neighbor).
o Remote alternate : alternate which is does not share an IGP
adjacency with the point of local repair.
2. Introduction
Following the first deployments of Loop Free Alternates (LFA), this Following the first deployments of Loop Free Alternates (LFA), this
document provides feedback to the community about the management of document provides feedback to the community about the management of
LFA. LFA.
Section 2 provides real uses cases illustrating some limitations Section 3 provides real uses cases illustrating some limitations
and suboptimal behavior. and suboptimal behavior.
Section 4 proposes requirements for activation granularity and Section 5 proposes requirements for activation granularity and
policy based selection of the alternate. policy based selection of the alternate.
Section 5 express requirements for the operational management of Section 6 express requirements for the operational management of
LFA. LFA.
2. 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.
Note that the use case of per-prefix LFA is assumed throughout this Note that the use case of LFA computation per destination (per-prefix
analysis. LFA) is assumed throughout this analysis. We also assume in the
network figures that all IP prefixes are advertised with zero cost.
2.1. Case 1: Edge router protecting core failures 3.1. Case 1: PE router protecting failures within core network
R1 --------- R2 ---------- R3 --------- R4
P1 --------- P2 ---------- P3 --------- P4
| 1 100 1 | | 1 100 1 |
| | | |
| 100 | 100 | 100 | 100
| | | |
| 1 100 1 | | 1 100 1 | 1 5k
R5 --------- R6 ---------- R7 --------- R8 -- R9 - PE1 P5 --------- P6 ---------- P7 --------- P8 --- P9 -- PE1
| | | | | | | | | |
| 5k | 5k | 5k | 5k 5k| |5k 5k| |5k | 5k | 5k
| | | | | | | | | |
+--- n*PEx ---+ +---- PE2 ----+ | +-- PE4 --+ | +---- PE2 ----+
| | | |
| +---- PE5 ----+ | 5k
PEy |
PE3
Figure 1 Figure 1
Rx routers are core routers using n*10G links. PEs are connected Px routers are P routers using n*10G links. PEs are connected using
using links with lower bandwidth. PEx are a set of PEs connected to links with lower bandwidth.
R5 and R6.
In figure 1, let us consider the traffic flowing from PE1 to PEx. In figure 1, let us consider the traffic flowing from PE1 to PE4.
The nominal path is R9-R8-R7-R6-PEx. Let us consider the failure of The nominal path is P9-P8-P7-P6-PE4. Let us consider the failure of
link R7-R8. For R8, R4 is not an LFA and the only available LFA is link P7-P8. For P8, P4 is not an LFA and the only available LFA is
PE2. PE2.
When the core link R8-R7 fails, R8 switches all traffic destined to When the core link P8-P7 fails, P8 switches all traffic destined to
all the PEx towards the edge node PE2. Hence an edge node and edge PE4/PE5 towards the node PE2. Hence a PE node and PE links are used
links are used to protect the failure of a core link. Typically, to protect the failure of a core link. Typically, PE links have less
edge links have less capacity than core links and congestion may capacity than core links and congestion may occur on PE2 links. Note
occur on PE2 links. Note that although PE2 was not directly affected that although PE2 was not directly affected by the failure, its links
by the failure, its links become congested and its traffic will become congested and its traffic will suffer from the congestion.
suffer from the congestion.
In summary, in case of failure, the impact on customer traffic is: In summary, in case of P8-P7 link failure, the impact on customer
traffic is:
o From PE2 point of view : o From PE2 point of view :
* without LFA: no impact * without LFA: no impact
* with LFA: traffic is partially dropped (but possibly * with LFA: traffic is partially dropped (but possibly
prioritized by a QoS mechanism). It must be highlighted that prioritized by a QoS mechanism). It must be highlighted that
in such situation, traffic not affected by the failure may be in such situation, traffic not affected by the failure may be
affected by the congestion. affected by the congestion.
o From R8 point of view: o From P8 point of view:
* without LFA: traffic is totally dropped until convergence * without LFA: traffic is totally dropped until convergence
occurs. occurs.
* with LFA: traffic is partially dropped (but possibly * with LFA: traffic is partially dropped (but possibly
prioritized by a QoS mechanism). prioritized by a QoS mechanism).
Besides the congestion aspects of using an Edge router as an Besides the congestion aspects of using an Edge router as an
alternate to protect a core failure, a service provider may consider alternate to protect a core failure, a service provider may consider
this as a bad routing design and would like to prevent it. this as a bad routing design and would like to prevent it.
2.2. Case 2: Edge router choosen to protect core failures while core 3.2. Case 2: PE router choosen to protect core failures while P router
LFA exists LFA exists
P1 --------- P2 ------------ P3 -------- P4
R1 --------- R2 ------------ R3 --------- R4
| 1 100 | 1 | | 1 100 | 1 |
| | | | | |
| 100 | 30 | 30 | 100 | 30 | 30
| | | | | |
| 1 50 50 | 10 | | 1 50 50 | 10 | 1 5k
R5 -------- R6 ---- R10 ---- R7 -------- R8 --- R9 - PE1 P5 --------- P6 --- P10 ---- P7 -------- P8 --- P9 -- PE1
| | \ | | | | | \ |
| 5000 | 5000 \ 5000 | 5000 5k| |5k 5k| |5k \ 5k | 5k
| | \ | | | | | \ |
+--- n*PEx --+ +----- PE2 ----+ | +-- PE4 --+ | +---- PE2 ----+
| | | |
| +---- PE5 ----+ | 5k
PEy |
PE3
Figure 2 Figure 2
Rx routers are core routers meshed with n*10G links. PEs are meshed Px routers are P routers meshed with n*10G links. PEs are meshed
using links with lower bandwidth. using links with lower bandwidth.
In the figure 2, let us consider the traffic coming from PE1 to PEx. In the figure 2, let us consider the traffic coming from PE1 to PE4.
Nominal path is R9-R8-R7-R10-R6-PEx. Let us consider the failure of Nominal path is P9-P8-P7-P10-P6-PE4. Let us consider the failure of
the link R7-R8. For R8, R4 is a link-protecting LFA and PE2 is a the link P7-P8. For P8, P4 is a link-protecting LFA and PE2 is a
node-protecting LFA. PE2 is chosen as best LFA due to its better node-protecting LFA. PE2 is chosen as best LFA due to its better
protection type. Just like in case 1, this may lead to congestion on protection type. Just like in case 1, this may lead to congestion on
PE2 links upon LFA activation. PE2 links upon LFA activation.
2.3. Case 3: suboptimal core alternate choice 3.3. Case 3: suboptimal P router alternate choice
+--- PE3 --+ +--- PE3 --+
/ \ / \
1000 / \ 1000 1000 / \ 1000
/ \ / \
+----- R1 ---------------- R2 ----+ +----- P1 ---------------- P2 ----+
| | 500 | | | | 500 | |
| 10 | | | 10 | 10 | | | 10
| | | | | | | |
R5 | 10 | 10 R7 R5 | 10 | 10 R7
| | | | | | | |
| 10 | | | 10 | 10 | | | 10
| | 500 | | | | 500 | |
+---- R3 ---------------- R4 -----+ +---- P3 ---------------- P4 -----+
\ / \ /
1000 \ / 1000 1000 \ / 1000
\ / \ /
+--- PE1 ---+ +--- PE1 ---+
Figure 3 Figure 3
Rx routers are core routers. R1-R2 and R3-R4 links are 1G links. Px routers are P routers. P1-P2 and P3-P4 links are 1G links. All
All others inter Rx links are 10G links. others inter Px links are 10G links.
In the figure above, let us consider the failure of link R1-R3. For In the figure above, let us consider the failure of link P1-P3. For
destination PE3, R3 has two possible alternates: destination PE3, P3 has two possible alternates:
o R4, which is node-protecting o P4, which is node-protecting
o R5, which is link-protecting o P5, which is link-protecting
R4 is chosen as best LFA due to its better protection type. However, P4 is chosen as best LFA due to its better protection type. However,
it may not be desirable to use R4 for bandwidth capacity reason. A it may not be desirable to use P4 for bandwidth capacity reason. A
service provider may prefer to use high bandwidth links as prefered service provider may prefer to use high bandwidth links as prefered
LFA. In this example, prefering shortest path over protection type LFA. In this example, prefering shortest path over protection type
may achieve the expected behavior, but in cases where metric are not may achieve the expected behavior, but in cases where metric are not
reflecting bandwidth, it would not work and some other criteria would reflecting bandwidth, it would not work and some other criteria would
need to be involved when selecting the best LFA. need to be involved when selecting the best LFA.
2.4. Case 4: ISIS overload bit on LFA computing node 3.4. Case 4: IS-IS overload bit on LFA computing node
P1 P2 P1 P2
| \ / | | \ / |
50 | 50 \/ 50 | 50 50 | 50 \/ 50 | 50
| /\ | | /\ |
PE1-+ +-- PE2 PE1-+ +-- PE2
\ / \ /
45 \ / 45 45 \ / 45
-PE3-+ -PE3-+
(OL set) (OL set)
Figure 4 Figure 4
In the figure above, PE3 has its overload bit set (permanently, for In the figure above, PE3 has its overload bit set (permanently, for
design reason) and wants to protect traffic using LFA for destination design reason) and wants to protect traffic using LFA for destination
PE2. PE2.
On PE3, the loopfree condition is not satisified : 100 !< 45 + 45. On PE3, the loop-free condition is not satisfied : 100 !< 45 + 45.
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 loopfree 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.
3. 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 ([I-D.ietf-rtgwg-remote-lfa]) extends
significantly the coverage of the basic LFA specification, there is significantly the coverage of the basic LFA specification, there is
still some cases where protection would not be available. As network still some cases where protection would not be available. As network
topologies are constantly evolving (network extension, capacity topologies are constantly evolving (network extension, capacity
addings, latency optimization ...), the protection coverage may addings, latency optimization ...), the protection coverage may
change. Fast reroute functionality may be critical for some services change. Fast reroute functionality may be critical for some services
supported by the network, a service provider must constantly know supported by the network, a service provider must constantly know
what protection coverage is currently available on the network. what protection coverage is currently available on the network.
Moreover, predicting the protection coverage in case of network Moreover, predicting the protection coverage in case of network
topology change is mandatory. topology change is mandatory.
Today network simulation tool associated with whatif scenarios Today network simulation tool associated with whatif scenarios
functionnality 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 6.5, network design (capacity, path optimization ...). Section 7.5,
Section 6.4 and Section 6.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.
o to adjust the topology change to cover the primary need (e.g. o to adjust the topology change to cover the primary need (e.g.
latency optimization or bandwidth increase) as well as LFA latency optimization or bandwidth increase) as well as LFA
protection. protection.
o monitor constantly the LFA coverage in the live network and being o monitor constantly the LFA coverage in the live network and being
alerted. alerted.
4. Need for LFA activation granularity Implementers SHOULD document their LFA selection algorithms (default
and tuning options) in order to leave possibility for 3rd party
modules to model these policy-LFA expressions.
5. Need for LFA activation granularity
As all FRR mechanism, LFA installs backup paths in Forwarding As all FRR mechanism, LFA installs backup paths in Forwarding
Information Base (FIB). Depending of the hardware used by a service Information Base (FIB). Depending of the hardware used by a service
provider, FIB ressource may be critical. Activating LFA, by default, provider, FIB resource may be critical. Activating LFA, by default,
on all available components (IGP topologies, interface, address on all available components (IGP topologies, interface, address
families ...) may lead to waste of FIB ressource as generally in a families ...) may lead to waste of FIB resource as generally in a
network only few destinations should be protected (e.g. loopback network only few destinations should be protected (e.g. loopback
addresses supporting MPLS services) compared to the amount of addresses supporting MPLS services) compared to the amount of
destinations in RIB. destinations in RIB.
Moreover a service provider may implement multiple different FRR Moreover a service provider may implement multiple different FRR
mechanism in its networks for different usages (MRT, TE FRR), mechanism in its networks for different usages (MRT, TE FRR). In
computing LFAs for prefixes or interfaces that are already protected this scenario, an implementation MAY permit to compute alternates for
by another mechanism is useless. a specific destination even if the destination is already protected
by another mechanism. This will bring redundancy and let the ability
for the operator to select the best option for FRR using a policy
langage.
Section 5 of this document propose some implementation guidelines. Section 6 of this document propose some implementation guidelines.
5. Configuration requirements 6. Configuration requirements
Controlling best alternate and LFA activation granularity is a Controlling best alternate and LFA activation granularity is a
requirement for Service Providers. This section defines requirement for Service Providers. This section defines
configuration requirements for LFA. configuration requirements for LFA.
5.1. LFA enabling/disabling scope 6.1. LFA enabling/disabling scope
The granularity of LFA activation should be controlled (as alternate The granularity of LFA activation should be controlled (as alternate
nexthop consume memory in forwarding plane). next hop consume memory in forwarding plane).
An implementation of LFA SHOULD allow its activation with the An implementation of LFA SHOULD allow its activation with the
following criteria: following criteria:
o Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast, o Per routing context: VRF, virtual/logical router, global routing
LDP IPv6 unicast ...
o Per routing context : VRF, virtual/logical router, global routing
table, ... table, ...
o Per interface o Per interface
o Per protocol instance, topology, area o Per protocol instance, topology, area
o Per prefixes: prefix protection SHOULD have a better priority o Per prefixes: prefix protection SHOULD have a better priority
compared to interface protection. This means that if a specific compared to interface protection. This means that if a specific
prefix must be protected due to a configuration request, LFA must prefix must be protected due to a configuration request, LFA must
be computed and installed for this prefix even if the primary be computed and installed for this prefix even if the primary
outgoing interface is not configured for protection. outgoing interface is not configured for protection.
5.2. Policy based LFA selection An implementation of LFA MAY allow its activation with the following
criteria:
o Per address-family: ipv4 unicast, ipv6 unicast
o Per MPLS control plane: for MPLS control planes that inherit
routing decision from the IGP routing protocol, MPLS dataplane may
be protected by LFA. The implementation may allow operator to
control this inheritance of protection from the IP prefix to the
MPLS label bound to this prefix. The protection inheritance will
concern : IP to MPLS, MPLS to MPLS, and MPLS to IP entries. As
example, LDP and segment-routing extensions for ISIS and OSPF are
control plane eligible to this inheritance of protection.
6.2. Policy based LFA selection
When multiple alternates exist, LFA selection algorithm is based on When multiple alternates exist, LFA selection algorithm is based on
tie breakers. Current tie breakers do not provide sufficient control tie breakers. Current tie breakers do not provide sufficient control
on how the best alternate is chosen. This document proposes an on how the best alternate is chosen. This document proposes an
enhanced tie breaker allowing service providers to manage all enhanced tie breaker allowing service providers to manage all
specific cases: specific cases:
1. An implementation of LFA SHOULD support policy-based decision for 1. An implementation of LFA SHOULD support policy-based decision for
determining the best LFA. determining the best LFA.
skipping to change at page 9, line 43 skipping to change at page 11, line 14
5. It is an implementation choice to reevaluate policy dynamically 5. It is an implementation choice to reevaluate policy dynamically
or not (in case of policy change). If a dynamic approach is or not (in case of policy change). If a dynamic approach is
chosen, the implementation SHOULD recompute the best LFAs and chosen, the implementation SHOULD recompute the best LFAs and
reinstall them in FIB, without service disruption. If a non- reinstall them in FIB, without service disruption. If a non-
dynamic approach is chosen, the policy would be taken into dynamic approach is chosen, the policy would be taken into
account upon the next IGP event. In this case, the account upon the next IGP event. In this case, the
implementation SHOULD support a command to manually force the implementation SHOULD support a command to manually force the
recomputation/reinstallation of LFAs. recomputation/reinstallation of LFAs.
5.2.1. Connected vs remote alternates 6.2.1. Connected vs remote alternates
In addition to direct LFAs, tunnels (e.g. IP, LDP or RSVP-TE) to In addition to connected LFAs, tunnels (e.g. IP, LDP, RSVP-TE or
distant routers may be used to complement LFA coverage (tunnel tail Segment Routing) to distant routers may be used to complement LFA
used as virtual neighbor). When a router has multiple alternate coverage (tunnel tail used as virtual neighbor). When a router has
candidates for a specific destination, it may have connected multiple alternate candidates for a specific destination, it may have
alternates and remote alternates reachable via a tunnel. Connected connected alternates and remote alternates (reachable via a tunnel).
alternates may not always provide an optimal routing path and it may Connected alternates may not always provide an optimal routing path
be preferable to select a remote alternate over a connected and it may be preferable to select a remote alternate over a
alternate. The usage of tunnels to extend LFA coverage is described connected alternate. Some usage of tunnels to extend LFA ([RFC5286])
in [I-D.ietf-rtgwg-remote-lfa]. coverage is described in either [I-D.ietf-rtgwg-remote-lfa] or
[I-D.francois-segment-routing-ti-lfa]. These documents present some
use cases of LDP tunnels ([I-D.ietf-rtgwg-remote-lfa]) or Segment
Routing tunnels ([I-D.francois-segment-routing-ti-lfa]). This
document considers any type of tunneling techniques to reach remote
alternates (IP, GRE, LDP, RSVP-TE, L2TP, Segment Routing ...) and
does not restrict the remote alternates to the usage presented in the
referenced document.
In figure 1, there is no core alternate for R8 to reach PEs located In figure 1, there is no P router alternate for P8 to reach PE4 or
behind R6, so R8 is using PE2 as alternate, which may generate PE5 , so P8 is using PE2 as alternate, which may generate congestion
congestion when FRR is activated. Instead, we could have a remote when FRR is activated. Instead, we could have a remote alternate for
core alternate for R8 to protect PEs destinations. For example, a P8 to protect traffic to PE4 and PE5. For example, a tunnel from P8
tunnel from R8 to R3 would ensure LFA protection without using an to P3 (following shortest path) can be setup and P8 would be able to
edge router to protect a core router. 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.
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). Especially,
computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD be
performed before best alternate selection. performed before best alternate selection.
5.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 nexthop being protected by another primary nexthop 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 fallback 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 5.2.6 o SRLG (as defined in [RFC5286] Section 3, see also Section 6.2.6
for more details). for more details).
5.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 5.2.7). (see Section 6.2.7).
o Link Bandwidth (see Section 5.2.8). o Link Bandwidth (see Section 6.2.8).
o Alternate preference (see Section 5.2.9). o Alternate preference/Node coloring (see Section 6.2.9).
5.2.4. Retrieving alternate path attributes 6.2.4. Retrieving alternate path attributes
The policy to select the best alternate evaluate multiple criterions The policy to select the best alternate evaluate multiple criterions
(e.g. metric, SRLG, link colors ...) which first need to be computed (e.g. metric, SRLG, link colors ...) which first need to be computed
for each alternate.. In order to compare the different alternate for each alternate.. In order to compare the different alternate
path, a router must retrieve the attributes of each alternate path. path, a router must retrieve the attributes of each alternate path.
The alternate path is composed of two distinct parts : PLR to The alternate path is composed of two distinct parts : PLR to
alternate and alternate to destination. alternate and alternate to destination.
5.2.4.1. Connected alternate 6.2.4.1. Connected alternate
For alternate path using a connected alternate : For alternate path using a connected alternate :
o attributes from PLR to alternate path are retrieved from the o attributes from PLR to alternate path are retrieved from the
interface connected to the alternate. interface connected to the alternate.
o attributes from alternate to destination path are retrieved from o attributes from alternate to destination path are retrieved from
SPF rooted at the alternate. As the alternate is a connected SPF rooted at the alternate. As the alternate is a connected
alternate, the SPF has already been computed to find the alternate, the SPF has already been computed to find the
alternate, so there is no need of additional computation. alternate, so there is no need of additional computation.
5.2.4.2. Remote alternate 6.2.4.2. Remote alternate
For alternate path using a remote alternate (tunnel) : For alternate path using a remote alternate (tunnel) :
o attributes from the PLR to alternate path are retrieved using the 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 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 if extended P space is used, combined with the attributes of the
link(s) to reach that neighbor. In both cases, no additional SPF link(s) to reach that neighbor. In both cases, no additional SPF
is required. is required.
o attributes from alternate to destination path are retrieved from o attributes from alternate to destination path may be retrieved
SPF rooted at the remote alternate. An additional forward SPF is from SPF rooted at the remote alternate. An additional forward
required for each remote alternate as indicated in SPF is required for each remote alternate as indicated in
[I-D.ietf-rtgwg-rlfa-node-protection] section 3.2.. [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, simulations shown The number of remote alternates may be very high. In case of remote
that hundred's of PQs may exist for a single interface being LFA, simulations of real-world network topologies, reveal that order
protected. Running a forward SPF for every PQ-node in the network is of hundreths of PQ ...
not scalable.
To handle this situation, it is needed to limit the number of remote To handle this situation, it is needed to limit the number of remote
alternates to be evaluated to a finite number before collecting alternates to be evaluated to a finite number before collecting
alternate path attributes and running the policy evaluation. [I- alternate path attributes and running the policy evaluation. [I-
D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to D.ietf-rtgwg-rlfa-node-protection] Section 2.3.3 provides a way to
reduce the number of PQ to be evaluated. 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 Link Remote Remote
alternate alternate alternate alternate alternate alternate
------------- ------------------ ------------- ------------- ------------------ -------------
Alternates | LFA | | rLFA (PQs) | | Static | Alternates | LFA | | rLFA (PQs) | | Static/ |
| | | | | Dynamic |
sources | | | | | tunnels | sources | | | | | tunnels |
------------- ------------------ ------------- ------------- ------------------ -------------
| | | | | |
| | | | | |
| ---------------------- | | -------------------------- |
| | Prune some PQs | | | | Prune some alternates | |
| | (sorting strategy) | | | | (sorting strategy) | |
| ---------------------- | | -------------------------- |
| | | | | |
| | | | | |
------------------------------------------------ ------------------------------------------------
| Collect alternate attributes | | Collect alternate attributes |
------------------------------------------------ ------------------------------------------------
| |
| |
------------------------- -------------------------
| Evaluate policy | | Evaluate policy |
------------------------- -------------------------
| |
| |
Best alternates Best alternates
5.2.5. ECMP LFAs 6.2.5. ECMP LFAs
10 10
PE2 - PE3 PE2 - PE3
| | | |
50 | 5 | 50 50 | 5 | 50
P1----P2 P1----P2
\\ // \\ //
50 \\ // 50 50 \\ // 50
PE1 PE1
Figure 5 Figure 5
Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are Links between P1 and PE1 are L1 and L2, links between P2 and PE1 are
L3 and L4 L3 and L4
In the figure above, primary path from PE1 to PE2 is through P1 using 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 ECMP on two parallel links L1 and L2. In case of standard ECMP
behavior, if L1 is failing, postconvergence nexthop would become L2 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 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 [RFC5286] Section 3.4., "alternate next-hops may themselves also be
primary next-hops, but need not be" and "alternate next-hops should primary next-hops, but need not be" and "alternate next-hops should
maximize the coverage of the failure cases". In this scenario there maximize the coverage of the failure cases". In this scenario there
is no alternate providing node protection, LFA will so prefer L2 as is no alternate providing node protection, LFA will so prefer L2 as
alternate to protect L1 which makes sense compared to postconvergence alternate to protect L1 which makes sense compared to postconvergence
behavior. behavior.
Considering a different scenario using figure 5, where L1 and L2 are 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/ 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 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 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 of the bundle. Layer 3 bundles are generally introduced to increase
bandwidth between nodes. In nominal situation, ECMP is still bandwidth between nodes. In nominal situation, ECMP is still
available from PE1 to PE2, but if L1 is failing, postconvergence available from PE1 to PE2, but if L1 is failing, postconvergence next
nexthop would become ECMP on L3 and L4. In this case, LFA behavior hop would become ECMP on L3 and L4. In this case, LFA behavior
SHOULD be adapted in order to reflect the bandwidth requirement. SHOULD be adapted in order to reflect the bandwidth requirement.
We would expect the following FIB entry on PE1 : We would expect the following FIB entry on PE1 :
On PE1 : PE2 +--> ECMP -> L1 On PE1 : PE2 +--> ECMP -> L1
| | | |
| +----> L2 | +----> L2
| |
+--> LFA(ECMP) -> L3 +--> LFA(ECMP) -> L3
| |
+---------> L4 +---------> L4
If L1 or L2 is failing, traffic must be switched on the LFA ECMP If L1 or L2 is failing, traffic must be switched on the LFA ECMP
bundle rather than using the other primary nexthop. bundle rather than using the other primary next hop.
As mentioned in [RFC5286] Section 3.4., protecting a link within an As mentioned in [RFC5286] Section 3.4., protecting a link within an
ECMP by another primary nexthop is not a MUST. Moreover, we already ECMP by another primary next hop is not a MUST. Moreover, we already
presented in this document, that maximizing the coverage of the presented in this document, that maximizing the coverage of the
failure case may not be the right approach and policy based choice of failure case may not be the right approach and policy based choice of
alternate may be preferred. alternate may be preferred.
An implementation SHOULD permit to prefer a primary nexthop by An implementation SHOULD permit to prefer to protect a primary next
another primary nexthop with the possibility to deactivate this hop by another primary next hop. An implementation SHOULD permit to
criteria. An implementation SHOULD permit to use an ECMP bundle as a prefer to protect a primary next hop by a NON primary next hop. An
LFA. implementation SHOULD permit to use an ECMP bundle as a LFA.
5.2.6. SRLG 6.2.6. 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 number of
SRLG violations : more violations = less preference. SRLG violations : more violations = less preference.
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. In the case of remote LFA, PQ to destination path attributes paths based on the SRLG set of the primary path. In the case of
would be retrieved from SPT rooted at PQ. remote LFA, PQ to destination path attributes would be retrieved from
SPT rooted at PQ.
5.2.7. Link coloring 6.2.7. 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.
PE2 PE2
| +---- P4 | +---- P4
| / | /
PE1 ---- P1 --------- P2 PE1 ---- P1 --------- P2
| 10Gb | 10Gb
1Gb | 1Gb |
| |
P3 P3
Figure 5 Figure 5
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:
skipping to change at page 15, line 35 skipping to change at page 17, line 35
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.
5.2.8. Bandwidth 6.2.8. Bandwidth
As mentionned in previous sections, not taking into account bandwidth As mentionned 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 ...
skipping to change at page 16, line 12 skipping to change at page 18, line 12
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 two
ways : 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 nexthop 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 his bandwidth to reach it compared
to the link speed of the primary nexthop interface. to the link speed of the primary next hop interface.
5.2.9. Alternate preference 6.2.9. 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 5.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 ISIS protocol (tag) (for example, in case of IS-IS protocol
[I-D.ietf-isis-node-admin-tag] can be used) [I-D.ietf-isis-node-admin-tag] can be used). Using a tag is referred
as Node coloring in comparison to link coloring option presented in
Section 6.2.7.
Consider the following network: Consider the following network:
PE3 PE3
| |
| |
PE2 PE2
| +---- P4 | +---- P4
| / | /
PE1 ---- P1 -------- P2 PE1 ---- P1 -------- P2
skipping to change at page 17, line 35 skipping to change at page 19, line 35
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. Operational aspects 7. Operational aspects
6.1. ISIS 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
IS-IS overload bit of the LFA calculating neighbor (S) SHOULD be IS-IS overload bit of the LFA calculating neighbor (S) SHOULD be
taken into account. Indeed, if it has the overload bit set, no taken into account. Indeed, if it has the overload bit set, no
neighbor will loop back to traffic to itself. neighbor will loop back to traffic to itself.
6.2. Manual triggering of FRR 7.2. Manual triggering of FRR
Service providers often perform manual link shutdown (using router Service providers often perform manual link shutdown (using router
CLI) to perform some network changes/tests. A manual link shutdown CLI) to perform some network changes/tests. A manual link shutdown
may be done at multiple level : physical interface, logical may be done at multiple level : physical interface, logical
interface, IGP interface, BFD session ... Especially testing or interface, IGP interface, BFD session ... Especially testing or
troubleshooting FRR requires to perform the manual shutdown on the troubleshooting FRR requires to perform the manual shutdown on the
remote end of the link as generally a local shutdown would not remote end of the link as generally a local shutdown would not
trigger FRR. trigger FRR.
To enhance such situation, an implementation SHOULD support To enhance such situation, an implementation SHOULD support
skipping to change at page 19, line 5 skipping to change at page 21, line 5
implementation does not support FRR activation on physical link implementation does not support FRR activation on physical link
down event, there is no need for this implementation to support down event, there is no need for this implementation to support
FRR activation on manual physical link shutdown. FRR activation on manual physical link shutdown.
o A CLI command may permit to switch from primary path to FRR path o A CLI command may permit to switch from primary path to FRR path
for testing FRR path for a specific. There is no impact on for testing FRR path for a specific. There is no impact on
controlplane, only dataplane of the local node could be changed. controlplane, only dataplane of the local node could be changed.
A similar command may permit to switch back traffic from FRR path A similar command may permit to switch back traffic from FRR path
to primary path. to primary path.
6.3. Required local information 7.3. Required local information
LFA introduction requires some enhancement in standard routing LFA introduction requires some enhancement in standard routing
information provided by implementations. Moreover, due to the non information provided by implementations. Moreover, due to the non
100% coverage, coverage informations is also required. 100% coverage, coverage informations is also required.
Hence an implementation : Hence an implementation :
o MUST be able to display, for every prefixes, the primary nexthop o MUST be able to display, for every prefixes, the primary next hop
as well as the alternate nexthop information. as well as the alternate next hop information.
o MUST provide coverage information per activation domain of LFA o MUST provide coverage information per activation domain of LFA
(area, level, topology, instance, virtual router, address family (area, level, topology, instance, virtual router, address family
...). ...).
o MUST provide number of protected prefixes as well as non protected o MUST provide number of protected prefixes as well as non protected
prefixes globally. prefixes globally.
o SHOULD provide number of protected prefixes as well as non o SHOULD provide number of protected prefixes as well as non
protected prefixes per link. protected prefixes per link.
o MAY provide number of protected prefixes as well as non protected o MAY provide number of protected prefixes as well as non protected
prefixes per priority if implementation supports prefix-priority prefixes per priority if implementation supports prefix-priority
insertion in RIB/FIB. insertion in RIB/FIB.
o SHOULD provide a reason for chosing an alternate (policy and o SHOULD provide a reason for choosing an alternate (policy and
criteria) and for excluding an alternate. criteria) and for excluding an alternate.
o SHOULD provide the list of non protected prefixes and the reason o SHOULD provide the list of non protected prefixes and the reason
why they are not protected (no protection required or no alternate why they are not protected (no protection required or no alternate
available). available).
6.4. Coverage monitoring 7.4. Coverage monitoring
It is pretty easy to evaluate the coverage of a network in a nominal It is pretty easy to evaluate the coverage of a network in a nominal
situation, but topology changes may change the coverage. In some situation, but topology changes may change the coverage. In some
situations, the network may no longer be able to provide the required situations, the network may no longer be able to provide the required
level of protection. Hence, it becomes very important for service level of protection. Hence, it becomes very important for service
providers to get alerted about changes of coverage. providers to get alerted about changes of coverage.
An implementation SHOULD : An implementation SHOULD :
o provide an alert system if total coverage (for a node) is below a o provide an alert system if total coverage (for a node) is below a
skipping to change at page 20, line 14 skipping to change at page 22, line 14
An implementation MAY : An implementation MAY :
o provide an alert system if a specific destination is not protected o provide an alert system if a specific destination is not protected
anymore or when protection comes back up for this destination anymore or when protection comes back up for this destination
Although the procedures for providing alerts are beyond the scope of Although the procedures for providing alerts are beyond the scope of
this document, we recommend that implementations consider standard this document, we recommend that implementations consider standard
and well used mechanisms like syslog or SNMP traps. and well used mechanisms like syslog or SNMP traps.
6.5. LFA and network planning 7.5. LFA and network planning
The operator may choose to run simulations in order to ensure full The operator may choose to run simulations in order to ensure full
coverage of a certain type for the whole network or a given subset of coverage of a certain type for the whole network or a given subset of
the network. This is particularly likely if he operates the network the network. This is particularly likely if he operates the network
in the sense of the third backbone profiles described in [RFC6571], in the sense of the third backbone profiles described in [RFC6571],
that is, he seeks to design and engineer the network topology in a that is, he seeks to design and engineer the network topology in a
way that a certain coverage is always achieved. Obviously a complete way that a certain coverage is always achieved. Obviously a complete
and exact simulation of the IP FRR coverage can only be achieved, if and exact simulation of the IP FRR coverage can only be achieved, if
the behavior is deterministic and if the algorithm used is available the behavior is deterministic and if the algorithm used is available
to the simulation tool. Thus, an implementation SHOULD: to the simulation tool. Thus, an implementation SHOULD:
skipping to change at page 20, line 39 skipping to change at page 22, line 39
prefix. prefix.
o Document its behavior. The implementation SHOULD provide enough o Document its behavior. The implementation SHOULD provide enough
documentation of its behavior that allows an implementer of a documentation of its behavior that allows an implementer of a
simulation tool, to foresee the exact choice of the LFA simulation tool, to foresee the exact choice of the LFA
implementation for every prefix in a given topology. This SHOULD implementation for every prefix in a given topology. This SHOULD
take into account all possible policy configuration options. One take into account all possible policy configuration options. One
possible way to document this behavior is to disclose the possible way to document this behavior is to disclose the
algorithm used to choose alternates. algorithm used to choose alternates.
7. Security Considerations 8. Security Considerations
This document does not introduce any change in security consideration This document does not introduce any change in security consideration
compared to [RFC5286]. compared to [RFC5286].
8. Contributors 9. Contributors
Significant contributions were made by Pierre Francois, Hannes Significant contributions were made by Pierre Francois, Hannes
Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri and Mustapha Gredler, Chris Bowers, Jeff Tantsura, Uma Chunduri and Mustapha
Aissaoui which the authors would like to acknowledge. Aissaoui which the authors would like to acknowledge.
9. Acknowledgements 10. Acknowledgements
10. IANA Considerations 11. IANA Considerations
This document has no action for IANA. This document has no action for IANA.
11. References 12. References
11.1. Normative References 12.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.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)", of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005. RFC 4203, October 2005.
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of Intermediate System (IS-IS) Extensions in Support of
skipping to change at page 21, line 39 skipping to change at page 23, 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.
11.2. Informative References 12.2. Informative References
[I-D.francois-segment-routing-ti-lfa]
Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,
"Topology Independent Fast Reroute using Segment Routing",
draft-francois-segment-routing-ti-lfa-00 (work in
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-00 (work in progress),
December 2014. December 2014.
[I-D.ietf-rtgwg-remote-lfa] [I-D.ietf-rtgwg-remote-lfa]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate Fast Re-Route", draft- So, "Remote Loop-Free Alternate (LFA) Fast Re-Route
ietf-rtgwg-remote-lfa-10 (work in progress), January 2015. (FRR)", draft-ietf-rtgwg-remote-lfa-11 (work in progress),
January 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-01
(work in progress), December 2014. (work in progress), December 2014.
Authors' Addresses Authors' Addresses
Stephane Litkowski Stephane Litkowski
 End of changes. 101 change blocks. 
204 lines changed or deleted 281 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/