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

[Scott Leibrand]

On 04/20/06 at 4:48pm +0300, Pekka Savola <pekkas at netcore.fi> wrote:

> Now, from practical point of view, it seems there is strong "need" for
> PI, and it might be a PI policy of some kind might actually get
> through.

Very true.  I'd even s/might/will/.

> If so, the policy should be such that it minimizes the bad effects of
> PI and encourages people to use other solutions if those are viable
> for them (unfortunately, the only way to achieve that appears to be
> $$$$), in particular (in the rough order of importance):
>
>   1. Each assignment must be accompanied by a recurring fee (at least
> 1000-2000 USD/EUR a year, preferably 5000+).  This is peanuts
> (compared to other costs) to anyone who actually needs this
> multihoming solution.  However, this ensures at least some minimum
> usage barrier ("those who don't really need this can use different
> multihoming solutions"), and recovery of the resources back to RIR
> after the company has gone bankrupt or no longer needs the addresses.
> If you don't know where to put the extra money, donate it to ISOC or
> something.

As has been discussed at ARIN, this is a good way to get the government to
declare the RIR a monopoly engaging in anticompetitive behavior.  I for
one don't want that.

Now if you think ISPs should start charging end sites for the privilege
of running BGP, that might fly.  ISPs in the DFZ are bearing the costs of
maintaining the extra routes*, so they can justify a per-route charge, and
they actually have contracts with their customers, so they can collect.
(* Yes, other end sites in the DFZ also bear those costs, but since they
contribute routes to the table as well, and can sometimes switch to
default-only BGP, I'd argue that DFZ ISPs are the ones stuck "holding the
bag" of routing table growth.)

>   2. one-size-fits-all assignments, period.  You get a /48 or /32 (I
> don't have much preference here), but you must not be able to justify
> for larger space.  This is to avoid the organization from getting a
> larger block and chopping it into smaller pieces and polluting the
> global routing table with more specifics which would get past prefix
> length filters.

With the current ARIN policy proposal, you'd get a /48, with a /44
reserved for growth.  Would you advocate giving everyone a /44 up front
instead?  Or something else?  I don't have too much preference here, FWIW.

>   3. assignments from a separate address block, set aside for PI.  To
> ease strict "assignment-size only" filtering of these blocks.

This is already a part of 2005-1, and has been a part (expressed or
implied) of every other PI proposal I've seen.

-Scott