[ppml] a modified proposal 2005-8

[Owen DeLong]

--On March 17, 2006 11:47:42 AM -0800 Tony Hain <alh-ietf at tndh.net> wrote:

> (Howard, W. Lee & bmanning below)
> Michael.Dillon wrote:
>> 
>> > From a policy point of view, we must remember that the
>> IPv6 address space is finite. At the same time it is intended
>> to be very big so that it is very hard to use up all of the
>> space. Any scheme which maps some locator, like GPS coordinates,
>> directly onto the IPv6 address space, is likely to result in
>> large amounts of unusable address space due to the fact that
>> most territory on the earth is covered by ocean or uninhabited
>> wilderness. Therefore, the only politically tenable scheme
>> would be one that uses a database. 
> 
> This presumption is still open for political debate. Yes there will be
> some waste. The question becomes 'is that waste worth the value it
> returns in terms of simplicity and isolation from long term political
> squabbles?'. If you choose a strict database model you are presuming that
> there is still some organization that has rights and authority to decide
> who gets how much. At the same time the implication is that the
> organization remains as it is today. An alternate outcome might be that
> the RIR community casts the 'control' model followed by a take over by
> the UN/ITU who could then say 'we didn't define it'. 
> 
And if you go with a strictly positional model, then, you assume that
all population density is equal.  The idea of a /128 per square foot
sounds great until you consider the possibility of a 100 story
office building with 10 floors of high-density colocation (45
1U servers per cabinet) and 90 floors of moderate to high density
office.

>> In fact, this type of
>> scheme is proven to work for interactive applications since
>> this is how phone number portability works.
> 
> While that model works for service provider controlled applications, it
> would be more effort to implement for P2P application models. The
> timeliness of global database updates would have to be better than dns,
> and there is always the 'trust' issue about who has access and rights to
> make the change. The problem of crossing the trust boundary should not be
> minimized.
> 
The timeliness of global updates only needs to be better than DNS if
the churn rate is higher.  If instead of changing the addresses,
we change indirect the addresses to one or more routing locators
through the same database, then, the routing locator updates don't
actually need to be all that timely since they will not change
often (where often is defined as a given record changing more
than once every 5 minutes or so).


>> 
>> Given that such mapping schemes are almost certain to
>> be based on a database, then there should be no scaling
>> problems.
> 
> Then why does it take so long for simple dns changes to propagate
> globally? Wouldn't that be due to an operational requirement specifically
> implemented to deal with scale? After all DNS is a distributed database.
> Or are you assuming that this is a central database which has scaling
> issues in another dimension? There are always scaling problems; it is
> just a matter of finding the lowest cost trade-off. 
> 
DNS changes with short TTLs propogate quite rapidly.  If I sent the
TTL on my DNS record to 60, then, generally speaking, (other than
buggy clients), I can depend on everyone getting the new version
within 120 seconds.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060317/07f8438a/attachment.sig>