Andrew Smith writes...
This would have one effect. ISP's would require any and all customers who have their own space to run BGP and use their own AS, therefore just sticking a variety of different labels on routes that were previously under the ISP's announcements.
Unless the customer has a larger network, /19 or shorter, they will face the same problem with prefix filters in certain networks like Sprint. Sure, this can be a problem, but the goal is to aggregate prefixes. If this won't encourage it, then it's a bad plan. But the goal still remains.
This point isn't even taking into account how absolutely real it is for a medium size ISP to have 3 /17s or 3 /18s or 3 /19s or 6 prefixes from /17 to /24.
They are taking up 15 prefixes in my route table, when they could aggregate their space by renumbering into a single /15 or /14 and take only one? If the high number of prefixes out there is NOT a problem, then say so. If that is the case, then Sprint has no justification for filtering the routes by prefix size.
Given that this would seriously impact the larger NSP's (how many /24's do you think Sprint, MCI, and UUNet) announce for non-BGP customers, how realistic do you view this proposal?
Us smaller ISPs are being required to constantly renumber our space just to get more space. So tell me what the boundary is where an ISP can grow past where they no longer are required to renumber space? We see "size bias" from Sprint in their filtering. Are we also seeing "size bias" in how ISPs are treated with respect to renumbering policies?
/* Beginning Rant */
Not to sound bitter, but the vast majority of the contributers to this list have gone from using engineering practices for the good of the net to using engineering practices to make it work, given the goals and limitations of corporate policy. Any other approach can't get the dollars behind it and compete with the corporate direction of "well if other providers are willing to limit their potential customer revenues by making this policy, we can just buy RSP-4's and get the customers they lose".
As it stands now, small ISPs are the ones with the potential to lose customers because of the existing "size bias" with respect to filters against long prefixes.
Our ideas and suggestions need to be both good for the net, and not vulnerable to someone out there flying in the face of it to make a buck. Sprint's filtering policies are one of the few filtering plans that was successfully imposed upon the net that actually stuck (read, significantly impacted a majority of us in dealing with inter-provider announcements). The only way they did make it stick and not cost them large amounts of revenue was to make exceptions for their own customers thereby removing the "good of the net" result and making it "good for Sprint".
You're being vague here. In on breath you are saying Sprint's policy is good, and then saying it is not good for the net, but only good for Sprint. Well, I can see how it is good for Sprint. With filters they can go cheap on router memory and CPU speed and save a few bucks, possibly charging less for their customers, and certainly making more profit. This, from a business standpoint, is certainly good for Sprint in the short term. But a small web provider business that was smart enough to implement their web services using shared IP addresses, instead of putting each web site on its own IP address, can do it in a /26 instead of a /19, but gets shafted by Sprint. Maybe you are suggesting that they hook up to Sprint and become and expection? Maybe I suggest that they blackhole all of Sprint instead.
Cabal-like engineering mandates may be damn good for the routers, but the dollars behind the routers are speaking much louder with each passing day. It is not only naive, but irresponsible to count on the technical "good of the network" arguments to continue to dismiss without question or compromise, business concerns, especially when such proposed and/or implimented methods cause complaints of hardship from paying customers which assuredly reach those who's chief concern is the satisfaction of the stockholders.
I agree there are concerns for router efficiency. But some other solution is needed aside from requiring everyone to get a /19 (which once everyone does, Sprint will raise the bar to /18 or /17 or some such level). There needs to be a solution where the small (whether because their business is small or because their engineering is wise) are treated equally to the large. I did say that at some level the number of prefixes might no longer need to be counted. Would Sprint be willing to allow the one largest prefix in the /29 to /20 range, per each AS, through, if the software provided a feature to automatically pick it out from the announcements for each AS, and just let all /19 and shorter through as they do now? That would increase the number of prefixes they have to deal with by some amount, while encouraging the smaller ISPs to keep their space well aggregated. It would still allow the large ISPs to flood the route space with excess numbers of prefixes, it which seems they want to be able to do while not allowing the smaller ones to do so. By all means, my idea is not ideal. But the existing situation is not, either, unless you are willing to give each of your multi-home customers a /19 block, whether then need that many addresses or not. Got any better ideas? I'd really like to see one that is better than the choices we have now. -- Phil Howard | stop3it9@s3p7a1m8.com stop2ads@no6where.com no7spam4@no5where.net phil | stop7it1@noplace7.com ads3suck@no4place.org stop9630@no7place.org at | stop0ads@nowhere4.com stop6137@s2p9a0m5.com no16ads2@anywhere.edu ipal | die6spam@anywhere.com ads8suck@dumb3ads.net no0way65@anyplace.com dot | stop5it7@s9p5a5m6.com no6spam3@spammer0.edu die2spam@spam5mer.com net | end1it62@no6where.edu end4it88@no7place.edu stop6609@no8where.net