wdiff draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00.txt draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01.txt

Routing Area Working Group S. Litkowski
Internet-Draft B. Decraene
Intended status: Standards Track Orange
Expires: May 17, August 22, 2013 C. Fils Fils FilsFils
K. Raza
Cisco Systems
November 13, 2012
February 18, 2013

Interactions between LFA and RSVP-TE
draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00
draft-litkowski-rtgwg-lfa-rsvpte-cooperation-01

Abstract

RSVP-TE FRR is a well known and deployed technology for fast reroute,
and there are some use cases where LFA and RSVP-TE may interact.

This document clarifies defines the behavior of LFA a node supporting Loopfree
Alternates (LFA) when RSVP-TE the node has established RSVP TE tunnels. It
first describes the decisions to be made by the LFA mechanism with
respect to the use of TE tunnels as LFA candidates. Second, it
discusses the use of RSVP TE tunnels as a way to complement the LFA
coverage, illustrating how these technologies can benefit from each
other.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are
used simultaneously. to be interpreted as described in [RFC2119].

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 May 17, August 22, 2013.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LFA FRR and MPLS TE FRR interaction . . . . . . . . . . . . . 3
2.1. LFA on TE head end router . . . . . . . . . . . . . . . . 3
2.1.1. LFA and TE IGP shortcut MPLS-TE interactions . . . . . . . . . . . . . . . 3
2.1.2. TE tunnel
2.1. Use case : using MPLS LSP as an LFA candidate . . . . . candidates . . . . . . . 4
2.1.3. 3
2.2. Specifications of interactions between LFA candidate TE tunnel and TE IGP shortcut . . . LSP . . 4
2.1.4. LFA
2.2.1. Having both a physical interface and a TE tunnel to
toward a directly connected neighbor . . 4
2.2. LFA on TE midpoint router . . . . . . . . . . . . . . . . 4
3. Need for LFA and RSVP-TE interactions . . . . . . . . . . . . 4
3.1. Network with some already deployed RSVP-TE tunnels . . . . 5
3.2. Network with no protection at all .
2.2.2. TE ingress LSP as LFA candidate . . . . . . . . . . . 5
4.
2.2.3. Independence between LFA FRR and MPLS TE FRR interaction scenarios . . . . . . . . . 5
4.1. LFA activated on RSVP-TE tunnel headend
3. Operational considerations . . . . . . . . . 5
4.2. LFA activated on RSVP-TE tunnel midpoint . . . . . . . . . 6
5. 7
3.1. Relevance of joint LFA FRR and RSVP-TE FRR deployments . . 7
3.2. Extending LFA coverage using RSVP-TE tunnels . . . . . . . . . 7
5.1. Reference 8
3.2.1. Creating multihop tunnel to extend topology . . . . . . . . . . . . . . . . . . . . 7
5.2. Creating 8
3.2.2. Selecting multihop tunnel tunnels to extend topology . . . . . . . 8
6. 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1.
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2.
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

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.

When a failure occurs inside in an IP network, network has to converge.
This convergence the subsequent converge
process often leads to traffic disruption. Some mechanisms are
already
available to limit traffic disruption disruptions by computing pre-computing alternate
path
paths and switching locally to alternate path reroute over these as soon as the failure is
detected. All this can be termed Such techniques are commonly known as a protection mechanism. "protection
mechanisms". Currently, the widely used protection mechanisms for traffic widely used in
Service Provider networks are (i) RSVP-TE Fast Reroute [RFC4090] and Loop
Free Alternates [RFC5286].
Both have pros and cons. For example, RSVP-TE FRR permits full network coverage
but with a quite high complexity in terms of
operation operation, as well as
potential scaling issues. Whereas, On the other hand, LFA is offer a very easy, manageable
manageable, and quite scalable mechanism mechanism, but it does not
provides provide full
coverage.

This document presents some scenarios where discusses how LFA and RSVP-TE may should interact. The It
first describes how an LFA implementation should deal with existing
RSVP TE tunnels established by the LFA node, as well as its behavior
with respect to established IGP Shortcut tunnels [RFC3906]. Second,
the document also proposes suggets the usage use of RSVP-TE tunnels to extend LFA coverage
coverage, and clarifies interactions between discusses the two
protection mechanisms. management and operational aspects of
such a practice.

2. LFA FRR and MPLS TE FRR interaction MPLS-TE interactions

This section provides discusses the various interactions among LFA FRR and
MPLS-TE FRR. It starts with a simple example emphasizing the
benefits of jointly using of LFA-FRR and MPLS-TE FRR, and then
summarizes the summarized normative requirements for the
interaction interactions between LFAs and
MPLS-FRR.

2.1. Use case : using MPLS LSP as LFA FRR candidates

In some cases, typically in ring shapped parts of network topologies,
links cannot be protected by LFAs. In the following topology, from
the point of view of R5, LFAs are able to partiatlly protect (49% of
the destination routers) from the failure of R3, while the failure of
R4 is not covered at all.

(30 routers) --- R1 ----(30)---- R2 --- (50 routers)
| |
(5) (30)
| |
R3 R4 --- (20 routers)
| |
(10) (30)
| |
------- R5 ------

Figure 1

Many networks deploy MPLS tunnels for traffic engineering and
resiliency reasons. To extend its benefit, an LFA implementation
could take advantage of such existing MPLS tunnels. In the exemple
above, if R5 has established TE FRR. Following sections provide
illustration tunnels bypassing R4 and reasoning why an operator may care for R3, these
behavior.

2.1.
could be considerd as LFA on candidates respectively protecting links
from R5 to R4 and R3.

In the following section, we provide a detailed summary of the
behavior to be applied by an LFA implementation which would consider
the existence of MPLS TE head end router

2.1.1. tunnels to improve its applicability. The
explicit configuration of such tunnels with the intent of improving
LFA applicability is discussed in later sections.

2.2. Specifications of interactions between LFA and TE IGP shortcut LSP

Here we summarize the normative requirements for the interaction
between LFA FRR and MPLS TE tunnels.

2.2.1. Having both a physical interface and a TE tunnel toward a LFA

If a node N S has an IGP/LDP forwarding entry F1 with outgoing both a physical interface i1 and a TE tunnel to reach a
LFA, it SHOULD use the physical interface unless :

1. The tunnel has been explicitly configured as an LFA candidate.

2. The tunnel does not pass through the link subject to LFA
protection.

In other words, if a node S has an IGP/LDP forwarding entry F2 F1 with
outgoing interface onto i1, and S originates a TE tunnel T2 (due to IGP shortcut [RFC3906]) and terminating on
direct neighbor N2 (for example : if a TE tunnel is provisionned for
link protection), T2 has an outgoing interface i2, i2 and N2 is best LFA
for F1, then an implementation MUST
support enabling NOT use T2 when programming LFA FRR
repair for F1 and using TE FRR for F2 as long unless T2 is configured as i1
!= i2.

If i1 == i2, an implementation SHOULD allow for using LFA FRR backup
for F1 and TE FRR backup for F2.

2.1.2. candidate.

2.2.2. TE tunnel ingress LSP as an LFA candidate

A TE tunnel LSP can be used as a virtual interface to reach a LFA candidate mechanism is the ability if

1. The TE tunnel has been configured to allow its use a as an LFA
candidate.

2. The TE tunnel does not pass through the primary outgoing
interface of D.

This would permit to extend LFA coverage as a virtual neighbor described in LFA computation.

If
[I-D.ietf-rtgwg-remote-lfa], in a controlled fashioned, as the
tunnels used by the fast reroute mechanism are defined by
configuration.

In other words, if a node N S has an IGP/LDP forwarding entry F1 with
outgoing interface i1 and N S originates a TE tunnel T1 terminating at
node Y, then an implementation SHOULD support a local policy which
instructs node N S to consider Y as a virtual neighbor and hence
include Y as part of the LFA FRR alternate computation. In such
case, an implementation MUST not use Y as an LFA for F1 if T1's
outgoing interface is i1.

