[ppml] Just say *NO* to PI space -- or how to make it less destructive

[Pekka Savola]

On Thu, 20 Apr 2006, Stephen Sprunk wrote:
> I think that the multihoming requirement will be enough to keep the 
> number of assignments reasonable; if you look at the actual number 
> of non-transit ASNs in the v4 table, it's not all that large.  If we 
> assume one PIv6 prefix per non-transit ASN, which is the goal, we're 
> looking at under 10k routes from the ARIN region.

(Actually, the number is somewhere between 15k and 20k but that's 
beside the point.)

The upper limit is around the number of AS numbers, and if it's 
expanded to 32 bits, at least I start to feel uncomforable... "Umm.. 
are we sure 64K folks playing around at DFZ isn't enough??? we want 4B 
instead...????"

Remember, it's easy and cheap to have a multihoming setup with two DSL 
lines...

>> That is, ARIN has every right to require, for example, that everyone
>> getting a prefix is (for instance) a member of ARIN, and charging for
>> the membership should be OK.
>
> I'd want a lawyer to sign off on it.  You're talking about 
> deliberately charging an excessive fee to make it more difficult for 
> smaller companies to compete with larger ones.  That has the 
> appearance of an industry cartel creating artificial barriers to 
> lock their smaller competitors out of the market, and the FTC 
> generally doesn't like that.

Come on, arguing that 1K or even 5K is an "excessive fee" for PI 
prefixes in the context of reliable multihoming setup and services 
provided seems a bit absurd.  I'd agree that if the charge was 100K 
per year, this could be considered locking out smaller competitors, 
but (say) 1K is nothing -- that's less than 100 bucks a month!

You might even consider a payment like 1K or 2K fair: small ISPs which 
get exactly the same resources have to pay such in their membership 
fees.  Obviously the end-sites should pay at least the same if they 
consume the same resources..

>> setting a foundation for multihoming research to actually SOLVE this
>> problem, etc.etc.
>
> In theory, we already have a group tasked with that: the IETF.  Are you 
> proposing that RIRs start developing protocols outside the IETF?  Or funding 
> people to work full-time in the IETF on problems pertinent to RIRs?  Again, 
> this is a slippery slope and distracts from the RIRs' purpose.

I said 'research', not 'engineering'.  The IETF isn't the right vessel 
for research, though IETF could maybe be consulted on it.

>> I wouldn't object to reserving a /44 just in case, but make no
>> provisions (at this point) for applying more.  If someone needs more
>> than /48, it needs to justify another one, and get a separate /48
>> (with its own reserved /44).
>
> So instead of giving an org a /47, which _could_ be advertised as a single 
> route, you'd prefer to give them two /48s, which _must_ be advertised as two 
> routes?  That seems to increase routing table pollution, not reduce it.

Not necessarily.  Doing so would hopefully ensure that it'll be *more* 
difficult to justify for more than a /48 especially if you have to pay 
for the extra too (hence less pollution).  I.e., we'd need to figure 
out we have sufficiently strict criteria.

> Also, what's the point of reserving a /44, or worse multiple /44s, if we're 
> only going to let people use a /48?  That seems to defeat the purpose of 
> having a reserved block.

As I said, I wouldn't object to reserving a /44 under those 
conditions, but I wouldn't require reservation either.  One reason for 
reserving is that we could have the option of changing the policy 
later if we become wiser (or dumber) and decide that maybe we'll want 
to be able to deal out aggregatable chunks after all, regardless of 
the more specific crap that's filling the routing tables right now.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings