[RRG] Future mapping DB size, small micronets/EIDs

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

Hi Scott,

In "Re: [RRG] Evolutionary Possibilities - host MH/portability, IPv4
address depletion, you wrote:

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

I meant IPv6.


>> so I think they are aiming their system to do "network" (many
>> IP addresses and hosts per EID prefix) multihoming, not "host"
>> multihoming.
>
> There is an authentication problem with map-n-encap and wandering
> EIDs.

(See new thread "Authentication of authority to control mapping"
concerning the questions you raise about problems with securely
controlling mapping.)

Is it true that with LISP in general, or at least with LISP-ALT,
that you not anticipating the system to be used to control the
mapping of individual IPv4 addresses or IPv6 /64s, but to be used
for some larger number of these?

If so, please give some examples of the lower limit of number of
IPv4 addresses per EID prefix - the longer prefix limit - you think
the system should be used for.

For instance, do you think LISP should be used to provide EID IPv4
prefixes longer than /24?   Or some other limit shorter than /32?
If not, I would like to understand your reasoning.


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

I think that unless you have host changes, session continuity
depends entirely on persistence of the IP - address used by
applications and seen by the correspondent hosts - as the device
moves.  Traditional approaches to Mobile IP involve fancy software
at one or both ends, and usually a "home agent" router, with the
likelihood of long path lengths unless the correspondent host has
upgraded software too.

Ivip's approach to mobility is different.  The mobile device retains
its IPv4 (or IPv6) address or prefix (with Ivip, actually any
contiguous number of them, from any starting point) and the
applications run via this address.  The device gains one or more
care-of addresses in the various networks it connects to, and sets
up a two-way encrypted tunnel to a Translating Tunnel Router (TTR)
which behaves like an ETR to the rest of the Ivip system, but can
also get packets out to the Net.  This is described further in:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.html#rfc.section.4.5

Since there is a lot you can do with a single IP address, I think
the map-encap architecture should support and work efficiently with
single IPv4 address EIDs/micronets.


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

I intend to do this, but the melting point depends on the technology
of the day.  By the time a billion micronets are needed, we will
have cheaper CPUs, RAM, bandwidth etc.

Can you write about how LISP-ALT or LISP-NERD could support mobility
or not?

Also, given the answer to that question, how many EIDs do you think
- as an outside but not unrealistic estimate - a LISP scheme would
ever have to support, say in 2015, 2020, 2030, 2040 and 2050?

  - 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