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

Versions: 00

Network Working Group                                     O. Bonaventure
Internet-Draft                                               P. Francois
Intended status: Experimental                                  D. Saucez
Expires: January 7, 2010                                       UCLouvain
                                                            July 6, 2009


      Preserving the reachability of LISP ETRs in case of failures
                 draft-bonaventure-lisp-preserve-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Bonaventure, et al.      Expires January 7, 2010                [Page 1]


Internet-Draft            LISP ETR reachability                July 2009


Abstract

   Maintaining reachability of an EID prefix despite the failures of
   ETRs is a key concern in the LISP architecture.  In this document, we
   first analyse this problem in comparison with traditional routing
   protocols.  Then, we explain how Internet Service Providers could
   offer a service that preserves the reachability of the LISP ETRs of
   their customers in case of failures.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Using anycast to preserve reachability of EID prefixes in
       case of failure  . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Rewriting to preserve the reachability of EID prefixes . . . .  9
     3.1.  Rewriting interface  . . . . . . . . . . . . . . . . . . . 10
     3.2.  Link and ETR failures  . . . . . . . . . . . . . . . . . . 11
     3.3.  PE failures  . . . . . . . . . . . . . . . . . . . . . . . 12
   4.  Protocol issues  . . . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Verifying the reachability of ETRs . . . . . . . . . . . . 13
     4.2.  Advertising the backup ETR . . . . . . . . . . . . . . . . 14
     4.3.  Destination RLOC rewriting . . . . . . . . . . . . . . . . 14
       4.3.1.  Which packets should be rewritten ?  . . . . . . . . . 14
       4.3.2.  After a failure, for how long should packets be
               rewritten ?  . . . . . . . . . . . . . . . . . . . . . 15
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21


















Bonaventure, et al.      Expires January 7, 2010                [Page 2]


Internet-Draft            LISP ETR reachability                July 2009


1.  Introduction

   Measurements performed in ISP networks indicate that link and node
   failures are frequent events [FAILURES][BGPFRR].  Fortunately, most
   of these failures have a short duration.  However, the more and more
   stringent Service Level Agreements (SLAs) requested by users of IP
   networks have forced researchers and router vendors to develop
   various kinds of fast route techniques that allow a network to
   quickly recover after a node or link failure [RFC4090]
   [I-D.ietf-rtgwg-ipfrr-framework] [RECOVERY].

   The Locator/Identifier Separation Protocol (LISP) [I-D.ietf-lisp] is
   being developed within the LISP working group of the IETF.  LISP
   relies on two principles.  First, Endpoint Identifiers (EIDs) are
   allocated to hosts while Routing Locators (RLOCs) are allocated to
   LISP Ingress/Egress Tunnel Routers (xTRs).  The EIDs are not directly
   routable on the global Internet, only the RLOCs are routable.
   Second, LISP relies on map and encaps.  Hosts are located on sites
   and are served by xTRs.  When host A.1 in site A needs to send a
   packet to host B.2 in site B, its packet is intercepted by the
   Ingress Tunnel Router (ITR) that serves its site.  This ITR will
   query a mapping system to find the RLOC of the Egress Tunnel Router
   (ETR) that serves EID B.2.  Once the RLOC of the ETR serving B's site
   is known, the ITR will encapsulate the packet using the encapsulation
   defined in [I-D.ietf-lisp] so that it can reach B's ETR.  B's ETR
   will decapsulate the packet and forward it to host B.

   Recovery in case of failures is also one of the problems being
   discussed within the LISP working group.  More precisely, the working
   group is working on techniques to verify the reachability of the
   destination ETRs for a given EID prefix.  The current draft,
   [I-D.ietf-lisp], uses several locator reachability bits in the header
   of all data encapsulated packets to allow an ITR to indicate to a
   remote ETR the xTRs on the ITR's site that are known to be reachable
   and unreachable.  For another discussion of the reachability problem,
   see [I-D.meyer-loc-id-implications]

   This reachability problem can be better understood by comparing it
   with the operation of traditional routing protocols in the network
   shown in Figure 1.  In this picture, the stars indicate domain
   boundaries.










Bonaventure, et al.      Expires January 7, 2010                [Page 3]