This would permit

2.2.3. Independence between LFA and TE FRR

2.2.3.1. Tunnel head-end case

Similar requirements can be expressed for TE IGP shortcut tunnels.

-----C1 ---------
/ | \
/ | \
PE1 ---- C2 --- C3 ---- PE2
| /
PE3

Figure 2

PE to extend Cx metrics are 50, Cx to Cx are 1

A service provider is often providing traffic-engineered path for
specific customer traffic (L3VPN, PW ...) to ensure path diversity or
traffic constraints. In the diagram above, we consider a TE tunnel
T2 built on a non shortest path as follows : PE1->C2->C3->PE2 and IGP
shortcut is activated on PE1 to make traffic to PE2 using T2. Based
on operational feedback, some implementations prevent LFA computation
to run for an interface where a TE tunnel exists. In our example, if
LFA is activated on N, we would not be able to have a protection for
PE3 destination as a tunnel exists on the interface. This current
observed behavior leads to a very limited coverage for LFA. In the
other hand, it is important to keep protection mechanisms independant
as described in
[I-D.ietf-rtgwg-remote-lfa]

2.1.3. LFA candidate much as possible to keep implementation simple. We propose the
following approach :

o If an IP prefix is reachable through a TE tunnel, LFA must not
compute a protection for it.

o If an IP prefix is reachable through a native IP path, LFA MUST
compute a protection for it disregarding the presence of a tunnel
or not on the primary interface.

In other words, if a node S has an IGP/LDP forwarding entry F1 with
outgoing interface i1 and an IGP/LDP forwarding entry F2 with
outgoing interface onto a TE tunnel T2 (due to IGP shortcut
[RFC3906]) and tunnel T2 has outgoing interface i2, then an
implementation MUST support enabling LFA FRR for F1 and using TE FRR
for F2 as long as i1 != i2.

If i1 == i2, an implementation SHOULD allow for using LFA FRR backup
for F1 and TE FRR backup for F2.

The mechanisms for using TE tunnel as an LFA candidate, and RFC3906
mechanisms MUST be de-correlated -- i.e an implementation MUST
support TE tunnel configuration with RFC3906 only, as LFA candidate
only, or both at the same time.

2.1.4. LFA and TE tunnel

2.2.3.2. Tunnel midpoint case

-----C1 ---------
/ | \
/ | \
PE1 ---- C2 --- C3 ---- PE2
| /
PE3

Figure 3

PE to a directly connected neighbor

If a node N has an IGP/LDP forwarding entry F1 with outgoing
interface i1, and N originates Cx metrics are 50, except PE3-C3 (60), Cx to Cx are 1In the
diagram above, we consider a TE tunnel T2 terminating built on direct
neighbor N2 (for example a non shortest
path as follows : if PE1->C2->C3->PE2 and IGP shortcut is activated on
PE1 to make traffic to PE2 using T2. C2 is a TE tunnel is provisionned for link
protection), T2 midpoint
router. In terms of forwarding, C2 has a MPLS TE forwarding entry
for T2, as well as an outgoing interface i2 IP forwarding entry to PE2. As explained in
previous sections, it would be too restrictive and N2 is best would limit LFA
benefit on C2 if C2 would not be able to compute an LFA for
F1, then the IP
forwarding entry to PE2 due to the presence of a transit tunnel.

We propose the following approach for a midpoint router of a TE
tunnel :

o MPLS TE forwarding entries MUST not be protected by LFA (if an implementation
operator wants protection, TE FRR could be enabled).

o IP forwarding entries MUST NOT use T2 when programming be protected by LFA
repair disregarding the
presence of a TE tunnel transiting through the primary interface
of the destination.

In our example :

o MPLS TE forwarding entry for F1 unless T2 is configured as an LFA candidate.

2.2. LFA (ending on PE2) would be protected
by TE-FRR (if enabled).

o IP forwarding entry for PE2 would be protected by LFA.

In case of failure of C2-C3 :

o traffic from PE1 to PE2 (encapsulated in T2), would be protected
by TE midpoint router

