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

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

Hi Dino,

I would appreciate you and other people commenting on my packet loss
and sending host time-out example:

  http://psg.com/lists/rrg/2007/msg00462.html

When I wrote:

>> This is a completely changed behavior for the entire LISP system,

I meant that this is very different from LISP-CONS without
full-database Re-Encapsulating Tunnel Routers - because all packets
are tunnelled to the ETR, whereas without such full-database RETRs,
packets are dropped when there is no mapping information at the
caching ITR.


You wrote:

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

Yes, but my suggestion is that if you have the full mapping database
in a local full-database RETR, then it would make sense to use that
(or a nearby server which also gets the full feed of updates too) as
a local, fast, ~100% contactable, query server.  This means you
don't need the CDR-CAR system.

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

I agree.  I think Eliot was contemplating keeping the prefixes
advertised in perpetuity in order to enable full reachability from
non-upgraded networks for LISP-NERD-mapped addresses.

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

> We all want to withdraw routes . . .

Not me - and maybe not Eliot.  I would be happy for any of the
ITR-ETR proposals to work with the same or a moderately higher
number of BGP advertised prefixes, as long as, in general, each such
prefix serves the needs of multiple end-users who would try and
probably succeed in getting a prefix if there was no ITR-ETR system
to serve their needs for multihoming and portable address space.
(Apologies to those who wince at this term.)


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

As far as I can see, the only way a "proxy ITR" could receive
packets from non-upgraded networks is for the prefix these addresses
are part of to be advertised in BGP.  Without a BGP advertisement
for the prefix in which LISP maps address space, the packets will
never leave the border routers of the non-upgraded networks.

So I think there needs to be at least one "proxy ITR" in the world
which advertises the prefix.  The Ivip approach - and I think what
Eliot was exploring - is for there to be multiple such "proxy ITRs"
outside non-upgraded networks, all advertising the prefix, so most
packets don't rely on the one ITR and so most packets have more
optimal paths.


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

There is no problem with a sending host in a network with LISP ITRs
sending packets to hosts with non-LISP mapped addresses, including
those in sites with no LISP ITRs and/or ETRs.  The problem I am
discussing is how to get a packet from a sending host in a network
with no LISP ITRs to an ITR so it can be tunneled to the right ETR
of a destination host with a LISP-mapped address.

 - 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