Operational management of Loop Free Alternates
draft-litkowski-rtgwg-lfa-manageability-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Stephane Litkowski , Bruno Decraene , Clarence Filsfils , Syed Kamran Raza | ||
| Last updated | 2012-10-15 | ||
| Replaced by | draft-ietf-rtgwg-lfa-manageability, RFC 7916 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-litkowski-rtgwg-lfa-manageability-00
Routing Area Working Group S. Litkowski
Internet-Draft B. Decraene
Intended status: Standards Track Orange
Expires: April 18, 2013 C. Filsfils
K. Raza
Cisco Systems
October 15, 2012
Operational management of Loop Free Alternates
draft-litkowski-rtgwg-lfa-manageability-00
Abstract
Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
ReRoute (IP FRR) mechanism enabling traffic protection for IP
traffic. Following first deployment experience, this document
provides operational feedback on LFA, highlights some limitations and
proposes a set of refinements to address those limitations.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Litkowski, et al. Expires April 18, 2013 [Page 1]
Internet-Draft LFA manageability October 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Operational issues with default LFA tie breakers . . . . . . . 3
2.1. Case 1: Edge router protecting core failures . . . . . . . 3
2.2. Case 2: Edge router choosen to protect core failures
while core LFA exists . . . . . . . . . . . . . . . . . . 5
2.3. Case 3: suboptimal core alternate choice . . . . . . . . . 6
3. Configuration aspects . . . . . . . . . . . . . . . . . . . . 6
3.1. LFA activation . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Policy based LFA selection . . . . . . . . . . . . . . . . 7
3.2.1. Mandatory criteria . . . . . . . . . . . . . . . . . . 8
3.2.2. Enhanced criteria . . . . . . . . . . . . . . . . . . 8
4. Operational aspects . . . . . . . . . . . . . . . . . . . . . 12
4.1. Controlling LFA computation . . . . . . . . . . . . . . . 12
4.2. Manual triggering of FRR . . . . . . . . . . . . . . . . . 13
4.3. Required local information . . . . . . . . . . . . . . . . 13
4.4. Coverage followup . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Litkowski, et al. Expires April 18, 2013 [Page 2]
Internet-Draft LFA manageability October 2012
1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document is being discussed on the rtgwg@ietf.org mailing list.
2. Operational issues with default LFA tie breakers
[RFC5286] introduces the notion of tie breakers when selecting the
LFA among multiple candidate alternate next-hops. Most
implementations are using the following algorithm :
o Prefer node protection alternate over link protection alternate.
o If protection type is equal, choose alternate providing shortest
path.
First deployments have revealed that the above algorithm may be
insufficent to reflect Service Provider preferences and could lead to
negative side effects.
The following sections details use cases highlighting the
limitations. Per-prefix LFA is assumed.
2.1. Case 1: Edge router protecting core failures
R1 --------- R2 ---------- R3 --------- R4
| 1 100 1 |
| |
| 100 | 100
| |
| 1 100 1 |
R5 --------- R6 ---------- R7 --------- R8 -- R9 - PE1
| | | |
| 5k | 5k | 5k | 5k
| | | |
+--- n*PEx ---+ +---- PE2 ----+
|
|
PEy
Figure 1
Rx routers are core routers using n*10G links. PEs are connected
using links with lower bandwidth.
Litkowski, et al. Expires April 18, 2013 [Page 3]
Internet-Draft LFA manageability October 2012
In figure 1, let's consider the traffic from PE1 to PEx. Nominal
path is R9-R8-R7-R6-PEx. Let's consider the failure of link R7-R8.
For R8, R4 is not an LFA and the only available LFA is PE2.
When the core link R8-R7 fails, R8 switches all traffic destined to
all the PEx towards the edge node PE2. Hence a edge node and edge
links are used to protect the failure of a core link. Typically,
edge links have less capacity than core links hence congestion will
occur on PE2 links. Note that altough PE2 was not directly affected
by the failure, its links become congested and its traffic will
suffer from the congestion.
In summary, in case of failure, the impact on customer traffic is:
o From PE2 point of view :
* without LFA: no impact
* with LFA: traffic is partially dropped (but possibly
prioritized by QoS mechanism).
o From R8 point of view:
* without LFA: traffic is totally dropped until convergence
* with LFA: traffic is partially dropped (but possibly
prioritized by QoS mechanism).
Litkowski, et al. Expires April 18, 2013 [Page 4]
Internet-Draft LFA manageability October 2012
2.2. Case 2: Edge router choosen to protect core failures while core
LFA exists
R1 --------- R2 ------------ R3 --------- R4
| 1 100 | 1 |
| | |
| 100 | 30 | 30
| | |
| 1 50 50 | 10 |
R5 -------- R6 ---- R10 ---- R7 -------- R8 --- R9 - PE1
| | \ |
| 5000 | 5000 \ 5000 | 5000
| | \ |
+--- n*PEx --+ +----- PE2 ----+
|
|
PEy
Figure 2
Rx routers are core routers meshed with n*10G links. PEs are meshed
using links with lower bandwidth.
In figure 2, let's consider the traffic coming from PE1 to PEx.
Nominal path is R9-R8-R7-R6-PEx. Let's consider the failure of the
link R7-R8. For R8, R4 is a link-protecting LFA and PE2 is a node-
protecting LFA. PE2 is chosen as best LFA due to its better
protection type. Just like in case 1, this will probably lead to
congestion on PE2 links.
Litkowski, et al. Expires April 18, 2013 [Page 5]
Internet-Draft LFA manageability October 2012
2.3. Case 3: suboptimal core alternate choice
+--- PE3 --+
/ \
1000 / \ 1000
/ \
+----- R1 ---------------- R2 ----+
| | 500 | |
| 10 | | | 10
| | | |
R5 | 10 | 10 R7
| | | |
| 10 | | | 10
| | 500 | |
+---- R3 ---------------- R4 -----+
| |
| 1000 | 1000
| |
PE1 -------------- PE2
10k
Figure 3
Rx routers are core routers. R1-R2 and R3-R4 links are 1G links.
All others inter Rx links are 10G links.
In the figure above, let's consider the failure of link R1-R3. For
destination PE3, R3 has two possible alternates:
o R4 is node-protecting
o R5 is link-protecting
R4 is chosen as best LFA due to better protection type. However, it
may not be desirable to use R4 as prefered alternate due to bandwidth
capacity reason. Service provider may prefer to use high bandwidth
link as prefered LFA. In this example, prefering shortest path over
protection type may achieve the expected behavior but in cases where
metric are not reflecting bandwidth, it would not work and some other
criteria would need to be involved when selecting the best LFA.
3. Configuration aspects
Controlling best alternate and LFA activation granularity is a
requirement for Service Providers. This section defines
configuration requirements for LFA.
Litkowski, et al. Expires April 18, 2013 [Page 6]
Internet-Draft LFA manageability October 2012
3.1. LFA activation
Granularity of LFA activation is important to control scaling of
boxes (programmed alternate nexthop consuming memory in forwarding
plane) and to control what is protected and not protected.
An implementation of LFA SHOULD allow activation:
o Per address-family : ipv4 unicast, ipv6 unicast, LDP IPv4 unicast,
LDP IPv6 unicast ...
o Per routing context : VRF, virtual/logical router, global routing
table, ...
o Per interface to control protected interfaces
o Per protocol instance, topology, area
o Per prefixes: prefix protection SHOULD have a better priority
compared to interface protection. This means that if a specific
prefix must be protected due to configuration request, LFA must be
computed and installed for this prefix even if the primary
outgoing interface is not configured for protection.
3.2. Policy based LFA selection
When multiple alternates exists, LFA selection algorithm is based on
tie breakers . Current tie breakers do not provide sufficient
control on how best alternate is chosen. This document proposes an
enhanced tie breaker allowing service providers to manage all
specific cases:
1. An implementation of LFA SHOULD support policy based decision for
determining best LFA.
2. Policy based decision SHOULD be based on multiple criterions,
where each criteria having a level of preference.
3. If defined policy does not permit to determine a unique best LFA,
the implementation MUST pick only one based on its own decision.
4. Policy SHOULD be applied to a protected interface or to a
specific set of destinations. In case of application on the
protected interface, all destinations primarily routed on this
interface SHOULD use the interface policy.
5. An implementation MAY support a behavior providing a non
disruptive change compared to behavior described in [RFC5286].
Litkowski, et al. Expires April 18, 2013 [Page 7]
Internet-Draft LFA manageability October 2012
3.2.1. Mandatory criteria
An implementation of LFA MUST support following mandatory criteria:
o Non candidate link. A link marked as "non candidate" it will
never be used as LFA.
o A primary nexthop being protected by another primary nexthop of
the same prefix (ECMP case).
o Type of protection provided by the alternate: link protection,
node protection, downstream.
o Shortest path: lowest IGP metric used to reach the destination.
o Local SRLG.
3.2.2. Enhanced criteria
An implementation of LFA SHOULD support following enhanced criteria:
o Linecard disjointness for protected and protecting nexthop: this
means that primary and alternate cannot be connected on the same
linecard.
o Link coloring.
o Existing TE based informations:
* Link affinity
* Link speed
* Link bandwidth (available/residual)
* Link loss
* Link delay
o Router type: core, edge, core/edge...
o Alternate type: link or tunnel alternate. This means that user
may change preference between link alternate or tunnel alternate
(tunnel prefered over link, link prefered over tunnel, or
considered as equal).
Litkowski, et al. Expires April 18, 2013 [Page 8]
Internet-Draft LFA manageability October 2012
3.2.2.1. Linecard disjointness
Linecard disjointness criteria provides another level of SRLG on the
node (automatic SRLG). The SRLG beeing the node Line Card.
Notion of linecard may be different depending on the hardware design.
If applicable, multiple level of linecard disjointness may be
proposed.
3.2.2.2. Link coloring
Link coloring is a powerful system to control alternates. The idea
is very similar to TE Link affinity but with a local significance
only. Protecting interfaces are tagged with colors. Protected
interface are configured to include some colors with a preference
level and exclude others
Example : P1 router is connected to three P routers and two PEs.
PE2
| +---- P4
| /
PE1 ---- P1 --------- P2
| 10Gb
1Gb |
|
P3
P1 is configured to protect the P1-P4 link. We assume that given the
topology, all neighbors are LFA. We would like to enforce a policy
in the network where only a core router may protect against the
failure of a core link, and where high bandwidth link are prefered.
In this example, we can use our link coloring system by:
o Marking PEs links with color RED
o Marking 10Gb CORE link with color BLUE
o Marking 1Gb CORE link with color YELLOW
o Configured the protected interface P1->P4 with :
* Include BLUE, preference 200
* Include YELLOW, preference 100
Litkowski, et al. Expires April 18, 2013 [Page 9]
Internet-Draft LFA manageability October 2012
* Exclude RED
Using this, PE links will never be used to protect against P1-P4 link
failure and 10Gb link will be be prefered.
The main advantage of this solution is that it could be reproduced
easily on other interface and other nodes without specifities. A
Service provider has only to define color system (associate color
with a significance) as it is done for TE affinity or BGP
communities.
Implementation of link coloring:
o SHOULD support multiple include and exclude colors an a single
protected interface.
o SHOULD provide a level of preference between included colors.
o SHOULD support multiple colors configuration on a single
protecting interface.
3.2.2.3. TE based information
It would be useful to be able to reuse already existing information
provided by traffic engineering extensions ([RFC3630]/[RFC5305] and
[I-D.previdi-isis-te-metric-extensions]) as tie-breakers for LFA.
This would allow automatic and optimized decision when choosing best
LFA while limiting the configuration overhead. Existing IGP TE-
extensions are "dedicated" to Traffic Engineering database and any
change for LFA choice introduced in TE-LSDB may impact already
existing tunnels. It would be interesting to make traffic-
engineering extensions available to other components than MPLS-TE.
The mechanisms to achieve this is beyond the scope of this document.
But basically, LFA as a purely local mechanim, only the local
information is directly interesting for the alternate choice and
there is no need to propagate it.
3.2.2.4. Router type
Rather than tagging interface on each node (using link color) to
identify neighbor node type, it would be helpful if routers were
announcing their role/function in the IGP. Currently no IGP
extension provides this information. The mechanics for flooding this
information is beyond the scope of this document.
Consider following network:
Litkowski, et al. Expires April 18, 2013 [Page 10]
Internet-Draft LFA manageability October 2012
PE3
|
|
PE2
| +---- P4
| /
PE1 ---- P1 -------- P2
| 10Gb
1Gb |
|
P3
In the example above, each node is configured with its role, and the
role is flooded through the IGP.
o PE1,PE3: edge.
o PE2: aggregation (edge/core).
o P1,P2,P3: core.
A simple policy could be configured on P1 to choose best alternate
for P1->P4 based on router function/role as follows :
o criteria 1 -> router type: exclude aggregation and edge.
o criteria 2 -> bandwidth.
3.2.2.5. Link vs tunnel alternate
In addition to LFA, tunnels (IP, LDP or RSVP-TE) to distant routers
may be used to complement LFA coverage (tunnel tail used as virtual
neighbor). When a router has multiple alternate candidates for a
specific destination, it may have direct alternates as well as tunnel
alternates. Direct alternates may not always provide an optimal
routing path and it may be preferable to select a tunnel alternate
over a direct alternate.
In figure 1, there is no core alternate for R8 to reach PEs located
behind R6, so R8 is using PE2 as alternate, which may generate
congestion when FRR is activated. Instead, we could have a tunnel
core alternate for R8 to protect PEs destinations. For example, a
tunnel from R8 to R3 may enable to prefer R3 over PE2 as best
alternate if policy permits. For example :
o tunnel alternates must be prefered over link alternate.
Litkowski, et al. Expires April 18, 2013 [Page 11]
Internet-Draft LFA manageability October 2012
o Consider tunnel and link alternate as same level and use another
criteria to prefer R3 over PE2.
4. Operational aspects
4.1. Controlling LFA computation
LFA computation may be CPU intensive depending on the scope of
application. On a network suffer from instability, it may be useful
to control LFA SPF computation as it is done in most implementations
for main SPF.
An implementation MAY allow throttling of LFA computation and LFA
computation SHOULD have his own throttling values. The procedures
for throttling is beyond the scope of this document:
Consider a stable converged network and main SPF and LFA SPF
configured with throttling.
o T0 : LSP is received advertising a topology change.
o T0 : Main SPF is scheduled at t0+x (x depending on throttling
value of main SPF).
o T0+x : main SPF is computed.
o T1 : main SPF finishes and LFA computation is scheduled at T1+y (y
depending on throttling value of LFA computation).
o T1+y : LFA SPF computation starts.
o T2 : LFA SPF finishes and alternates are computed and installed.
If a new LSP is received in a short period of time after T2, values
of x and y may increase based on implementation algorithm of
throttling.
It may happen that a network topology change is received while LFA
SPF is computing or during LFA SPF throttling time. Priority SHOULD
be given to main SPF computation compared to LFA computation. An
implementation SHOULD abort any running or scheduled LFA computation
if a topology change is received.
Moreover when a topology change is received, current programmed
alternates may not be loopfree anymore, so an implementation MAY drop
programmed alternates when a topology change is received, and
recompute and reinstall the alternates again later after completion
Litkowski, et al. Expires April 18, 2013 [Page 12]
Internet-Draft LFA manageability October 2012
of LFA SPF.
4.2. Manual triggering of FRR
Service providers often use using manual link shutdown (using router
CLI) to perform some network changes. An implementation MUST support
triggering/activating LFA Fast Reroute for a given link when a manual
shutdown is done.
4.3. Required local information
LFA introduction requires some enhancement in standard routing
information provided by implementations. Moreover, due to the non
100% coverage, coverage informations also is required.
Hence an implementation :
o MUST be able to display for every destination, the primary nexthop
as well as the alternate nexthop information
o MUST provide coverage information per activation domain of LFA
(area, level, topology, instance, virtual router ...)
o MUST provide total percentage of coverage
o SHOULD provide percentage of coverage per link
o MAY provide percentage of coverage per priority if implementation
supports prefix-priority insertion in RIB/FIB
o SHOULD provide a reason for chosing an alternate (policy and
criteria)
o MAY provide a mean to clear programmed backup and trigger backup
recomputation
o MAY provide the list of non protected destinations and the reason
why they are not protected (no protection required or no alternate
available)
4.4. Coverage followup
It is pretty easy to evaluate coverage of a network in a nominal
situation, but topology changes may change the coverage. In some
situations, network may not be able to provide the required level of
protection. Hence, it becomes very important for service providers
to get alerted about changes of coverage.
Litkowski, et al. Expires April 18, 2013 [Page 13]
Internet-Draft LFA manageability October 2012
An implementation SHOULD :
o provide an alert system if total coverage is below a defined
threshold or comes back to a normal situation.
o provide an alert system if coverage of a specific link is below a
defined threshold or comes back to a normal situation
An implementation MAY :
o provide an alert system if a specific destination is not protected
anymore or when protection comes back up for this destination
Although the procedures for providing alerts are beyond the scope of
this document, we recommend that implementations should consider
standard and well used mechanisms like syslog or SNMP traps.
5. Security Considerations
This document does not introduce any change in security consideration
compared to [RFC5286].
6. Acknowledgements
7. IANA Considerations
This document has no action for IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
8.2. Informative References
[I-D.previdi-isis-te-metric-extensions]
Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas,
A., and C. Filsfils, "IS-IS Traffic Engineering (TE)
Metric Extensions",
Litkowski, et al. Expires April 18, 2013 [Page 14]
Internet-Draft LFA manageability October 2012
draft-previdi-isis-te-metric-extensions-02 (work in
progress), October 2012.
[I-D.shand-remote-lfa]
Bryant, S., Filsfils, C., Shand, M., and N. So, "Remote
LFA FRR", draft-shand-remote-lfa-01 (work in progress),
June 2012.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway
Protocol (IGP) Routes Over Traffic Engineering Tunnels",
RFC 3906, October 2004.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, January 2010.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010.
[RFC6571] Filsfils, C., Francois, P., Shand, M., Decraene, B.,
Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
Alternate (LFA) Applicability in Service Provider (SP)
Networks", RFC 6571, June 2012.
Authors' Addresses
Stephane Litkowski
Orange
Email: stephane.litkowski@orange.com
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
Litkowski, et al. Expires April 18, 2013 [Page 15]
Internet-Draft LFA manageability October 2012
Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com
Kamran Raza
Cisco Systems
Email: skraza@cisco.com
Litkowski, et al. Expires April 18, 2013 [Page 16]