Hi Dennis, I don't think flapping routes will increase due to the assignments of PI space, as in the most cases ISP's are requesting those for customers and offers managed multihoming solutions. So announcing these routes into BGP is the responsibility of an ISP. Regards Marcus Ruchti COLT Telecom -----Ursprüngliche Nachricht----- Von: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] Im Auftrag von Dennis Lundström Gesendet: Donnerstag, 20. April 2006 16:25 An: Pekka Savola Cc: ppml@arin.net; address-policy-wg@ripe.net; global-v6@lists.apnic.net Betreff: Re: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive Hi Pekka. Totally agree with you there. At the moment as we have PI with IPv4, and I'll guess there will be lot's of fuzz dropping It. On the other hand. If PI allocations were no more, then the same people you nag about here would try to become their own ASN:s. And the percentage of peers running on cheap 'o pc-boxes would quite possibly increase. Resulting in that the problem with flapping routes would probably remain, or even get worse. So the problem is really. How do we regulate PI to only be an accepted solution for extreme cases? And still have a fair policy to those who really needs this feature. Best regards. --Dennis Lundström GippNET Pekka Savola wrote:
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.
************************************************************************************* The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way. The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security@colt.net and delete the message and any attachments without retaining any copies. Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses. No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party. Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.