Internet-Draft            LISP ETR reachability                July 2009


                       +----+      +----+      +----+
                       | R1 |------| R2 |------| R3 |
                       +----+      +----+      +----+
                         |            |           |
                  *******|************************|*******
                         |            |           |
                       +----+      +----+      +----+
                       | R6 |------| R5 |------| R4 |
                       +----+      +----+      +----+
                         |                        |
                  *******|************************|*******
                         |                        |
                       +----+                  +----+
                       | e1 |                  | E2 |
                       +----+                  +----+
                             \                 /
                               \             /
                             ==================
                                    Prefix P


                        Figure 1: A simple network

   Figure 1 shows a simple network with 8 routers and one LAN containing
   a single prefix P. With traditional routing protocols, the prefix P
   will be advertised by both E1 and E2 via BGP.  If E1 and E2 are up, P
   will be reachable via both routers.  If E1 (resp. E2) fails, then all
   the packets destined to P will be sent via E2 (resp. E1).  In such a
   network, the reachability of P is maintained despite the failures of
   E1 or E2 because :

   o  routers E1 and E2 send messages about the reachability of P in the
      entire network

   o  all routers of the network have an entry for prefix P inside their
      Forwarding Information Base (FIB)















Bonaventure, et al.      Expires January 7, 2010                [Page 4]


Internet-Draft            LISP ETR reachability                July 2009


                                    +----+
                                    |ITR1|
                                    +----+
                                       |
                     ******************|*****************
                        +----+      +----+      +----+
                        | R1 |------| R2 |------| R3 |
                        +----+      +----+      +----+
                          |            |           |
                          |            |           |
                        +----+      +----+      +----+
                        | R6 |------| R5 |------| R4 |
                        +----+      +----+      +----+
                          |                        |
                     *****|************************|*****
                        +----+                  +----+
                        |ETR1|                  |ETR2|
                        +----+                  +----+
                              \                 /
                                \             /
                              ==================
                                   EID Prefix P


               Figure 2: A simple network with LISP routers

   Now, let us assume that E1 and E2 are LISP ETRs and that P is an EID
   prefix.  We also add an ITR connected to R2 as shown in Figure 2.
   Since both the network of Figure 1 and of Figure 2 have the same
   topology, they should be able to maintain reachability even in case
   of failures.  Unfortunately, there are several important differences
   :

   1.  the routers are managed by three different autonomous entities
       and different IGPs are used : one for R1-R6, another one for ETR1
       and ETR2 and a third for the network that contains ITR1.  Three
       different routing protocols are used and only aggregated RLOCs
       are advertised accross the boundaries represented by stars in the
       figure.

   2.  The packets sent towards EID prefix P are encapsulated in packets
       destined to ETR1 or ETR2.  There is no entry for prefix P in the
       FIB or routers R1-R6.  ITR1 has one entry for P inside its LISP
       mapping cache.  Only ETR1 and ETR2 can reach directly EID prefix
       P.

   We assume that the middle network uses an IGP to advertise the
   reachability of all the routers (R1-R6) and of the directly attached



Bonaventure, et al.      Expires January 7, 2010                [Page 5]


