AW: [address-policy-wg] Just say *NO* to PI space -- or how to make it less destructive
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.
Hi, On Fri, 21 Apr 2006, Ruchti, Marcus wrote:
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.
First off: there has been some discussion whether 200K routes is a problem or not. If the numbers stayed at that level (how can we ensure that?), that wouldn't be a huge problem. Bigger one is dynamicity. Huston's study indicated that there are folks whose BGP announcements flap (due to TE) intentionally 1000's of times a day. Multiply that by the number of sites (and add sBGP or friends to the stew) and you may start thinking that your DFZ router might have better things to do than process that cruft. And now responding to your specific comment, I do not agree with "So announcing these routes into BGP is the responsibility of an ISP." -- the _sites_ decide how they want to advertise; the biggest decision of the ISP is whether it does BGP flap damping for these or not. Virtually all multihomers use their own AS number -- agree? If you agree, I guess what you're saying is that in most cases the ISPs set up the AS numbers and the multihoming at customer's equipment, customer's premises or colo, customer's AS number, etc.? Indeed, I believe in significant number of cases, a consultant (whether from one of the ISPs or an outsider -- I'd personally prefer an outsider as (s)he wouldn't have a conflict of interest) sets up the multihoming setup. But that doesn't preclude said consultants, other consultants, or local network engineering staff from adjusting the set-up later on. If one of the ISPs had sole management of the setup, that would seem somewhat at odds with the provider independence principle. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Tue, Apr 25, 2006 at 09:10:43AM +0300, Pekka Savola wrote:
First off: there has been some discussion whether 200K routes is a problem or not. If the numbers stayed at that level (how can we ensure that?), that wouldn't be a huge problem. Bigger one is
Well, as most business models are based on the concept of everlasting growth, I assume most ISPs should not try to ensure stagnation there. Though they could (just stop accepting new customers, but I believe you will get into trouble with some of the more commercial oriented departments then).
dynamicity. Huston's study indicated that there are folks whose BGP announcements flap (due to TE) intentionally 1000's of times a day. Multiply that by the number of sites (and add sBGP or friends to the stew) and you may start thinking that your DFZ router might have better things to do than process that cruft.
Well using the max value as the average is a little unusual for a business calculation, but okay, you are expecting the worst case. Good for you, but most customers have no interest in paying for an ISP, that is always ready for the worst case. There is a market segment, though, so thats fine.
I do not agree with "So announcing these routes into BGP is the responsibility of an ISP." -- the _sites_ decide how they want to advertise; the biggest decision of the ISP is whether it does BGP flap damping for these or not.
ACK.
Virtually all multihomers use their own AS number -- agree? If you agree, I guess what you're saying is that in most cases the ISPs set up the AS numbers and the multihoming at customer's equipment, customer's premises or colo, customer's AS number, etc.?
NACK. In many cases they do it themselves or have externals doing it. Those managing the equipment are mostly not the same delivering the lines, though sometimes they are. Thats at least the perspective I got from customers we have set up interconnections with. Thats mainly large enterprise market, small customers usually do not get connectivity to our network (as they do not need it). Nils
On Tue, Apr 25, 2006 at 08:37:39AM +0200, Nils Ketelsen wrote:
Thats at least the perspective I got from customers we have set up interconnections with. Thats mainly large enterprise market, small customers usually do not get connectivity to our network (as they do not need it).
Do we have stats on what percentage of people with PI allocations for IPv4 have it to avoid renumbering (i.e. to change provider much more easily), and how many in addition use it for multihoming? I know of small enterprises that are not interested in multihoming so much (they have good reliability from their ISPs) but who want to be able to react to better connectivity deals (e.g. in a case I saw recently move from 15K pa. to 8K pa. for a service, without losing that advantage with renumbering costs). Just curious. -- Tim/::1
On 4/24/06, Pekka Savola <pekkas@netcore.fi> wrote:
Hi,
On Fri, 21 Apr 2006, Ruchti, Marcus wrote:
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.
First off: there has been some discussion whether 200K routes is a problem or not. If the numbers stayed at that level (how can we ensure that?), that wouldn't be a huge problem. Bigger one is dynamicity. Huston's study indicated that there are folks whose BGP announcements flap (due to TE) intentionally 1000's of times a day. Multiply that by the number of sites (and add sBGP or friends to the stew) and you may start thinking that your DFZ router might have better things to do than process that cruft.
BGP flap dampening is already well understood for limiting the impact of flapping routes on your CPU, if that's a concern; it has no bearing on address allocation policy decisionmaking. And configuring dampening is up to each _recipient_ network, and is not something that should be codified into an address allocation policy, which is targetted at the _originating_ network. Let's stick to the topic at hand, which is how to craft a useful address allocation policy which allows for provider indepent address allocations, while at the same time showing good stewardship of the overall address pool. The policy cannot allow itself to be shaped by the least-capable routers, or we'll be chaining ourselves to the past,unable to make adequate forward progress so long as there's any network out there that's still running old hardware that's unwilling to upgrade. I agree we need to be reasonable--but please, let's not "dumb down" the v6 internet just because some people aren't willing to step up to the plate and upgrade their routers when needed. Provider independence is here already, period. It's too late to try to put the horse back in the barn--what we *can* try to do is craft a well-thought-out policy 'bridle' for it, and then let it start running (to abuse a metaphor horribly). Trying to stop provider independent addressing in IPv6 is simply another way of saying 'IPv6 addressing is broken, let's just stick with IPv4 instead' -- because that's what the practical outcome is. Any addressing scheme that tries to deny the need for provider independent addressing is less capable for businesses than what they have today in the IPv4 world, and will therefore not be used. So. Given that PI allocations are going to happen in IPv6 just as they have in IPv4, let's put all the rest of the grumbling about it aside, acknowledge the reality of the situation, and simply agree that as a starting point, issuing a /48 out of a reserved /44 to each multi-homed, non-transit-service-providing network which applies and demonstrates it has met the requirements for being multi-homed and obtaining its own AS, is reasonable--if adjustments to the policy are needed, they can be applied in the future as needed, just as we've done in the IPv4 world. I *do* agree that stipulating that only the largest possible aggregate assigned to a given AS *should be* announced by the AS is a reasonable addition to the policy to help encourage aggregation, and prevent stupid routing mistakes like this: * 198.144.160.0/20 195.66.224.82 0 4513 174 6983 8051 i * 198.144.172.0 195.66.224.82 0 4513 701 8051 i (real-world example pulled from route-views; the /24 is announced by the same originating AS, but is not connected to or directly reachable from the network that announces the /20 aggregate, as was pointed out by the end-site when their /24 more specific was filtered out at one point.) That is, if you have discontiguous networks, they should each obtain their own AS, and should pay the registration fees for that AS and the associated IP aggregate which it will announce. I don't see why the discussion is dragging out for so long. This isn't rocket science. Let's just nail the policy down, and move on with more productive work. Matt
Hi, (removing ppml and global-v6, taking this to the address policy wg list) On Tue, Apr 25, 2006 at 11:56:27AM -0700, Matthew Petach wrote:
I don't see why the discussion is dragging out for so long. This isn't rocket science. Let's just nail the policy down, and move on with more productive work.
As soon as anyone can come up with a policy draft that we all can *agree* upon, then we can go ahead. What I'm not seeing in your mail is a specific proposal on the rules that should be used in deciding "who will get an address block / routing table slot, and who will not" - and that's the main question here, no matter how the resulting address bits are called. Gert Doering -- RIPE APWG co-chair -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
participants (6)
-
Gert Doering -
Matthew Petach -
Nils Ketelsen -
Pekka Savola -
Ruchti, Marcus -
Tim Chown