16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-site enterprises and PI]

Owen DeLong owen at delong.com
Wed Dec 1 07:31:33 UTC 2004



--On Wednesday, December 1, 2004 8:36 +0200 Pekka Savola 
<pekkas at netcore.fi> wrote:

> On Tue, 30 Nov 2004, Owen DeLong wrote:
>>> if the prices were one or two orders of magnitude higher, that might be
>>> true.  That's way too cheap as it is.  10000$ upfront, 5000$/yr for
>>> renewal might scare away who _really_ don't need them.  Have the RIRs
>>> donate the markup to ISOC or whoever and we're done.
>>>
>> So, you think that global resources should be allocated solely on the
>> basis of wealth.  Well... I don't subscribe to that theory, so, on this
>> we will certainly have to agree to disagree.
>
> No.  I'm just saying that they need to distributed based on who _really_
> needs them and based on who is sufficiently relevant in the global scale
> of things that cannot use some other mechanisms which do not require
> presence at the global routing table.
>
Well... You said that your intended criteria for determining need was
to make them pay $10,000 up front and $5,000/year for renewal.  If I'm
Ford Motor Company or Donald Trump, then, that's easy.  On the other hand,
if I'm a rural ISP in the american south west, multihomed to 5 or 6
upstream providers and a number of local peers churning in annual
profits in the neighborhood of $100,000 to $500,000, then, that's an
awful lot of money just to get a single integer.

> Unfortunately, putting a sufficient cost to the resources is one of the
> few ways to measure real need.  If you have real need, and you're big
> enough to be globally relevant, you _can_ afford e.g. 5k/yr.
>
Except that it has a number of problems:

	1.	It has no association with need.
	2.	We already see that some of the worst abusing organizations
		in general are also some of the best funded.
	3.	It penalizes a number of organizations with real need and
		poor funding.
	4.	It is an arbitrary and capricious attack on a significant
		portion of the community.

> The point is to make PI/ASN-based multihoming sufficiently unattractive
> to those who should be using local instead of global means.
>
Herein lies the major difference between your position and mine.  You seem
to have this mystical idea of some clear cut distinction between "Should be
able to use PI/ASN based multihoming" and "Should be using PA space and
local instead of global means" (whatever that actually means).

My questions are:

	1.	How do you determine the distinction between these two
		classes? (An actual rule that can be applied fairly
		and consistently by RIR staff when considering resource
		requests)

	2.	Why do you think that criteria is a valid criteria?
		(I can't really refute it until I know what it is.)

> For example, my own consulting company certainly (currently with a /24)
> falls under that category.. sure, it would be nice to have PI and BGP for
> multihoming -- but I don't have any delusions of grandeour that my site
> would be worth it in the global scale of things.  Just because it might
> be easiest way for _me_ doesn't mean it's the way multihoming should be
> done because of the impacts on the rest of the world.

My focus isn't easiest, but, frankly, it's far more important as far as I
am concerned to more people in Europe to be able to reliably reach my site
for my consulting company (and other purposes hosted there) than to be able
to reach WalMart.

Again, I'll be interested to see what your actual criteria for making this
determination are, but, I suspect we will not agree about what they should
be, and, that we will, in the end, have to agree to disagree about who 
should
be in the position to make the decision of whether a given organization
is worthy of PI and dynamic multihoming.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041130/e1440292/attachment.sig>


More information about the NANOG mailing list