Internet-Draft            LISP ETR reachability                July 2009


   customers (i.e.  ITR1, ETR1 and ETR2).  This is a very common design.
   For the routers R1-R6, ETR1, ETR2 ad ITR1 are different RLOCs and
   none of these routers is aware of the fact that LISP data
   encapsulated packets sent to ETR1 can also be sent to ETR2.

   The network of Figure 2 is sufficiently redundant to preserve the
   reachability of EID prefix P in case of the failure of ETR1, ETR2, R6
   or R4.  Let us analyse how LISP would react to these four failures :

   o  Failure of ETR1.  In this case, ETR2 can notice the failure by
      either having an iBGP or BFD session with ETR1 or participating in
      the same IGP.  Once ETR2 has detected the failure of ETR1, it
      changes its locator reachability bits so that ITR1 is also
      informed and can redirect the packets destined to EID prefix P via
      ETR2.  The time required to inform ITR1 will depend on both the
      local failure detection time and the current packet transmission
      rate between ETR2 and ITR1.  This only works, of course, if
      traffic is bidirectionnal.

   o  Failure of R6.  To detect such failures, since ETR1 does not
      participate in the ISP's IGP, it needs to use a mechanism to
      verify that its upstream router is alive.  This can be achieved
      for example by having a BGP session between ETR1 and R6 possibly
      coupled with a fast failure detection mechanism such as BFD
      [I-D.ietf-bfd-base].  Once ETR1 has detected the failure of R6, it
      must inform ETR2.  The method used to inform ETR2 is not specified
      by LISP, but is important from a deployment viewpoint.  For
      example, ETR1 could withdrawing the default route learned from R6
      from the site's IGP.  ETR2 can then update the loc-reach bits of
      the LISP encapsulated packets that it sends.  ITR1 will stop
      sending LISP data encapsulated packets to ETR1 as soon as it has
      received the updated loc-reach bits.

   In practice, the time required to detect and recover from such
   failures can be longer than a round-trip-time.  It would be desirable
   in some environments to have a shorter recovery time.  Unfortunately,
   the classical techniques [RECOVERY] deployed in IP and MPLS networks
   are not directly applicable to preserve the reachability of the EIDs
   behind the unreachable ETR.

   In this document, we first analyse several solutions based on anycast
   that can be used by an ISP to preserve the reachability to LISP ETRs
   in case and failures and discuss their advantages and drawbacks.
   Then, we propose a rewriting technique that can be deployed by ISPs
   to ensure that the EIDs of their customers remain reachable despite
   that some of their LISP ETRs are unreachable.





Bonaventure, et al.      Expires January 7, 2010                [Page 6]


Internet-Draft            LISP ETR reachability                July 2009


2.  Using anycast to preserve reachability of EID prefixes in case of
    failure

   A first possible approach to preserve the reachability of EID
   prefixes in case of link or node failures in the service provider
   network to which the ETR is attached is to use anycast routing.  The
   figure below shows a simplified network using the terminology used by
   BGP/MPLS VPNs [RFC2547].  The ISP network contains three Provider (P)
   routers, 3 Provider Edge (PE) routers and two LISP ETRs.  The two
   LISP ETRs are responsible for the same EID prefix P.


                        +----+      +----+      +----+
                        | P1 |------| P3 |------| P2 |
                        +----+      +----+      +----+
                          |            |           |
                          |            |           |
                        +----+      +----+      +----+
                        | PE1|------| PE3|------| PE2|
                        +----+      +----+      +----+
                          |                        |
                    ******|************************|******
                        +----+                  +----+
                        |ETR1|                  |ETR2|
                        +----+                  +----+
                              \                 /
                                \             /
                              ==================
                                  EID Prefix P


                 Figure 3: A simple network with two ETRs

   A first solution to ensure that ETR2 remains reachable when ETR1
   becomes unreachable is to use an anycast address for the RLOC used by
   both ETR1 and ETR2.  For example, with IPv4 a single anycast /32
   would be allocated to both ETR1 and ETR2.  This solution clearly
   ensures that all LISP data encapsulated packets will reach an ETR
   attached to EID prefix P as long as either ETR remains reachable.
   However, it has several important drawbacks :

   o  As ETR1 and ETR2 use the same anycast address, the site cannot
      engineer the incoming traffic toward EID prefix p by tuning its
      mapping replies.

   o  Anycast cannot be used if ETR1 and ETR2 are attached to two
      different ISPs.  Unfortunately, it can be expected that owners of
      sites will often attach their ETRs to different ISP networks to



Bonaventure, et al.      Expires January 7, 2010                [Page 7]


Internet-Draft            LISP ETR reachability                July 2009


      have technical and economical redundancy.  Anycast could probably
      be used if ETR1 and ETR2 were located in the same IGP area (often
      equivalent to the same POP in large ISP networks).

   To allow a site to continue to engineer its incoming traffic, an
   alternative could be to use two anycast addresses as RLOCs for the
   site's ETRs.  PE1 (resp. PE2) would advertise in the ISP's IGP two
   addresses for ETR1 (resp. ETR2) : ETR1's RLOC (resp. ETR2's RLOC)
   with a low IGP distance and ETR2's RLOC (resp. ETR1's RLOC) with a
   very high IGP distance.  With those advertisements, ETR1 and ETR2 are
   both used when they are up.  If ETR1 becomes unreachable, the
   provider's IGP will converge and all packets sent to its RLOC will be
   automatically rerouted to ETR2 which also supports the same RLOC.
   Unfortunately, this solution has the following drawbacks :

   o  It increases the size of the IGP, especially when ETR1 and ETR2
      are not in the same POP/area.

   o  It cannot be used when ETR1 and ETR2 are attached to two different
      ISPs.

   For these reasons, anycast cannot be considered as a technique that
   totally fulfills the role of preserving the reachability of
   multihomed EID prefixes.



