If FRR.

o traffic from PE3 to PE2 (native IP), would be protected by LFA.

In other words, if a node N S has an IGP/LDP forwarding entry F1 with
outgoing interface i1 and a MPLS TE midpoint forwarding entry F2 with
outgoing interface i2, then an implementation MUST support using LFA
FRR for F1 and TE FRR for F2 as long as i1 != i2.

If i1 == i2, an implementation SHOULD allow for using LFA FRR backup
for F1 and TE FRR backup for F2.

3. Need Operational considerations

In this section, we first discuss the benefit of considering a joint
deployment of LFA and MPLS tunnels to achieve resiliency. We then
discuss one approach aiming at defining MPLS tunnels for the purpose
of complementing LFA coverage.

3.1. Relevance of joint LFA FRR and RSVP-TE interactions FRR deployments

This section describes some of the deployment scenarios where LFA it can be
beneficial to jointly use LFAs and RSVP-TE may interact.

3.1. Network with some already deployed RSVP-TE tunnels FRR.

There are many networks where RSVP-TE is already deployed. The
deployment of RSVP-TE is typically for two main reasons :

o Traffic engineering : a provider wants to route some flows on some
specific paths using constraints;

o Traffic protection using Fast-reroute ability

LFA is a feature that may bring benefits on RSVP-TE enabled networks,
with no/minimal operational cost (compared to RSVP-TE FRR global roll
out). These benefits include:

o Should increase protection on network where FRR is not available
everywhere. Although it may not provide full coverage, it will
increase the protection significantly.

o May provide better protection in specific cases than RSVP-TE FRR

3.2. Network with no protection at all

For IP networks that do not have any traffic protection mechanism,
LFA is a very good first step to provide traffic protection even if
its coverage is not 100%. Providers may want to increase protection
coverage if LFA benefit is not sufficient for some destinations. destinations, in
some parts of the network. The following sections
describe usage discusses the use
of basic RSVP-TE tunnels to extend protection coverage.

4. LFA FRR and MPLS TE FRR interaction scenarios

4.1. LFA activated on RSVP-TE tunnel headend

R4 --(10)- R5 -(1)- R6 -(10)- R7
| |
(10) ---(30)----R14--(10)----- (10)
| / \ |
R1 -R2 -(100)-- R3 --(22)--- R8 ---(10)------- R9 --(100)-- R10 ---- R11
/ / | |
(10) (10) (40) |
| / | |
R16-(200)-R15 R12 --(1)-- R13--------(5)------

Figure 1

In figure 1, shortest path from R1 to R11 is : R1-R2-R3-R8-R9-R10-
R11.

An RSVP-TE tunnel (tunnel1) is configured on R3 towards R10 using
constrained path R4-R5-R6-R7-R9-R10, and another tunnel (tunnel2) is
configured towards R8 using IGP path (with no constraints). IGP
shortcut ([RFC3906]) is activated on R3, leading to the following
forwarding informations (not exhaustive) on R3 :

o R8 and R9 via tunnel2

o R10 and R11 via tunnel1

o R4 and R5 via R4

o R14 via R14

Per destination LFA is also activated on R3

Based on the normative principles already described, here are the FRR
backup paths :

o R8, R9, R10 and R11 are forwarded via an RSVP-TE tunnel, so there
will be no LFA programmed, TE FRR may be used for protection, if
available.

o R14 has primary nexthop R14, LFA computed to protect R14 is R8,
but R8 is primarily reachable through tunnel2. As defined in
normative principles, backup forwarding entry for R14 will be
programmed to direct neighbor (R8) rather than using tunnel2.

o R4 has primary nexthop R4, alternate is R12. (no ambiguity in this
case as no tunnel is involved)

o R16,R15,R2,R1 are not covered because though alternate paths exist
but they are not loop free. We could envisage to create a new TE
tunnel to provide more path diversity using loop free tunnel
endpoints. For example, we could create a tunnel from R3 to R16
(explicity routed through R15), that is configured only as an LFA
candidate, to provide loop free alternate to R1 and R2.

