| Routing Area Working Group | S. Litkowski |
| Internet-Draft | B. Decraene |
| Intended status: Standards Track | Orange |
| Expires: April 02, 2013 | C. Filsfils |
| K. Raza | |
| Cisco Systems | |
| October 2012 |
Operational management of Loop Free Alternates
draft-litkowski-rtgwg-lfa-manageability-00
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.
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 02, 2013.
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 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.
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.
[RFC5286] introduces the notion of tie breakers when selecting the LFA among multiple candidate alternate next-hops. Most implementations are using the following algorithm :
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.
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.
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:
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.
+--- 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:
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.
Controlling best alternate and LFA activation granularity is a requirement for Service Providers. This section defines configuration requirements for LFA.
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:
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:
An implementation of LFA MUST support following mandatory criteria:
An implementation of LFA SHOULD support following enhanced criteria:
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.
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
PE2
| +---- P4
| /
PE1 ---- P1 --------- P2
| 10Gb
1Gb |
|
P3
Example : P1 router is connected to three P routers and two PEs.
In this example, we can use our link coloring system by:
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:
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.
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.
PE3
|
|
PE2
| +---- P4
| /
PE1 ---- P1 -------- P2
| 10Gb
1Gb |
|
P3
Consider following network:
A simple policy could be configured on P1 to choose best alternate for P1->P4 based on router function/role as follows :
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 :
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.
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 of LFA SPF.
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.
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 :
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.
An implementation SHOULD :
An implementation MAY :
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.
This document does not introduce any change in security consideration compared to [RFC5286].
This document has no action for IANA.
| [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. |