[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Re: LISP-CONS Default Mapper

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


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.


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


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.


I don't understand what you are saying.


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


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

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