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

[RRG] Re: LISP-CONS Default Mapper = Re-Encapsulating Tunnel Router

This is a completely changed behavior for the entire LISP system,
No, it was always an option. It's the type of mapping system one uses that dictate if a packet gets dropped or not. 


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.


I think CRIO (http://www.ieee-icnp.org/2006/papers/s4a4.pdf) is less
similar to my understanding of the use of LISP with RETRs than is
eFIT-APT or Ivip, since these two, like LISP, are intended to be
incrementally deployable without overall changes in addressing
and/or the capabilities of DFZ routers.


The reference to CRIO only was for the state/stretch 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*.


I was assuming that a RETR would have a full database - a RETRD -
and that the RETRD would be located in the same ISP's network as the
other ITRs.  I assumed therefore that the RETRD receives a complete
feed of database updates by some system other than CONS - which I
understand is a query-based system and so is not designed to
broadcast all the changes which occur in a mapping database.

In this case, with a copy of the full database in the RETRD
somewhere in the ISP's network, why would any of the ITRs in that
network need to use the global CAR-CDR network?  That would be much
slower and less reliable than using some query system which got
results directly from the nearby RETRD.
The ITRs wouldn't need to use the CAR-CDR network directly if they had a mapping. The CONS spec says an ITR only sends a Map-Request when it gets a cache miss. But if the ITR had 0.0.0.0/0 in it's mapping database, it would never have a cache miss. 


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.


As long as non-LISP sites cannot get packets to an ITR, then sending
hosts in those sites will not be able to reach any host which has a
LISP-mapped address.  This is because, in my understanding of LISP
in general and LISP-CONS in particular (not counting Eliot's
suggestion, which I assume applies only to LISP-NERD), the address
space which is used for EIDs is not advertised in BGP.


Okay, so we are changing the subject of this thread.

This was brought up at Nanog as well. Let me put it simply:
o Of course non-LISP site cannot get access to a LISP site if it withdraws it's PI 
  prefix out of the routing system.
o Of course a non-LISP site today cannot get access to another non- LISP site if it 
  withdraws it's prefix from the routing system.
So, it's not that LISP is forcing this. We all want to withdraw routes so the only way to get packets to a LISP site from a non-LISP site is to have the packets hit an ITR some where on the path to the LISP site. That could be a proxy ITR that does this. Or the LISP site can be smart enough to use an EID that *is in* the routing system. Such as a PA address that will always continue to be there.
We are working out the details on how to get a LISP site to talk to a non-LISP site. In our test rig we have it working already. It is very simple by using the following rule:
If the ITR has a cache mapping for a destination site, use it and encapsulate the packet with a LISP header. If the ITR does not have a cache mapping for a destination site, it does not encapsulate.
That is how I (at cisco) debug the LISP boxes that DaveM/Vince/Darrel/ Shep have deployed. They are LISP sites and cisco is not one. 

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