Bonaventure, et al.      Expires January 7, 2010                [Page 8]


Internet-Draft            LISP ETR reachability                July 2009


3.  Rewriting to preserve the reachability of EID prefixes

   To preserve the reachability of EID prefixes in case of failures of
   either the link or the router that connects an ETR to its provider,
   we need to ensure that the packets destined to the RLOC of an ETR
   that became unreachable can be rerouted efficiently by routers in the
   provider's network.  We consider three reference environments where
   our solution must be applicable :

   o  A network where the two ETRs are attached to the same POP of one
      ISP

   o  A network where the two ETRs are attached to different POPs of the
      same ISP

   o  A network where the two ETRs are attached to different ISPs

   The more general case is the third one.  In the remainder of this
   section, we will mainly discuss the topology shown in Figure 4.

   A solution to preserve the reachability of these ETRs in case of
   link/router failures must be applicable to these three deployment
   scenarios.  We consider two different types of failures :

   o  Failure of the link between an ETR and its PE router, such as
      PE1-E1 in Figure 4.  From the viewpoint of the ISP network, the
      failure of a link between a PE and an ETR is equivalent to the
      failure of the ETR itself.

   o  Failure of the PE router to which an ETR is attached, such as PE1
      in Figure 4.  In this case, all the ETRs attached to the PE router
      become unreachable.



















Bonaventure, et al.      Expires January 7, 2010                [Page 9]


Internet-Draft            LISP ETR reachability                July 2009


                                        Internet
                                      /          \
                                  ISP1            ISP2
                              /         |           |
                         +----+      +----+      +----+
                         | P1 |------| P2 |      | P3 |
                         +----+      +----+      +----+
                           |            |           |
                           |            |           |
                         +----+      +----+      +----+
                         | PE1|------| PE2|      | PE3|
                         +----+      +----+      +----+
                           |                        |
                           |                        |
                         +----+                  +----+
                         | E1 |                  | E2 |
                         +----+                  +----+
                               \                 /
                                 \             /
                               ==================
                                      Prefix P
                           -- POP1 --          -- POP3 --


     Figure 4: A network with two LISP ETRs attached to different ISPs

3.1.  Rewriting interface

   Our technique to preserve the reachability of EID prefixes despite
   link and node failures relies on a new type of virtual interface that
   we call a rewriting interface.  Besides real physical interfaces,
   routers often have virtual interfaces such as tunnel interfaces.
   When the nexthop of a packet is a tunnel interface, this packet is
   encapsulated and the encapsulated packet is sent towards the tunnel
   destination.

   A rewriting virtual interface is configured with :

   o  a primary address

   o  a (set of ) alternate addresses

   A rewriting interface can only be used by packets whose destination
   address is equal to the primary address of the rewriting interface.
   When such a packet is to be forwarded by the rewriting interface, its
   destination address is replaced by one of alternate addresses known
   for this interface.  Of course, the IP and UDP checksums of the
   rewritten packets are updated.  When selecting an alternate address,



Bonaventure, et al.      Expires January 7, 2010               [Page 10]


Internet-Draft            LISP ETR reachability                July 2009


   the router should prefer an alternate address that it knows (e.g.
   based on its own routing table or thanks to other information) to be
   reachable.  The rewritten packet is then forwarded towards its new
   destination.

   Instead of using a rewriting interface, another solution could have
   been to encapsulate the packet destined to the failed address towards
   the alternate.  However, using a second level of encapsulation would
   like cause MTU problems.  For this reason, we chose to rewrite part
   of the LISP header.  From an implementation viewpoint, rewriting part
   of a LISP header is similar to the operation performed by a Network
   Address Translator.  Given the current interest in carrier-grade NAT,
   it can be expected that efficient hardware-based NAT implementations
   will appear.

   The operation of the rewriting interface is discussed in more details
   in section Section 4.3.

