This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
- Previous message (by thread): [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
- Next message (by thread): [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nils Ketelsen
nils at druecke.strg-alt-entf.org
Thu Apr 20 16:48:57 CEST 2006
On Thu, Apr 20, 2006 at 04:48:30PM +0300, Pekka Savola wrote: > 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... So there shouldn't be PI for ISPs either, I guess. Only to Peering points (one per RIR). Would make the routing table so much cleaner. Completely impractical? Why is it possible for end sites then? > 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. I strongly hope so. > 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. Where does this money go? Do you really want an Sub-PI-sales-market popping up? There will be startups buying a /32 and then selling /48s and /64s for a discount rate. There will be demand for anyone to route these nets. > 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. This will also happen with /48 and /32. I am convinced the only solution to avoid this is only handing out /128s. Everything else will be taken apart. > 3. assignments from a separate address block, set aside for PI. To > ease strict "assignment-size only" filtering of these blocks. Won't take long until the first ISPs fall. And then more and more will have to. There is no strong community, apart from those customers with lots-o-money. Nils -- Will trade links for food. [geklaut bei www.userfriendly.org]
- Previous message (by thread): [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
- Next message (by thread): [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]