draft-ietf-rtgwg-lfa-manageability-02.txt   draft-ietf-rtgwg-lfa-manageability-03.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: August 7, 2014 C. Filsfils Expires: August 16, 2014 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
February 3, 2014 February 12, 2014
Operational management of Loop Free Alternates Operational management of Loop Free Alternates
draft-ietf-rtgwg-lfa-manageability-02 draft-ietf-rtgwg-lfa-manageability-03
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 August 7, 2014. This Internet-Draft will expire on August 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 19
2.1. Case 1: Edge router protecting core failures . . . . . . . 5 2.1. Case 1: Edge router protecting core failures . . . . . . . 5
2.2. Case 2: Edge router choosen to protect core failures 2.2. Case 2: Edge router choosen to protect core failures
while core LFA exists . . . . . . . . . . . . . . . . . . 6 while core LFA exists . . . . . . . . . . . . . . . . . . 6
2.3. Case 3: suboptimal core alternate choice . . . . . . . . . 7 2.3. Case 3: suboptimal core alternate choice . . . . . . . . . 7
2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 8 2.4. Case 4: ISIS overload bit on LFA computing node . . . . . 8
3. Need for coverage monitoring . . . . . . . . . . . . . . . . . 8 3. Need for coverage monitoring . . . . . . . . . . . . . . . . . 8
4. Need for LFA activation granularity . . . . . . . . . . . . . 9 4. Need for LFA activation granularity . . . . . . . . . . . . . 9
5. Configuration requirements . . . . . . . . . . . . . . . . . . 9 5. Configuration requirements . . . . . . . . . . . . . . . . . . 9
5.1. LFA enabling/disabling scope . . . . . . . . . . . . . . . 9 5.1. LFA enabling/disabling scope . . . . . . . . . . . . . . . 9
5.2. Policy based LFA selection . . . . . . . . . . . . . . . . 10 5.2. Policy based LFA selection . . . . . . . . . . . . . . . . 10
5.2.1. Connected vs remote alternates . . . . . . . . . . . . 10 5.2.1. Connected vs remote alternates . . . . . . . . . . . . 11
5.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . . 11 5.2.2. Mandatory criteria . . . . . . . . . . . . . . . . . . 11
5.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 11 5.2.3. Enhanced criteria . . . . . . . . . . . . . . . . . . 12
5.2.4. Retrieving alternate path attributes . . . . . . . . . 11 5.2.4. Retrieving alternate path attributes . . . . . . . . . 12
5.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 13 5.2.5. ECMP LFAs . . . . . . . . . . . . . . . . . . . . . . 14
5.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.6. SRLG . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 15 5.2.7. Link coloring . . . . . . . . . . . . . . . . . . . . 16
5.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 16 5.2.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . 17
5.2.9. Neighbor preference . . . . . . . . . . . . . . . . . 17 5.2.9. Alternate preference . . . . . . . . . . . . . . . . . 18
6. Operational aspects . . . . . . . . . . . . . . . . . . . . . 18 6. Operational aspects . . . . . . . . . . . . . . . . . . . . . 19
6.1. ISIS overload bit on LFA computing node . . . . . . . . . 18 6.1. ISIS overload bit on LFA computing node . . . . . . . . . 19
6.2. Manual triggering of FRR . . . . . . . . . . . . . . . . . 18 6.2. Manual triggering of FRR . . . . . . . . . . . . . . . . . 19
6.3. Required local information . . . . . . . . . . . . . . . . 19 6.3. Required local information . . . . . . . . . . . . . . . . 20
6.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 20 6.4. Coverage monitoring . . . . . . . . . . . . . . . . . . . 20
6.5. LFA and network planning . . . . . . . . . . . . . . . . . 20 6.5. LFA and network planning . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. 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 2 provides real uses cases illustrating some limitations
and suboptimal behavior. and suboptimal behavior.
Section 3 proposes requirements for activation granularity and Section 4 proposes requirements for activation granularity and
policy based selection of the alternate. policy based selection of the alternate.
Section 4 express requirements for the operational management of Section 5 express requirements for the operational management of
LFA. LFA.
2. Operational issues with default LFA tie breakers 2. 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
skipping to change at page 8, line 43 skipping to change at page 8, line 43
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 : using network simulation tool and topology change is mandatory.
whatif scenarios functionnality, a service provider may be able to
evaluate protection coverage after a topology change and may be able Today network simulation tool associated with whatif scenarios
to adjust the topology change to cover the primary need (e.g. latency functionnality are often used by service providers for the overall
optimization or bandwidth increase) as well as LFA protection. network design (capacity, path optimization ...). Section 6.5,
Section 6.4 and Section 6.3 of this document propose to add LFA
informations into such tool and within routers, so a service provider
may be able :
o to evaluate protection coverage after a topology change.
o to adjust the topology change to cover the primary need (e.g.
latency optimization or bandwidth increase) as well as LFA
protection.
o monitor constantly the LFA coverage in the live network and being
alerted.
4. Need for LFA activation granularity 4. Need for LFA activation granularity
As all FRR mechanism, LFA installs backup paths in FIB. Depending of As all FRR mechanism, LFA installs backup paths in Forwarding
the hardware used by a service provider, FIB ressource may be Information Base (FIB). Depending of the hardware used by a service
critical. Activating LFA, by default, on all available components provider, FIB ressource may be critical. Activating LFA, by default,
(IGP topologies, interface, address families ...) may lead to waste on all available components (IGP topologies, interface, address
of FIB ressource as generally in a network only few destinations families ...) may lead to waste of FIB ressource as generally in a
should be protected (e.g. loopback addresses supporting MPLS network only few destinations should be protected (e.g. loopback
services) compared to the amount of destinations in RIB. addresses supporting MPLS services) compared to the amount of
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),
computing LFAs for prefixes or interfaces that are already protected computing LFAs for prefixes or interfaces that are already protected
by another mechanism is useless. by another mechanism is useless.
Section 5 of this document propose some implementation guidelines.
5. Configuration requirements 5. 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 5.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). nexthop consume memory in forwarding plane).
skipping to change at page 11, line 30 skipping to change at page 11, line 46
o A primary nexthop being protected by another primary nexthop of o A primary nexthop being protected by another primary nexthop 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 fallback 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). o SRLG (as defined in [RFC5286] Section 3, see also Section 5.2.6
for more details).
5.2.3. Enhanced criteria 5.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 a neighbor : 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).
o Link Bandwidth. o Link Bandwidth (see Section 5.2.8).
o Neighbor preference. o Alternate preference (see Section 5.2.9).
5.2.4. Retrieving alternate path attributes 5.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 5.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.
skipping to change at page 17, line 20 skipping to change at page 18, line 5
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 nexthop 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 nexthop interface.
5.2.9. Neighbor preference 5.2.9. Alternate preference
Rather than tagging interface on each node (using link color) to Rather than tagging interface on each node (using link color) to
identify neighbor 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 neighbors (see Section 5.2.3), an implementation : some specific alternates (see Section 5.2.3), an implementation :
o SHOULD be able to give a preference to specific neighbor. o SHOULD be able to give a preference to specific alternate.
o SHOULD be able to give a preference to a group of neighbor. o SHOULD be able to give a preference to a group of alternate.
o SHOULD be able to exclude a group of neighbor. o SHOULD be able to exclude a group of alternate.
A specific neighbor may be identified by its interface, IP address or A specific alternate may be identified by its interface, IP address
router ID and group of neighbors may be identified by a marker (tag). or router ID and group of alternates may be identified by a marker
(tag).
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 18, line 17 skipping to change at page 19, line 5
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 -> neighbor 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 6. Operational aspects
6.1. ISIS overload bit on LFA computing node 6.1. ISIS 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.
 End of changes. 27 change blocks. 
51 lines changed or deleted 68 lines changed or added

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