3.2.  Link and ETR failures

   In this section, we describe informally the principle of our
   solution.  The details are discussed later.  To maintain reachability
   of EID prefix when the link between one of its ETR and the associated
   PE fails, we propose to install a rewriting interface on the upstream
   PE.  Consider for example Figure 4 and that E1 is the ETR whose
   reachability needs to be preserved.  This can be achieved as follows
   :

   o  PE1 is configured with a rewriting interface having E1's RLOC as
      primary address and E2's RLOC as alternate address.  A static
      route for this rewriting interface is configured on PE1, but this
      route has a high administrative distance so that the route is not
      installed in the FIB when E1 is up.

   o  When the link between PE1 and E1 fails, PE1's rewriting interface
      is still up.  Thus, PE1 continues to announce E1's RLOC as being
      reachable in the IGP.  This ensures that packets destined to E1
      still reach PE1.  However, the rewriting interface replaces the
      physical interface as the nexthop for E1 in PE1's FIB.

   o  When a LISP data encapsulated packet destined to E1 arrives while
      E1 is unreachable, PE1 forwards this packet over its rewriting
      interface.  This interface rewrites the destination RLOC of this
      LISP data encapsulated packet with E2's RLOC as destination
      address and the packet is forwarded to E2.

   o  When E1 becomes again reachable, the physical interface towards E1
      replaces the rewriting interface as the nexthop for E1 in PE1's



Bonaventure, et al.      Expires January 7, 2010               [Page 11]


Internet-Draft            LISP ETR reachability                July 2009


      FIB and the rewriting stops.  Rewriting could also stop by
      removing the rewriting interface e.g. after the expiration of a
      timer.

   It should be noted that this solution is purely local on the PE
   router attached to the ETR responsible for the EID prefix whose
   reachability must be preserved in case of failures.  No additional
   prefix needs to be advertised in the IGP.  Thus, there are no
   scalability issues with this solution.

3.3.  PE failures

   To maintain reachability of an EID prefix when the PE attached to one
   ETR fails, we cannot use the solution described above as the PE is
   not reachable anymore.  To solve this problem, we introduce a
   rewriting PE.  A rewriting PE is a PE router that is configured with
   a rewriting interface whose primary address is the address of an ETR
   attached to another PE router.  The rewriting PE will usually be
   located in the same POP as the PE that must be protected.  For
   example, let us consider the failure of PE1 in Figure 4 and assume
   that PE2 is the rewriting PE :

   o  PE2 is configured with one rewriting interface having :

      *  E1's RLOC as primary address

      *  E2's RLOC as alternate address

   o  E1's RLOC is advertised as an anycast address by both PE1 and PE2
      that acts as a rewriting router.  PE2's advertisement has a high
      IGP distance such that PE1's advertisement is always preferred
      inside the ISP network.  Furthermore, the rewriting interface has
      a high administrative distance and thus PE2 does not install a FIB
      entry towards this rewriting interface.

   o  When PE1 becomes unreachable, the IGP converges and PE2 becomes
      the only router that advertises E1's RLOC.  It thus receives all
      packets destined to E1's RLOC.  These packets are rewritten by the
      rewriting interface and forwarded to E2's RLOC.

   o  When PE1 comes back, it readvertises the reachability of E1's
      RLOC.  PE2 prefers PE1's advertisement and stops receiveing
      packets destined to E1's RLOC.








Bonaventure, et al.      Expires January 7, 2010               [Page 12]


Internet-Draft            LISP ETR reachability                July 2009


4.  Protocol issues

   In this section, we discuss in more details the protocols and
   mechanisms that are required to implement the solution described
   informally in the previous section.  We first discuss how a PE can
   verify the reachability of ETRs.  Then we discuss how a rewriting
   router can learn the rewriting address that it should use when an ETR
   becomes unreachable.  Finally we explain how the RLOC of the
   unreachable ETR needs to be rewritten and propose a small change to
   the LISP header for this.

