[ppml] Just say *NO* to PI space -- or how to make it less destructive
Pekka Savola
pekkas at netcore.fi
Thu Apr 20 09:48:30 EDT 2006
Hi,
I don't support PI space to end-sites. We have to get rid of the
notion that a random end-site has any business whatsoever in mucking
with the global routing tables, either by making it much larger than
need be or by polluting it with needless dynamicity.
Example of the latter: deploying inbound traffic engineering
adjustment solutions which result in thousands of daily flaps in the
advertisements, as shown by Huston's analysis.
We have way too much trouble with clueless ISPs to also add (or
continue to add) end-sites to the mix...
....
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.
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.
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.
3. assignments from a separate address block, set aside for PI. To
ease strict "assignment-size only" filtering of these blocks.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
More information about the ARIN-PPML
mailing list