Subject: [rrg] LISP-NERD-Map-Resolver ~= APT & Ivip

From: Robin Whittle <[email-masked]>
Date: Tue, 10 Mar 2009 14:32:19 +1100

Perhaps the LISP team is contemplating using NERD full push mapping
distribution to Map-Resolvers, instead of ALT or CONS.

   LISP Map Server (and Map-Resolvers)  2009-03-03
   http://tools.ietf.org/html/draft-fuller-lisp-ms-00

   http://www.ietf.org/mail-archive/web/rrg/current/msg04575.html

      Dino wrote:  "... a Map-Resolver can be a LISP-ALT
                    router/system, a NERD system, or a
                    CONS/DHT system."

This "LISP-NERD-Map-Resolver" (my term) architecture would resemble
the APT and Ivip architectures in some important ways, since all
three architectures involve the global push of mapping to local
full-database query servers.

I think this approach would replace ALT or CONS entirely.  If the
mapping was centralised to one or a smallish number of servers, as it
is in NERD, then there would be no point in building and running an
ALT global query server network too.  I think it would be simpler to
have the entire system work with Map-Resolvers getting their database
updates via the NERD system.

These local full database query servers ("Default Mappers" in APT)
are typically located in each ISP and handle mapping queries from
ITRs in that ISP's network.  With Ivip and perhaps LISP, the local
query servers (Map-Resolvers for LISP) also handle mapping requests
from ITRs in end-user networks which use the ISP.

There are profound advantages of this architecture over a global
query server architecture such as LISP-ALT or LISP-CONS, including:

  a - The mapping reply comes back to the ITR nearly instantly. So
      there is no significant delay for any traffic packets.

  b - The traffic costs of the request and reply are minimal since
      they are within the local ISP network and perhaps the end-user
      network if the ITRs are there too.  (But there are traffic
      costs getting the continual feed of mapping updates to each
      local query server.)

  c - A local query server is a much more reliable source of mapping
      than sending the query over any global query server network
      such as ALT or CONS.

  d - No need for Map-Servers or for ETRs to necessarily be the
      authoritative source of mapping.

  e - If the Map-Resolver can tell the ITR whenever new mapping
      arrives, then (depending on how fast the push system is) there
      is reduced or no reason to fuss with reachability bits,
      mapping version numbers, ETRs prompting ITRs to get new
      mapping etc.

  f - For Ivip, with essentially real-time mapping distribution with
      direct (previous query nonce secured) push of updates from
      local query servers to the ITRs  which may need it, then there
      is no need for multiple choice of ETR addresses.

      The mapping consists of a single ETR address and the ITR has
      no decision to make regarding which ETR to tunnel packets to.

      This also completely separates the probing and decision making
      from the core-edge separation scheme itself, whereas for a
      slow push system, it has to be integrated, since the ITRs have
      do this individually.

     (See recent message: "Concerns about LISP Reachability Bits &
      Ivip's distributed probing" for a description of the separate
      probing and decision system.

      http://www.ietf.org/mail-archive/web/rrg/current/msg04587.html)

Of course, in place of the ALT or CONS global query server system,
there there needs to be substantial Map-Servers, and a secure robust,
global mapping distribution system by which the Map-Servers can boot,
get the current mapping and then keep their copy up to date.  This is
non-trivial, but I am sure it is worth it.

APT gets its mapping to its local query servers (Default Mappers) in
a totally different manner to Ivip, and NERD (which was originally
conceived of being for all ITRs having the full database) does it yet
another way, with each device downloading mapping and updates from
centralised servers).

  http://tools.ietf.org/html/draft-farinacci-lisp-12
  http://tools.ietf.org/html/draft-lear-lisp-nerd-04
  http://tools.ietf.org/html/draft-fuller-lisp-alt-05
  http://tools.ietf.org/html/draft-lewis-lisp-interworking-02

  http://www.cs.ucla.edu/~meisel/apt-rrg.pdf
  http://tools.ietf.org/html/draft-jen-apt-01

  http://www.firstpr.com.au/ip/ivip/
  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-01

   (I plan a much improved, shorter, architectural I-D in the
    next few months.)

  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Tue, 10 Mar 2009 19:01:41 +1100

Hi Dino,

You wrote to the LISP list:

> No, we are not contemplating. We are just saying that we *can* use any
> database mapping system. We still think the most robust, proven, and one
> with decent management tools is LISP-ALT. And the fact you can use
> off-the-shelf routers is a huge plus as well.

I could build a house in many ways.  If I worked in a timber yard,
I would probably be strongly tempted to build one of wood rather
than brick.

However, experience[1] shows that timber is not necessarily the
optimal choice.

  - Robin

[1] cf. The Dew Drop Inn, in: Freleng, F., Freberg, S. and Rogers, S. (1957),
    http://www.youtube.com/results?search_type=&search_query=Three+Little+Bops