4.1.  Verifying the reachability of ETRs

   The first router that needs to detect the unreachability of a LISP
   ETR is the PE router directly connected to it.  Several mechanisms
   can be used to detect this unreachability : physical layer
   information (if available), BFD or a single hop eBGP session could be
   established between the PE and the ETR.  No prefix will be advertised
   by the ETR on this eBGP session, but the PE may advertise a default
   route or its full BGP (RLOC) routing table.

   However, the rewriting PE router could also need to verify the
   reachability of the ETR that owns the RLOC that it will rewrite if
   the primary ETR becomes unreachable due to the failure of its
   attached PE.  This is especially important when the the rewriting PE
   knows several alternate ETR routers.  If it only knows a single
   alternate ETR and the primary fails, the only solution is to rewrite
   the packets towards the only alternate ETR.  This alternate ETR can
   be located in the same POP, in another POP or in another ISP.  Thus,
   the rewriting PE cannot always rely on its routing table to verify
   the reachability of such a distant ETR.

   To allow a PE to know which of the alternate addresses for a given
   primary address are alive, we propose to use multihop eBGP sessions
   to distribute the reachability information of each ETR.  Reachability
   information could be distributed as follows :

   o  Each LISP site, containing at least one EID prefix and several
      ETRs is allocated a unique route target.

   o  Each ETR has a single-hop BGP session with its attached PE router.
      On this eBGP session, the ETR advertises only its own RLOC with
      the allocated route target.

   o  The PE routers and the routers with rewriting interfaces are part
      of an iBGP mesh (e.g. based on route reflectors) where the routes
      received by the ETRs are distributed with their route target.




Bonaventure, et al.      Expires January 7, 2010               [Page 13]


Internet-Draft            LISP ETR reachability                July 2009


   o  The route reflectors of different ASes that host LISP ETRs can
      exchange the routes received from their ETRs by using multihop
      eBGP sessions.

   o  A rewriting router only needs to receive reachability information
      for alternate addresses that it supports.  This can be achieved by
      requesting in the iBGP mesh all the routes with a list of route
      targets.

   The next version of this document will analyse this problem in more
   details

4.2.  Advertising the backup ETR

   In the previous section, we have assumed that the PE and the
   rewriting router were configured with several information.  Such a
   manual configuration is possible, but in practice it would be useful
   to allow some of these routers to automatically learn some of this
   information.  For example, it would be useful for a PE router to
   learn automatically the backup RLOCs to be used in case of failure of
   one of its directly attached ETRs.  This can be achieved by either :

   o  developing a new protocol to advertise these backup RLOCs to be
      rewritten

   o  using BGP and defining a new address family that allows BGP to
      carry this kind of information

   o  extending the Map-Request/Map-Reply and allow the PE to query the
      ETR for its alternate ETR

   The next version of this document will analyse in more detailed the
   advantages and drawbacks of each of these two approaches.

4.3.  Destination RLOC rewriting

   Our solution rewrites the destination RLOC of LISP packets once the
   destination of this packet has been found unreachable.  This
   rewriting raises several questions as discussed in the following
   sections.

4.3.1.  Which packets should be rewritten ?

   A LISP ETR will receive different types of packets and we need to
   define which packets should be rewritten by the rewriting router.
   LISP encapsulated data packets should be rewritten.  However, we need
   to ensure that when multiple failures occur LISP encapsulated data
   packets do not loop between rewriting routers.  This can be achieved



Bonaventure, et al.      Expires January 7, 2010               [Page 14]


