Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Dean Willis <dean.willis@softarmor.com> Thu, 29 September 2011 21:25 UTC

Return-Path: <dean.willis@softarmor.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9E621F8DEE for <rai@ietfa.amsl.com>; Thu, 29 Sep 2011 14:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.013
X-Spam-Level:
X-Spam-Status: No, score=-103.013 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnM0lIQ8zVPw for <rai@ietfa.amsl.com>; Thu, 29 Sep 2011 14:25:19 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46D3421F8DE2 for <rai@ietf.org>; Thu, 29 Sep 2011 14:25:19 -0700 (PDT)
Received: by yic13 with SMTP id 13so1173550yic.31 for <rai@ietf.org>; Thu, 29 Sep 2011 14:28:11 -0700 (PDT)
Received: by 10.150.61.16 with SMTP id j16mr875216yba.309.1317331691135; Thu, 29 Sep 2011 14:28:11 -0700 (PDT)
Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id 38sm8127775anu.24.2011.09.29.14.28.09 (version=SSLv3 cipher=OTHER); Thu, 29 Sep 2011 14:28:10 -0700 (PDT)
Message-ID: <4E84E2E8.6000102@softarmor.com>
Date: Thu, 29 Sep 2011 16:28:08 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: rai@ietf.org
References: <CD5674C3CD99574EBA7432465FC13C1B222B1F590A@DC-US1MBEX4.global.avaya.com> <CAA62EE0.3B275%jason_livingood@cable.comcast.com> <38726EDA2109264987B45E29E758C4D6022C0F@MISOUT7MSGUSR9N.ITServices.sbc.com> <00ab01cc7d31$2cfa1c40$86ee54c0$@us> <4E820778.1070807@softarmor.com> <EDC0A1AE77C57744B664A310A0B23AE220CE44FF@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <D74629EC-D802-4A33-82AE-DA2A76EA5996@bbn.com> <4E82832E.3090600@nostrum.com> <F3561159-7AE5-46D7-8577-EB765FD84C51@acmepacket.com>
In-Reply-To: <F3561159-7AE5-46D7-8577-EB765FD84C51@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2011 21:25:20 -0000

On 9/29/11 11:16 AM, Hadriel Kaplan wrote:
>
> You kept saying "Million", but I think you mean "Billion". :)
>
> ITADs handle 4.3 _Billion_ numbers.

Yeah, my bad, probably, but the math was mostly right in my post on 9/27 
at 11:27PM. I did miscount the reclamation rate; at a 10% annaual 
reclamation rate, we could recycle 430 million addresses a year, not 4.2 
million.

4,294,967,296 ITADs if we count 0.

As I said, "But if we're issuing a hundred million a year, we've only 
got a 42 year window."

> While there are more than 4.3 Billion E.164 numbers in use, it's in
> the same ballpark... and it's also the same ballpark for number of
> devices on the Internet.
>
> In short: it's a crap-load.

But we live in a world with many, many loads of crap. Or KRAP, as the 
case may be...

The question: Is our KRAP-loader big enough? Inasmuch as I'm trying to 
sell my dump-truck because my front-end-loader isn't big enough to load 
it, it's the kind of thing I worry about.

Probably the worst-case scenario is that every single business in the 
world, living or dead, from now on will want an ITAD. The closest 
estimates I can find are that the world has between 200 million and one 
billion extant businesses (The US supposedly has 22 million). Let's call 
it 500M for giggles. Assume a churn of 10% a year, that's 50M new 
obsolete ITADs each year (and assuming no growth in the number of 
businesses). The 4.3B address space would be filled in something like 76 
years.

But if we recycle obsolete entries, we never run out (unless there is 
unforeseen growth and every new doghouse needs a SPID).

>
> And this really does make a difference for machines still today -
> there're still 32-bit CPU's/OS's out there. (and for some reason
> compilers/libraries still don't seem to handle 64-bit long longs very
> well)

This makes routing software for IPv6 very hard to write. We really need 
128-bit CPUs to become universal in order to assure the universal 
deployment of IPv6.

So, it looks like the ITAD space, with a policy of reclamation, will 
outlast both the 32-bit CPU and the technology-enhanced lifespans of 
those of us currently discussing it.

And it's pretty easy to add another 32 bits to the front of it later, 
since it's not sub-addressed. I'm guessing we'll have 64 bit CPUs in 
less than 76 years.

Or we could just remove the arbitrary bit-limit from the current 
registry, pad left with zeroes, and warn implementers that if they're 
using binary-integer representation on ITADs (instead of  string 
representation) that, somewhere in 50 years or so, they're going to need 
to use 64-bit long ints?


So can we just go with the ITAD already and get it done?



--
Dean