[RRG] LISP-CONS Default Mapper

[Robin Whittle <rw@firstpr.com.au>]

Hi Dino,

In "Re: [RRG] cache issues in LISP and CONS" you wrote:

> We have text in draft-farinacci-lisp-04.txt (been there since -00)
> on "re-encapsulating tunnel routers". The deployment would be like
> this:
>
> o  All ITRs would be configured with a default mapping of an
>    EID-prefix of 0.0.0.0/0 with one or more locators pointing to
>    the default mapper.
>
> o  The default mapper would decap the packet, interrogate the
>    inner DA EID and assuming it had more specific mappings, would
>    either encapsulate to the next mapper along the way to the
>    destination or directly to the ETR at the destination site.
>
> o  Then policy could decide if the ETR sends a Map-Reply back to
>    the ITR so a direct path can be taken for subsequent packets,
>    or continue to use the default-mapper path.

This requires the Default Mapper to be an ITR with a full copy of
the database - which means you need to use NERD or some other
approach like eFIT-APT's or Ivip's to get the updates there.

If you are doing that, then why not make the ITR or some nearby
server a query server for local caching ITRs?  This would be faster
than the caching ITRs waiting for the global CAR-CDR network to
respond.  Then the architecture would resemble eFIT-APT or Ivip.

As long as your Default Mapper is in the same ISP's network, you are
remaining true to the LISP-CONS architecture and the system should
never drop or delay a packet.  This puts it in good company with
LISP-NERD (sorry about my mistaken statements recently that it
relied on DNS and dropped packets), eFIT-APT and Ivip.

However, as long as the Default Mapper is within the same ISP's
network as the caching ITRs which feed it, then it doesn't solve the
incremental deployment problem of sending hosts in non-upgraded
(having no LISP ITRs) networks being unable to send packets to any
host with a LISP-mapped address.

To fix that, you could follow the path Eliot took and deploy one or
more ITRs, which know how to tunnel the packets, to which
un-tunnelled packets flow from all those non-upgraded networks.

   http://psg.com/lists/rrg/2007/msg00260.html
   http://psg.com/lists/rrg/2007/msg00264.html
   http://psg.com/lists/rrg/2007/msg00288.html

If you have a few of them, as Eliot suggested, then this much the
same as the Ivip "anycast ITRs in the core" approach.  Then, I
think, LISP-CONS would then be potentially incrementally deployable.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg