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 [EMAIL PROTECTED] 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
