One document matched: draft-litkowski-rtgwg-lfa-rsvpte-cooperation-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5286 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml">
<!ENTITY RFC3906 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3906.xml">
<!ENTITY RFC4090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4090.xml">
<!ENTITY REMOTE-LFA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-remote-lfa.xml">
<!ENTITY IPFRR-TUN SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bryant-ipfrr-tunnels.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?> <!-- generate a ToC -->
<?rfc tocdepth="3"?> <!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?> <!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="std" docName="draft-litkowski-rtgwg-lfa-rsvpte-cooperation-02" ipr="trust200902">
<front>
<title abbrev="lfa-rsvpte-cooperation">Interactions between LFA and RSVP-TE</title>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>stephane.litkowski@orange.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Bruno Decraene" initials="B" surname="Decraene">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>bruno.decraene@orange.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Clarence FilsFils" initials="C" surname="FilsFils">
<organization>Cisco Systems</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>cfilsfil@cisco.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Kamran Raza" initials="K" surname="Raza">
<organization>Cisco Systems</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>skraza@cisco.com</email>
<!-- <uri/> -->
</address>
</author>
<date year="2013" />
<area></area>
<workgroup>Routing Area Working Group</workgroup>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t> This document defines the behavior of a node supporting Loopfree
Alternates (LFA) when 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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119"/>.</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
When a failure occurs in an IP network, the subsequent converge process
often leads to traffic disruption. Some mechanisms are available to
limit traffic disruptions by pre-computing alternate paths and locally
reroute over these as soon as the failure is detected. Such techniques
are commonly known as "protection mechanisms". Currently, the
protection mechanisms widely used in Service Provider networks are
RSVP-TE Fast Reroute [RFC4090] and Loop Free Alternates [RFC5286].
RSVP-TE FRR permits full network coverage but with a quite high
complexity in terms of operation, as well as potential scaling issues.
On the other hand, LFA offer a very easy, manageable, and scalable
mechanism, but does not provide full coverage. </t>
<t> This document discusses how LFA and RSVP-TE should interact. 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
suggets the use of RSVP-TE tunnels to extend LFA coverage, and discusses
the management and operational aspects of such a practice.</t>
</section>
<section anchor ="interactions" title = "LFA FRR and MPLS-TE interactions">
<t> This section 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
requirements for the interactions between LFAs and MPLS-FRR. </t>
<section anchor="exemple" title = "Use case : using MPLS LSP as LFA candidates">
<t> 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. </t>
<figure>
<artwork>
(30 routers) --- R1 ----(30)---- R2 --- (50 routers)
| |
(5) (30)
| |
R3 R4 --- (20 routers)
| |
(10) (30)
| |
------- R5 ------
Figure 1
</artwork>
</figure>
<t> 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 tunnels bypassing
R4 and R3, these could be considerd as LFA candidates respectively
protecting links from R5 to R4 and R3.</t>
<t> 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 tunnels to improve its applicability. The explicit configuration of
such tunnels with the intent of improving LFA applicability is discussed in
later sections.</t>
</section>
<section anchor="normative" title="Specifications of interactions between LFA and TE LSP">
<t>Here we summarize the normative requirements for the interaction between
LFA FRR and MPLS TE tunnels.</t>
<section anchor="normative-head-end-tunneltoneighbor" title="Having both a physical interface and a TE tunnel toward a LFA">
<t>If a node S has both a physical interface and a TE tunnel to reach a LFA, it SHOULD use the physical interface unless :
<list style="numbers">
<t> The tunnel has been explicitly configured as an LFA candidate.</t>
<t> The tunnel does not pass through the link subject to LFA protection.</t>
</list>
</t>
<t>In other words, if a node S has an IGP/LDP forwarding entry
F1 with outgoing interface i1, and S originates a TE tunnel T2
terminating on direct neighbor N2 (for example : if a TE tunnel
is provisionned for link protection), T2 has an outgoing
interface i2 and N2 is best LFA for F1, then an implementation
MUST NOT use T2 when programming LFA repair for F1 unless T2 is
configured as an LFA candidate.</t>
</section>
<section anchor="normative-head-end-remoteLFA" title="TE ingress LSP as LFA candidate">
<t>A TE LSP can be used as a virtual interface to reach a LFA if
<list style ="numbers">
<t>The TE tunnel has been configured to allow its use as an LFA candidate.</t>
<t>The TE tunnel does not pass through the primary outgoing interface of D.</t>
</list>
</t>
<t>This would permit to extend LFA coverage as described in
<xref target="I-D.ietf-rtgwg-remote-lfa"/>, in a controlled
fashioned, as the tunnels used by the fast reroute mechanism
are defined by configuration.</t>
<t>In other words, if a node S has an IGP/LDP forwarding entry
F1 with outgoing interface i1 and S originates a TE tunnel T1
terminating at node Y, then an implementation SHOULD support a
local policy which instructs node 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.</t>
</section>
<section title="Independence between LFA and TE FRR">
<section anchor="normative-head-end-igp-shortcut" title="Tunnel head-end case">
<t>Similar requirements can be expressed for TE IGP shortcut tunnels.</t>
<t>
<figure>
<artwork>
-----C1 ---------
/ | \
/ | \
PE1 ---- C2 --- C3 ---- PE2
| /
PE3
Figure 2
</artwork>
<postamble>PE to Cx metrics are 50, Cx to Cx are 1</postamble>
</figure>
</t>
<t>
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 much as possible to keep implementation simple.
We propose the following approach :
<list style="symbols">
<t>If an IP prefix is reachable through a TE tunnel, LFA must not compute a protection for it.</t>
<t>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.</t>
</list>
</t>
<t>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.</t>
<t>If i1 == i2, an implementation SHOULD allow for using LFA
FRR backup for F1 and TE FRR backup for F2.</t>
<t>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.</t>
</section>
<section anchor="normative-midpoint" title="Tunnel midpoint case">
<t>
<figure>
<artwork>
-----C1 ---------
/ | \
/ | \
PE1 ---- C2 --- C3 ---- PE2
| /
PE3
Figure 3
</artwork>
<postamble>PE to Cx metrics are 50, except PE3-C3 (60), Cx to Cx are 1</postamble>
</figure>
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.
C2 is a TE tunnel midpoint router. In terms of forwarding, C2 has a MPLS TE forwarding entry for T2, as well as an IP forwarding entry to PE2.
As explained in previous sections, it would be too restrictive and would limit LFA benefit on C2 if C2 would not be able to compute an LFA for the IP forwarding entry to PE2 due to the presence of a transit tunnel.
</t>
<t>
We propose the following approach for a midpoint router of a TE tunnel :
<list style="symbols">
<t>MPLS TE forwarding entries MUST not be protected by LFA (if an operator wants protection, TE FRR could be enabled).</t>
<t>IP forwarding entries MUST be protected by LFA disregarding the presence of a TE tunnel transiting through the primary interface of the destination.</t>
</list>
</t>
<t>
In our example :
<list style="symbols">
<t>MPLS TE forwarding entry for T2 (ending on PE2) would be protected by TE-FRR (if enabled).</t>
<t>IP forwarding entry for PE2 would be protected by LFA.</t>
</list>
In case of failure of C2-C3 :
<list style="symbols">
<t>traffic from PE1 to PE2 (encapsulated in T2), would be protected by TE FRR.</t>
<t>traffic from PE3 to PE2 (native IP), would be protected by LFA.</t>
</list>
</t>
<t>In other words, if a node 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.</t>
<t>If i1 == i2, an implementation SHOULD allow for using LFA FRR backup
for F1 and TE FRR backup for F2.</t>
</section>
</section>
</section>
</section>
<section anchor="sec_management" title = "Operational considerations">
<t> 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.</t>
<section anchor="usecase" title="Relevance of joint LFA FRR and RSVP-TE FRR deployments">
<t>This section describes the deployment scenarios where it can be
beneficial to jointly use LFAs and RSVP-TE FRR.</t>
<t>There are many networks where RSVP-TE is already deployed. The deployment of RSVP-TE is typically for two main reasons :
<list style="symbols">
<t>Traffic engineering : a provider wants to route some flows on some specific paths using constraints;</t>
<t>Traffic protection using Fast-reroute ability</t>
</list>
</t>
<t>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:
<list style="symbols">
<t>Should increase protection on network where FRR is not available everywhere. Although it may not provide full coverage, it will increase the protection significantly.</t>
<t>May provide better protection in specific cases than RSVP-TE FRR</t>
</list>
</t>
<t>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, in
some parts of the network. The following sections discusses the use of
basic RSVP-TE tunnels to extend protection coverage.</t>
</section>
<section anchor="coverage-extension" title="Extending LFA coverage using RSVP-TE tunnels">
<t> We already have seen in previous sections that RSVP-TE tunnels
could be established by an operator to complement LFA coverage. The
method of tunnel placement depends on what type of protection
(link or node) is required, as well as on the set of destinations or
network parts which requires better protection than what LFA can
provide.</t>
<section anchor="tunneldefinition-shortcut" title="Creating multihop tunnel to extend topology">
<t> To extend the coverage, the idea is to use a mechanism extending
LFA by turning TE tunnels into LFA candidates. This mechanism is of a
local significance only.
</t>
<t>
When explicitly establishing tunnels for that purpose, choices have to be made for the endpoints of such tunnels, in order to maximize coverage while preserving
management simplicity. Requirements are that:
<list style="symbols">
<t>Endpoints must satisfy equations from <xref
target="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.</t>
<t>Tunnel must not flow though the link or node to be
protected, explicit routing of tunnel is recommended to
enforce this condition.</t>
</list>
</t>
<t>
The approach to choose tunnel endpoints might be different here when compared to <xref target="I-D.ietf-rtgwg-remote-lfa"/> as endpoint choice is a manual one.
Automatic behavior and scaling of <xref target="I-D.ietf-rtgwg-remote-lfa"/> requires:
<list style="symbols">
<t>Non null intersection of Extended P-Space and Q-Space</t>
<t>Computation of PQ node only for the remote end of the link</t>
</list>
Based on this, <xref target="I-D.ietf-rtgwg-remote-lfa"/> may:
<list style="symbols">
<t>Not find a tunnel endpoint;</t>
<t>Not provide the more efficient protection : -- i.e. provides only link protection, while there is node protection possible for a specific destination</t>
</list>
The proposed solution of manual explicitly routed tunnels is a good
complement for <xref target="I-D.ietf-rtgwg-remote-lfa"/> and
provides more flexibility:
<list style="symbols">
<t>Always a possibility to find a tunnel endpoint for a specific destination.</t>
<t>Possibility to provide a better protection type (link vs. node).</t>
</list>
</t>
</section>
<section anchor="tunnelselection-shortcut" title="Selecting multihop tunnels to extend topology">
<t>From a manageability point of view, computing a
best Q node for each destination could lead to have one different Q
node for 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. </t>
<t> 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 performing the following computations per link:
<list style="format Step %d :">
<t>Compute for each not covered destination (routed on the
link) the list of endpoints that are satisfying equations from
<xref target="RFC5286"/> (node or link protection equations
depending of required level of protection) : nodes in
Q-Space</t>
<t>Remove endpoints that 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 ...</t>
<t>Within the list of endpoints (one list per destination),
order the endpoints by number of destination covered</t>
<t>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)</t>
<t>Remove destinations covered by this endpoint from non
covered list</t>
<t>If non covered list is not empty, restart from Step 1</t>
</list>
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.</t>
</section>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
TBD.
</t>
</section>
<section anchor="Contributors" title="Contributors">
<t>Significant contribution was made by Pierre Francois which the authors would like to acknowledge.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5286;
&RFC3906;
&RFC4090;
</references>
<references title="Informative References">
&REMOTE-LFA;
&IPFRR-TUN;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:00:22 |