Subject: Re: [RRG] Evolutionary Possibilities - host MH/portability, IPv4 address depletion

From: Robin Whittle <[email-masked]>
Date: Sun, 17 Feb 2008 13:14:11 +1100

Hi Randall,

You wrote, in part:

> [3] Maybe I have missed something somewhere (certainly I am 
> behind in my reading of various proposals), but it also is not 
> obvious to me that the map-and-encapsulate solution class is
> helpful for things beyond site multi-homing -- for example (a)
> host  multi-homing, (b) host mobility, (c) network mobility. 

I intend that Ivip achieve all these.

I think the LISP folks are unhappy with the idea of individual IPv4
IP addresses being used as EIDs (or I guess /64s for IPv4) so I
think they are aiming their system to do "network" (many IP
addresses and hosts per EID prefix) multihoming, not "host" multihoming.

So far, Ivip is the only map-encap proposal which explicitly aims to
provide mobility - for networks or single IP addresses.  To do this,
a fast push system is needed - either to all ITRs in the world (pure
push), or to some and to query servers which answer mapping queries
for nearby caching ITRs (hybrid push-pull).  I think there also
needs to be a notification system by which the query server can send
a message to an ITR about updated mapping for a micronet (EID
prefix) which it queried recently and which has just had its mapping
changed.

> A question in my mind is whether the Routing RG is trying to solve
> just the narrow near-term issue of RIB/FIB scaling issues caused
> by site multi-homing XOR the Routing RG is trying to create an
> enhanced architecture that solves a much broader set of
> current/future issues.

I believe we should be doing the latter.  That is what I am working
on - including using Ivip to help with the IPv4 address depletion
problem by enabling much finer management of address space, to allow
much higher utilization rates.

That said, I think LISP, APT, Ivip or TRRP could all be used for
"host multihoming / portability" and for the finer slicing and
dicing we need to better utilize IPv4 space.  (LISP, APT and I think
TRRP can do TE for individual IP addresses - Ivip can't.)

  - 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: Scott Brim <[email-masked]>
Date: Wed, 20 Feb 2008 10:32:13 -0500

On 2/16/08 9:14 PM, Robin Whittle allegedly wrote:
 > (or I guess /64s for IPv4)

This makes no sense.  How many bits are there in an IPv4 address?

 > so I

There is an authentication problem with map-n-encap and wandering EIDs. 
  Suppose a device visits a site and wishes to use an EID that is not in 
a prefix that that site normally announces, and the site agrees to 
announce it.  Why should the mapping infrastructure, whatever it is, 
listen to the announcement of that new EID?  You could have it trust 
whatever it's told, but more likely there will be filters in place to 
defend against bogus announcements, intentional or otherwise.  Compare 
BGP route filters.

However, there is not really a need for this anyway.  An EID names an 
interface -- a network attachment point.  It is not a persistent name 
for a device.  Session continuity (the real gist of the IP mobility 
problem you're trying to solve) does not and should not need continuity 
of IP "address" as you move.

> prefix) which it queried recently and which has just had its mapping

I just don't see this scaling.  Can you put together a model of how you 
think it would work that we can put numbers into, to see when it melts?