Internet-Draft            LISP ETR reachability                July 2009


   by reserving one bit in the LISP header, called the Deflection (D)
   bit.  When an ITR sends a data encapsulated packet, it sets the D bit
   to false.  When a rewriting router receives a LISP data encapsulated
   with the D bit set to false, it can rewrite the destination address
   of the packet.  If the D bit is set to true, the packet must be
   dropped.  LISP control packets, i.e.  Map-Request and Map-Reply
   packets, do not need to be rewritten as they are targeted at the ETR
   itself and not at hosts behind the ETR.  Non-LISP packets destined to
   the ETR do not need to be rewritten either.

   Upon reception of packets with the D bit set, the ETR knows that the
   packets have been deflected by upstream routers, likely due to an
   upstream failure.  This ETR will soon detect the failure by other
   means (e.g. the primary ETR stops advertising its default route in
   the site's IGP).

4.3.2.  After a failure, for how long should packets be rewritten ?

   In theory, the ITR which is sending packets to the ETR could have
   learned the mapping up to TTL minutes ago if TTL is the mapping
   lifetime.  Thus, the rewriting entry should remain in the rewriting
   router for a duration at least equal to the lifetime of the mapping
   entries if we do not want to loose encapsulated packets.  With a
   default mapping lifetime of 24hours, this duration can be large.  In
   practice however, most of the failures have a short duration and the
   ETR will become reachable again well before the expiration of the
   lifetime of its mapping entries.
























Bonaventure, et al.      Expires January 7, 2010               [Page 15]


Internet-Draft            LISP ETR reachability                July 2009


5.  Security Considerations

   To be written once the details of the protocols have been specified.
















































Bonaventure, et al.      Expires January 7, 2010               [Page 16]


Internet-Draft            LISP ETR reachability                July 2009


6.  Conclusion

   In this document, we have first compared the LISP reachability
   problem with the traditional reachability problem with routing
   protocols.  We have then shown the drawbacks of using anycast to
   preserve the reachability of LISP ETRs in case of failures.  Then, we
   have proposed to allow PE routers to rewrite the destination address
   of LISP encapsulated packets to preserve the reachability of the EID
   prefix in case of failure of one of the responsible ETRs.  Further
   work is required to define the protocols and mechanisms that are
   necessary to allow ISPs to preserve the reachability of the ETRs of
   their customers.







































Bonaventure, et al.      Expires January 7, 2010               [Page 17]


Internet-Draft            LISP ETR reachability                July 2009


7.  Acknowledgements

   We would like to thank Dave Meyer for his comments on the first
   version of this draft.  This work was partially supported by a Cisco
   URP grant.














































Bonaventure, et al.      Expires January 7, 2010               [Page 18]


Internet-Draft            LISP ETR reachability                July 2009


8.  References

8.1.  Normative References

   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              May 2005.

8.2.  Informative References

   [BGPFRR]   Bonaventure , O., Filsfils, C., and P. Francois,
              "Achieving Sub-50 Milliseconds Recovery Upon BGP Peering
              Link Failures",  Conext   2005 .

   [FAILURES]
              Markopoulou, A., Iannacone, G.,  Chattacharyya, S.,
              Chuah, C., and C. Diot, "Characterization of Failures in
              an IP Backbone", INFOCOM 2004.

   [I-D.ietf-bfd-base]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", draft-ietf-bfd-base-09 (work in progress),
              February 2009.

   [I-D.ietf-bfd-multihop]
              Katz, D. and D. Ward, "BFD for Multihop Paths",
              draft-ietf-bfd-multihop-07 (work in progress),
              February 2009.

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-01 (work in progress), May 2009.

   [I-D.ietf-rtgwg-ipfrr-framework]
              Shand, M. and S. Bryant, "IP Fast Reroute Framework",
              draft-ietf-rtgwg-ipfrr-framework-10 (work in progress),
              February 2009.

   [I-D.meyer-loc-id-implications]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID Separation", draft-meyer-loc-id-implications-01
              (work in progress), January 2009.

   [RECOVERY]
              Vasseur, J., Demeester, P., and M. Pickavet, "Network
              Recovery: Protection and Restoration of Optical, SONET-
              SDH, IP, and MPLS", Elsevier Science & Technology



Bonaventure, et al.      Expires January 7, 2010               [Page 19]


Internet-Draft            LISP ETR reachability                July 2009


              Books 2004.

   [RFC2547]  Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
              March 1999.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.











































Bonaventure, et al.      Expires January 7, 2010               [Page 20]


Internet-Draft            LISP ETR reachability                July 2009


Authors' Addresses

   Olivier Bonaventure
   UCLouvain
   Universite catholique de Louvain, Place Sainte Barbe 2
   Louvain-la-Neuve,   1348
   Belgium

   Email: olivier.bonaventure@uclouvain.be
   URI:   http://inl.info.ucl.ac.be


   Pierre Francois
   UCLouvain
   Universite catholique de Louvain, Place Sainte Barbe 2
   Louvain-la-Neuve,   1348
   Belgium

   Email: pierre.francois@uclouvain.be
   URI:   http://inl.info.ucl.ac.be


   Damien Saucez
   UCLouvain
   Universite catholique de Louvain, Place Sainte Barbe 2
   Louvain-la-Neuve,   1348
   Belgium

   Email: damien.saucez@uclouvain.be
   URI:   http://inl.info.ucl.ac.be





















Bonaventure, et al.      Expires January 7, 2010               [Page 21]


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