Subject: [RRG] LISP-CONS Default Mapper

From: Robin Whittle <[email-masked]>
Date: Fri, 19 Oct 2007 16:08:41 +1000

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 [email-masked] 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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 18 Oct 2007 23:18:49 -0700

> approach like eFIT-APT's or Ivip's to get the updates there.

It could have the full database, it could use any of the mapping  
database schemes already designed, or it could point to another  
default mapper.

If the later, the design is looking like Paul Francis' CRIO which  
fundamentally allows you to reduce table size at the expense of  
stretch. Traditional state/bandwidth tradeoff.

> respond.  Then the architecture would resemble eFIT-APT or Ivip.

I don't understand. And can you explain *briefly*.

> relied on DNS and dropped packets), eFIT-APT and Ivip.

I don't understand what you are saying.

> host with a LISP-mapped address.

I don't understand what you are saying, your first paragraph says  
"within the same ISP's network" and your second paragraph says  
"however, within the same ISP's network".  So I don't know which  
explanation is for which polarity.  ;-)

> think, LISP-CONS would then be potentially incrementally deployable.

The statement saying "LISP-CONS would then be potentially  
incrementally deployable" does not make any sense to me. Old sites  
don''t know how to do LISP so they don't use CONS. New sites that do  
use LISP use CONS.

Let's don't turn this discussion, again, into how can LISP sites talk  
to non-LISP sites. This thread is about "packet loss during mapping  
cache misses".

Dino

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 19 Oct 2007 10:05:14 +0200

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Dino Farinacci
> 发送时间: 2007年10月19日 8:19
> 收件人: Robin Whittle
> 抄送: Routing Research Group list
> 主题: [RRG] Re: LISP-CONS Default Mapper
> 
I believe it would be interesting to combine the distributing mechanism and
the anycast mechanism together in the mapping mechanism. It not only
improves the scalability in mapping database size but also assures the
robustness and low-latency of mapping service.

Xiaohu XU