4.2. LFA activated on RSVP-TE tunnel midpoint
R4 --(10)-- R5 -(1)- R6 -(10)- R7
| | |
(10) (60) (10)
| | |
R1 -R2 -(100)-- R3 --(22)--- R8 ---(10)------- R9 --(100)-- R10 ---- R11
| |
(40) |
| |
R12 --(1)-- R13--------(5)------

Figure 3

In figure 3, RSVP-TE tunnel is configured from R3 to R9 using
constrained path R4-R5-R6-R7. R4 to R7 routers are midpoints of
tunnels, and they are receiving tunneled packets as well as native IP
packets on their interface. We consider LFA implemented on R5.

As explained in normative principles, IP prefixes will be programmed
with LFA alternate as backup entry (if available) and MPLS ILM
(Incoming label map) of transit TE tunnel will not use LFA alternate
as backup NHLFE even if there is a LFA to reach tunnel tail-end (TE
use his own protection).

In our figure 3, R5 receives native IP traffic from R4 to R10 and
tunneled traffic from R1 to R11 (tunneling done by R3). R5 computes
LFAs for all destinations. R8 is an alternate to reach R10, as well
as to reach R11 and R9. When link R5->R6 fails, traffic from R4 is
switched to alternate R8 (protection by LFA), but traffic from R1 to
R11 may be dropped (in case of tunnel without protection) or switched
to RSVP-TE protection path (in case tunnel has protection).

3.2. Extending LFA coverage using RSVP-TE tunnels

We already have seen in previous section sections that creating RSVP-TE tunnels would increase could
be established by an operator to complement LFA coverage. The choice method
of tunnel placement
should depend depends on what type of protection (link or node) we want to
achieve,
is required, as well as on the set of destinations we want to protect.

5.1. Reference topology

Some topologies like rings do not work well with LFA. We consider
the following topology in our document for further illustration.

(30 routers) --- R1 ----(30)---- R2 --- (50 routers)
| |
(5) (30)
| |
R3 R4 --- (20 routers)
| |
(10) (30)
| |
------- R5 ------

Figure 5

In this topology, we consider LFA enabled on all routers and links.
We will focus on R5 view of the network.

R5 is routing all traffic towards R3 as nominal nexthop, except
traffic towards R4 which is routed using R4 (direct link) as nexthop.
R5 has LFAs only for R2 and destinations behind R2 (primary nexthop
R3, alternate R4). There are 104 destinations (routers) in the or network in figure 5. R5-R3 link has 49% LFA coverage with 83
destinations primarily routed on it. R3 node (from R5 point of view)
has 49% LFA coverage with 83 destinations primarily routed through it
from R5. R5-R4 link has 0% coverage with 21 destinations primarily
routed on it. R4 node (from R5 point of view) has 0% coverage with
21 destinations primarily routed on it through it from R5.

Globally from R5 point of view, parts
which requires better protection than what LFA is able to protect to partially
(49%) protect from failure of R3, while failure of R4 is not
protected at all.

5.2. can provide.

3.2.1. Creating multihop tunnel to extend topology

From R5 point of view, traffic routed through R3 is protected (node
protected) at about 49% with 83 destinations routed on it.
Destinations R1,R3 and routers behind R1 are not protected, while R2
and destinations behind it are protected.

To extend the coverage, the idea is to extend the topology using use a mechanism extending LFA
tunnel candidate mechanism.
by turning TE tunnels into LFA candidates. This mechanism is of a
local significance only.

The hardest task is then

When explicitly establishing tunnels for that purpose, choices have
to choose be made for the tunnel(s) endpoint endpoints of such as tunnels, in order to
achieve the maximum coverage. Tunnel definition must satisfy : maximize
coverage while preserving management simplicity. Requirements are
that:

o Endpoint Endpoints must satisfy equations from [RFC5286], otherwise it will
not be a valide LFA : candidate: so when releasing traffic from
tunnel, the traffic will go to the destination without flowing
through the protected link or node. Depending on which equations
are satisfied, node or link protection will be provided by the
tunnel hop.

o Tunnel must not flow though the link or node to be protected,
explicit routing of tunnel is highly recommended to enforce this
condition.

The approach to choose tunnel endpoints might be different here when
compared to [I-D.ietf-rtgwg-remote-lfa] as endpoint choice is a
manual one. Automatic behavior and scaling of
[I-D.ietf-rtgwg-remote-lfa] requires : requires:

o Non null intersection of Extended P-Space and Q-Space

o Computation of PQ node only for the remote end of the link

Based on this, [I-D.ietf-rtgwg-remote-lfa] may : may:

o Not find a tunnel endpoint;

o Not provide the more efficient protection : -- i.e. provides only
link protection, while there is node protection possible for a
specific destination

The proposed solution of manual explicitly routed tunnels is a good
complement for [I-D.ietf-rtgwg-remote-lfa] and provides more
flexibility:

o Always a possibility to find a tunnel endpoint for a specific
destination
destination.

o Possibility to provide a better protection level type (link vs. node).

3.2.2. Selecting multihop tunnels to extend topology

From a manageability aspect point of our manual solution, view, computing a best Q node for each
destination could lead to have one different Q node for
different each
destination. This is not optimal in terms of number of tunnels,
given that possibly one Q node may be able to serve multiple non
covered destinations.

Rather than computing the best Q node per non covered destination, we
would prefer to find best compromise Q nodes (best for multiple
destinations). To find the best compromise between coverage increase
and number of tunnels, we recommend to use a simulator that do performing the
following computation computations per link : link:

Step 1 : Compute for each not covered destination (routed on the
link) the list of endpoints that are satisfying equations
from [RFC5286] (node or link protection equations depending
of required level of protection) : nodes in Q-Space

Step 2 : Remove endpoint endpoints that you want to avoid to use as are not eligible for repair (Edge
nodes, low bandwidth meshed nodes, number of hops ...) :
multiple attributes could be specified to exclude some
nodes from Q-Space : The example of attributes include
router type, metric to node, bandwidth, packet loss, RTD
...

Step 3 : Within all the list of endpoints (one list per destination),
order the endpoints by number of destination covered

Step 4 : Choose the endpoint that has the highest number of
destination covered : some other criteria could be used to
prefer an endpoint from another (same type of criteria that
excluded some nodes from Q-Space)

Step 5 : Remove destinations covered by this endpoint from non
covered list

Step 6 : If non covered list is not empty, restart from Step 1

Multiple endpoint (and so tunnels) could be necessary to have 100%
coverage. But the idea is to find a tradeoff between number of
tunnels configured (complexity) and number of destination covered,
combining with traffic information would also provide a better view.
Globally, configuring 2 tunnels providing 80% coverage would be
considered as (operationnally) better than configuring 15 tunnels to
obtain 100% coverage.

In our example, we can create a tunnel from R5 to R2. R2 satisfies
node protection equation for destination R1, routers behind R1 and
R3. To satisfy the second criteria, the tunnel must not use IGP path
but must be constrained through R4. With this, we achieve 100% of
LFA coverage for R3 router failure.

4. Security Considerations

TBD.

7. Acknowledgements

5. Contributors

Significant contribution was made by Pierre Francois which the
authors would like to acknowledge.

6. IANA Considerations

This document has no actions for IANA.

7. References

9.1.
7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[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.

[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008.

9.2.

7.2. Informative References

[I-D.bryant-ipfrr-tunnels]
Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03
(work in progress), November 2007.

[I-D.ietf-rtgwg-remote-lfa]
Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-00 draft-ietf-rtgwg-remote-lfa-01
(work in progress), June December 2012.

Authors' Addresses

Stephane Litkowski
Orange

Email: stephane.litkowski@orange.com

Bruno Decraene
Orange

Email: bruno.decraene@orange.com

Clarence Fils Fils FilsFils
Cisco Systems

Email: cfilsfil@cisco.com
Kamran Raza
Cisco Systems

Email: skraza@cisco.com