|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Renumbering for better aggregation (was Re: too many routes)
J.D. Falk writes... > Okay, this is somewhat operational (more policy, but it's > something backbone operators need to think about) -- how > many of y'all actually /do/ have a policy in place for > when your downstream customers want to reaggregate? For > that matter, how many of you have had to think about it > before? (I'm not looking for a show of hands, of course, > just some interesting discussion.) One of the effect of a downstream provider renumbering to aggregate IP space, is that they will be handing space back upstream. That's fragmented space and now it makes the upstream provider _look_ less efficient because they have to still go get /19's or larger from the NIC, but now have all these small holes. We need to make sure the upstream provider is given an incentive to get the downstream provider to aggregate. > Personally, I dealt with that somewhat in a previous job, > where we were returning space originally allocated to us > by Net99 (yup, it's a common story), and therefore forcing > just about all of our long-time customers to renumber. It > was not fun, but I tried real hard to make it go well. > > So, I figured out which of our customers were in a good > position to be renumbered into a better aggregate block as > long as they were going to have to renumber anyway, and > assigned new addresses accordingly. What do you mean? If everyone has to renumber, what does it matter which block they are renumbered into, as long as they move into one that is a fully routable block? Of course, once concern is if those doing the filtering of smaller than the /19 today might change to doing smaller than /18 tomorrow. When the range 64-126 opens up as CIDR, and if all that is chopped into pure /19 (which would be a dumb move, IMHO) that would mean 129,024 more potential routes, quadrupling the situation we have now. So just to sustain the route table size if that happened, filtering would have to be at /18 or maybe even /17. However 64-126 gets chopped up, it most certainly will be leading to many more routes. Here's my idea. This would require some new software by Cisco, Ascend, the gated folks, etc: Implement the ability to do filtering based on the total number of routes of a given size per ASN. The way this would work is that an array of small 8 bit (mayber smaller) numbers would be kept per ASN. There would be 8 numbers corresponding to network sizes /17 to /24. When a new route of a given size comes in, it's corresponding size number is incremented. If the total for that size in that ASN exceeds a maximum value configured for that size, then the new route is filtered out. I believe an effect of this approach would be to allow both small and large networks to have a finite number of routes, with encouragement to renumber as they grow larger in size, to keep the number of routes from getting out of hand. The configured limit should be 1 for all sizes up to the size where blocks cannot be gotten even if they are justified (large than /16 I might suspect) or nearly that size. Maybe /24 to /18 should be 1 and /19 to /17 be 2. I just came up with this idea, so it hasn't been refined. Do shoot it down if it deserves to be shot down, but realize that any flaws haven't had a chance yet to be resolved, and that maybe this could work if fine tuned. > The main failing in the plan was that I got assigned to a > different project before the renumbering was completed. Sounds like a Dilbert strip to me. > My guess would be that it'd be a little more difficult if > you or your customer were trying to reaggregate without the > impetus that your existing addresses didn't have valid > reverse DNS any more, and were gonna be forcibly reclaimed > in a few months. You cut things off like DNS, and the customer, having to renumber anyway, will renumber to another ISP. But among the realistic effects of not following the renumbering would be declining performance due to poor reachability, not participating in multi-homing, asymmetric routing, etc. -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
|