[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02

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


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

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 the behavior of LFA when RSVP-TE tunnels are
   used simultaneously.

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, 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
   include Simplified BSD License text as described in Section 4.e of



Litkowski, et al.         Expires May 17, 2013                  [Page 1]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


   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  . . . . . . . . . . . . . . .  3
       2.1.2.  TE tunnel as an LFA candidate  . . . . . . . . . . . .  4
       2.1.3.  LFA candidate TE tunnel and TE IGP shortcut  . . . . .  4
       2.1.4.  LFA and TE tunnel to 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  . . . . . . . . . . . .  5
   4.  LFA FRR and MPLS TE FRR interaction scenarios  . . . . . . . .  5
     4.1.  LFA activated on RSVP-TE tunnel headend  . . . . . . . . .  5
     4.2.  LFA activated on RSVP-TE tunnel midpoint . . . . . . . . .  6
   5.  Extending LFA coverage using RSVP-TE tunnels . . . . . . . . .  7
     5.1.  Reference topology . . . . . . . . . . . . . . . . . . . .  7
     5.2.  Creating multihop tunnel to extend topology  . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11





















Litkowski, et al.         Expires May 17, 2013                  [Page 2]


Internet-Draft           lfa-rsvpte-cooperation            November 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.

   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.

   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.


2.  LFA FRR and MPLS TE FRR interaction

   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.

2.1.  LFA on TE head end router

2.1.1.  LFA and TE IGP shortcut

   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.

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




Litkowski, et al.         Expires May 17, 2013                  [Page 3]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


2.1.2.  TE tunnel as an LFA candidate

   TE tunnel LFA candidate mechanism is the ability to use a TE tunnel
   as a virtual neighbor in LFA computation.

   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.

   This would permit to extend LFA coverage as described in
   [I-D.ietf-rtgwg-remote-lfa]

2.1.3.  LFA candidate TE tunnel and TE IGP shortcut

   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 to a directly connected neighbor

   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.

2.2.  LFA on TE midpoint router

   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.

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


3.  Need for LFA and RSVP-TE interactions

   This section describes some of the deployment scenarios where LFA and
   RSVP-TE may interact.




Litkowski, et al.         Expires May 17, 2013                  [Page 4]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


3.1.  Network with some already deployed RSVP-TE tunnels

   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.  The following sections
   describe usage 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




Litkowski, et al.         Expires May 17, 2013                  [Page 5]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


   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









Litkowski, et al.         Expires May 17, 2013                  [Page 6]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


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


5.  Extending LFA coverage using RSVP-TE tunnels

   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.

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.








Litkowski, et al.         Expires May 17, 2013                  [Page 7]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


   (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
   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, LFA is able to protect to partially
   (49%) protect from failure of R3, while failure of R4 is not
   protected at all.

5.2.  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 LFA
   tunnel candidate mechanism.  This mechanism is of a local
   significance only.

   The hardest task is then to choose the tunnel(s) endpoint such as to
   achieve the maximum coverage.  Tunnel definition must satisfy :

   o  Endpoint must satisfy equations from [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



Litkowski, et al.         Expires May 17, 2013                  [Page 8]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


      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 :

   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 :

   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

   o  Possibility to provide better protection level

   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.

   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 :

   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



Litkowski, et al.         Expires May 17, 2013                  [Page 9]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


   Step 2 :  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
             ...

   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.


6.  Security Considerations

   TBD.


7.  Acknowledgements


8.  IANA Considerations

   This document has no actions for IANA.




Litkowski, et al.         Expires May 17, 2013                 [Page 10]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


9.  References

9.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.  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., Shand, M., and S. Ning, "Remote
              LFA FRR", draft-ietf-rtgwg-remote-lfa-00 (work in
              progress), June 2012.


Authors' Addresses

   Stephane Litkowski
   Orange

   Email: stephane.litkowski@orange.com


   Bruno Decraene
   Orange

   Email: bruno.decraene@orange.com








Litkowski, et al.         Expires May 17, 2013                 [Page 11]


Internet-Draft           lfa-rsvpte-cooperation            November 2012


   Clarence Fils Fils
   Cisco Systems

   Email: cfilsfil@cisco.com


   Kamran Raza
   Cisco Systems

   Email: skraza@cisco.com









































Litkowski, et al.         Expires May 17, 2013                 [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/