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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Robin,

On 2008-02-22 14:15, Robin Whittle wrote:
> Hi Brian,
> 
> Regarding maximum length of LISP EID prefixes, you wrote:
> 
>> I think we've had that conversation (at least, I was having it
>> with Tony). My conclusion is that the longest prefix is
>> undoubtedly /32 or /128, but that doesn't answer the important
>> question of how many prefixes need to be mapped, which depends
>> on how many sites need to be mapped and what is their size
>> distribution.
> 
> While I understand the mapping data format for LISP will enable a
> /32 IPv4 to be specified, I wonder whether it makes sense to have
> ITRs all over the world tying to divide the IPv6 address space any
> finer then /64.
> 
> To allow for /128 in the data format rather than limiting it to /64
> adds another 8 bytes to every EID record, although it is going to be
> very long anyway, since there will be multiple 128 bit RLOC
> addresses for the ETRs.

The EID format is going to be variable length anyway, so we could
have three lengths: IPv4/32, IPv6/64, IPv6/128. Or make it
completely variable length, if redundant bits are really an issue.

> I also think that allowing /128s will complicate the design of every
> ITR, or at least bloat it or slow it down if someone really uses a
> /128 EID prefix.

Certainly, but I think that we shouldn't exclude it by design. That
would be like repeating the classful addressing error in IPv4-RFC791.

   Brian

> I am interested to know how the key LISP-ALT people envisage their
> system being used.  Their notion of the end-users the system serves
> isn't in the IDs, but I infer from some of what they write on the
> list that their vision is a lot more like current PI space end-users
> than the broad range of end-users, including non-technical
> individuals with cellphones and laptops, I and a few other people
> are envisaging.
> 
> 
>>> 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?
> 
>> And to that question we've had answers in the 10^7 to 10^9 range,
>> depending on a lot of assumptions which are economic and
>> sociological as much as they are technical.
> 
> But what do you and the LISP-ALT folks think about mobility?  I
> don't see how mobility could be provided by ALT, NERD, APT or TRRP.
> I can see how it could be provided by Ivip.
> 
> Mobility between provider networks (eg. operators of different radio
> networks) could add tens or hundreds of billions of dollars of value
> to the Net and IP-centric cellphones, by enabling each one to have
> its own micronet / EID, no matter where it is in the world.
> 
> To do this, you need fast push of some kind, and since push to every
> ITR in the world (NERD) doesn't scale to these cellphone scenarios,
> the only scalable approach seems to be hybrid push-pull like APT or
> Ivip.  However APT currently does slow push via flooding the mapping
> data around the world in a new BGP instance.  That leaves Ivip or
> some other fast hybrid push-pull system.
> 
> Without mobility, I could imagine that maybe, one day, we might have
> 10^7 end-users who want number portability (I know people wince at
> this term, but that is what people quite reasonably want and
> arguably need) for their home and business networks.  Maybe 10^8 if
> it became the common way of running a business to have at least one
> IPv4 address which was genuinely stable, or with IPv6, a /64.
> 
> But without mobility for laptops/cellphones/video-players (whatever
> these things develop into), how could the 10^9 or 10^10 figures be
> credible?
> 
> In short, ALT or TRRP could handle unlimited numbers of EIDs, but
> since they can't provide mobility, the demand will never be more
> than a few tens of millions.
> 
> A few tens of millions of relatively static mapping information is
> easy for NERD or APT to handle, so the primary (only?) argument for
> ALT or TRRP goes away.  NERD or APT are better because the don't
> delay any initial packets.
> 
> But NERD can be improved by allowing some ITRs to be caching ITRs,
> querying a local query server wherever there is a full push ITR.  I
> suggested this series of improvements on 22 January:
> 
>   ALT + NERD is inelegant & inefficient, compared to APT or Ivip
>   http://psg.com/lists/rrg/2008/msg00176.html
> 
> No-one ever debated my argument in detail.
> 
> The first step of upgrading NERD makes it a hybrid push-pull system
> like APT or Ivip.  Then we make it fast push rather than slow, which
> enables the mapping data to be a single IP address, and removes the
> reachability and multihoming service restoration decision functions
> from the ITRs . . . and the system can support mobility and looks a
> lot more like Ivip.
> 
> While a hybrid push-pull system can scale larger than a pure push
> system, neither system copes well with end-users changing their
> mapping very frequently, *unless* they have to pay a small fee for
> each change.  That fee will naturally be set by market forces so it
> pays for as much of the push network as needs to be paid for by the
> end-users (ISPs will pay for the final stages as they run their own
> Replicators to fan the mapping data around inside their networks).
> 
> Then, the more efficient the global push system, the lower the
> prices and the more end-users will want to have micronets - and the
> more they will be happy to change their mapping.
> 
> The physical mobility of cellphones is an immensely valuable thing.
> 
> Perhaps it is an anomaly in Australia, but the cost of making a
> cell-phone typically exceeds the rate at which people can earn money
> before tax.  (There are many freebie and discount plans, but many
> folks need ordinary plans in which they are charged a cent a second.
>  That is USD$33 an hour.)
> 
> I reckon a global fast push system can be largely funded by a fee
> per update which in practical terms in general physically mobile use
> is a lot cheaper than what people are paying for cell-phone calls today.
> 
>  - 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