One document matched: draft-litkowski-rtgwg-lfa-rsvpte-cooperation-00.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-00" 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 Fils Fils" initials="C" surname="Fils Fils">
<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 month="November" year="2012" />
<area></area>
<workgroup>Routing Area Working Group</workgroup>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t>
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 the behavior of LFA when RSVP-TE tunnels are
used simultaneously.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<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>
<t>
This document is being discussed on the rtgwg@ietf.org mailing list.
</t>
<t>
When a failure occurs inside an IP network, network has to converge.
This convergence leads to traffic disruption. Some mechanisms are
already available to limit traffic disruption by computing alternate
path and switching locally to alternate path as soon as failure is
detected. All this can be termed as a protection mechanism. Currently,
the widely used protection mechanisms for traffic 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 as well as potential
scaling issues. Whereas, LFA is a very easy, manageable and quite scalable
mechanism but it does not provides full coverage.
</t>
<t>
This document presents some scenarios where LFA and RSVP-TE may interact.
The document also proposes the usage of RSVP-TE tunnels to extend LFA coverage
and clarifies interactions between the two protection mechanisms.
</t>
</section>
<section anchor="normative" title="LFA FRR and MPLS TE FRR interaction">
<t>This section provides the summarized normative requirements for the interaction between LFA FRR and TE FRR. Following sections provide illustration and reasoning why an operator may care for these behavior.</t>
<section anchor="normative-head-end" title="LFA on TE head end router">
<section anchor="normative-head-end-igp-shortcut" title="LFA and TE IGP shortcut">
<t>If a node N 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>
</section>
<section anchor="normative-head-end-remoteLFA" title="TE tunnel as an LFA candidate">
<t>TE tunnel LFA candidate mechanism is the ability to use a TE tunnel as a virtual neighbor in LFA computation.</t>
<t>If a node N has an IGP/LDP forwarding entry F1 with outgoing interface i1 and N originates a TE tunnel T1 terminating at node Y, then an implementation SHOULD support a local policy which instructs node N 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>
<t>This would permit to extend LFA coverage as described in <xref target="I-D.ietf-rtgwg-remote-lfa"/></t>
</section>
<section anchor="normative-head-end-remoteLFA-igpshortcut" title="LFA candidate TE tunnel and TE IGP shortcut">
<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-head-end-tunneltoneighbor" title="LFA and TE tunnel to a directly connected neighbor">
<t>If a node N has an IGP/LDP forwarding entry F1 with outgoing interface i1, and N 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>
<section anchor="normative-midpoint" title="LFA on TE midpoint router">
<t>If a node N 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 anchor="usecase" title="Need for LFA and RSVP-TE interactions">
<t>This section describes some of the deployment scenarios where LFA and
RSVP-TE may interact.</t>
<section anchor="usecase1" title="Network with some already deployed RSVP-TE tunnels">
<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>
</section>
<section anchor="usecase2" title="Network with no protection at all">
<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%.</t>
<t>Providers may want to increase protection coverage if LFA benefit is not sufficient for some destinations. The following sections describe usage of basic RSVP-TE tunnels to extend protection coverage.</t>
</section>
</section>
<section anchor="interaction-scenarios" title="LFA FRR and MPLS TE FRR interaction scenarios">
<section anchor="interaction-scenario1" title="LFA activated on RSVP-TE tunnel headend">
<figure>
<artwork>
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
</artwork>
</figure>
<t>
In figure 1, shortest path from R1 to R11 is : R1-R2-R3-R8-R9-R10-R11.
</t>
<t>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 (<xref target="RFC3906"/>) is activated on R3, leading to the following forwarding informations (not exhaustive) on R3 :
<list style="symbols">
<t>R8 and R9 via tunnel2</t>
<t>R10 and R11 via tunnel1</t>
<t>R4 and R5 via R4</t>
<t>R14 via R14</t>
</list>
Per destination LFA is also activated on R3
</t>
<t>
Based on the normative principles already described, here are the FRR backup paths :
<list style="symbols">
<t>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.</t>
<t>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.</t>
<t>R4 has primary nexthop R4, alternate is R12. (no ambiguity in this case as no tunnel is involved)</t>
<t>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.</t>
</list>
</t>
</section>
<section anchor="interaction-scenario2" title="LFA activated on RSVP-TE tunnel midpoint">
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t>
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.
</t>
<t>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).</t>
<t>
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).
</t>
</section>
</section>
<section anchor="coverage-extension" title="Extending LFA coverage using RSVP-TE tunnels">
<t>
We already have seen in previous section that creating RSVP-TE tunnels would increase LFA coverage.
The choice of tunnel placement should depend on what type of protection (link or node) we want to achieve, as well as on the set of destinations we want to protect.
</t>
<section anchor="topology2" title="Reference topology">
<t>
Some topologies like rings do not work well with LFA. We consider the following topology in our document for further illustration.
</t>
<figure>
<artwork>
(30 routers) --- R1 ----(30)---- R2 --- (50 routers)
| |
(5) (30)
| |
R3 R4 --- (20 routers)
| |
(10) (30)
| |
------- R5 ------
Figure 5
</artwork>
</figure>
<t>
In this topology, we consider LFA enabled on all routers and links. We will focus on R5 view of the network.
</t>
<t>
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 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.
</t>
<t>
Globally from R5 point of view, LFA is able to protect to partially (49%) protect from failure of R3, while failure of R4 is not protected at all.
</t>
</section>
<section anchor="tunneldefinition-shortcut" title="Creating multihop tunnel to extend topology">
<t>
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.
</t>
<t>
To extend the coverage, the idea is to extend the topology using LFA tunnel candidate mechanism. This mechanism is of a local significance only.
</t>
<t>
The hardest task is then to choose the tunnel(s) endpoint such as to achieve the maximum coverage.
Tunnel definition must satisfy :
<list style="symbols">
<t>Endpoint must satisfy equations from <xref target="RFC5286"/>, otherwise it will not be a LFA : 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 highly 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 better protection level</t>
</list>
From manageability aspect of our manual solution, computing a best Q node for each destination could lead to have one different Q node for different 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 that do the following computation 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 endpoint that you want to avoid to use as 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 all 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.
Globally, configuring 2 tunnels providing 80% coverage would be considered as (operationnally) better than configuring 15 tunnels to obtain 100% coverage.
</t>
<t>
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.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
TBD.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
</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-24 03:16:51 |