In general, is it better to have you IP space scattered amongst a lot of different /24's /25's and /26's or would it be better to collect everything into a large /19 or /18, when going to BGP4? I would think the latter. If so, would anyone know why it is that the backbone providers are so resistant to giving out blocks to do this? Could it be because they won't be able to do anything with the small pieces that get returned and those will end up going to waste because they are so fragmented? Or perhaps they don't even have procedures in place to do anything with returned address space, yet? -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
I would think the latter. If so, would anyone know why it is that the backbone providers are so resistant to giving out blocks to do this?
If backbone operators do not efficiently allocate IP space to their downstream customers then the next time they need additional IP space they will not be able to get any. Everyone in the food chain has to operate under the same policies of justifying IP space based on need and using the space efficiently. There is more info on this at http://www.arin.net and in particular you should have a look through the recommended reading section especially any documents relating to CIDR. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
Michael Dillon writes...
I would think the latter. If so, would anyone know why it is that the backbone providers are so resistant to giving out blocks to do this?
If backbone operators do not efficiently allocate IP space to their downstream customers then the next time they need additional IP space they will not be able to get any. Everyone in the food chain has to operate under the same policies of justifying IP space based on need and using the space efficiently. There is more info on this at http://www.arin.net and in particular you should have a look through the recommended reading section especially any documents relating to CIDR.
It seems that efficiency is measured only in terms of numbers of IP addresses and disregards numbers of routes. We are at a point that we can pretty much nearly fill a /19 and will be past that point by the end of the year. Beyond that, I would think that when we need to keep coming back for address space, we would do it in increments of /19. How much of the routing space is filled with networks smaller than /19 that are part of an ASN that has enough other smaller networks to renumber into a single /19. I'm wondering if the policies are not being counter productive due to the apparently opposing nature of IP space vs route space (e.g. the one where people have to take more IP space to be routed, because of route filters, because of too many routes, because IP space is so fragmented, because IP space needs to be conserved, because everyone needs to get more IP space, becayse of route filtering, because of so many routes, because ...). I was given some other mailing lists for dealing with those issues by someone. I'll be subscribing there. In the mean time, especially to help put topics on the correct mailing list (if on-topic posts are to be another goal) can someone post an informatory posting that lists ALL the mailing lists (preferrably with a brief summary of topic/purpose) that would be of interest to ALL the aspects of network provider business and operation? Or is this listed on a web page? If not, I'll offer to host just such a web page if I can get a pretty much complete list (I'll even write HTML to get it going). But I'm sure most everyone here has some access to some web space somewhere. -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
We are at a point that we can pretty much nearly fill a /19 and will be past that point by the end of the year. Beyond that, I would think that when we need to keep coming back for address space, we would do it in increments of /19.
The problem is that although you know your goals and you also know that you WILL reach your goals, there are other companies out there with wildly inflated goals that will never even come close to reaching them. The registry folks have to cut through the bullshit and try to avoid delegating space to companies who don't really need the space and will never use it.
I'm wondering if the policies are not being counter productive due to the apparently opposing nature of IP space vs route space (e.g. the one where people have to take more IP space to be routed, because of route filters, because of too many routes, because IP space is so fragmented, because IP space needs to be conserved, because everyone needs to get more IP space, becayse of route filtering, because of so many routes, because ...).
You are quite right, it's a tricky balancing act. And many of us do believe that the right balance has not been struck yet and that allocation policies need to be modified a bit to accomodate the current realities.
I was given some other mailing lists for dealing with those issues by someone. I'll be subscribing there.
Hopefully the NAIPR list was one of them because that is where the new policies will likely be hashed out. Send a subscribe message to naipr-request@arin.net and before posting anything, review the background material at http://www.arin.net including the list archives. At ISPCON 3 weeks ago, Kim Hubbard announced that 50 organizations had already applied for ARIN membership.
Or is this listed on a web page? If not, I'll offer to host just such a web page if I can get a pretty much complete list (I'll even write HTML to get it going). But I'm sure most everyone here has some access to some web space somewhere.
I think that the ISP info pages hosted at http://www.nanog.org already has a pretty good collection of pointers to mailing lists. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
Michael, Michael Dillon wrote:
We are at a point that we can pretty much nearly fill a /19 and will be past that point by the end of the year. Beyond that, I would think that when we need to keep coming back for address space, we would do it in increments of /19.
The problem is that although you know your goals and you also know that you WILL reach your goals, there are other companies out there with wildly inflated goals that will never even come close to reaching them. The registry folks have to cut through the bullshit and try to avoid delegating space to companies who don't really need the space and will never use it.
Well if there were reasonable paramaters set, determining weather or not the requests for allocations would be reasonable. RFC 2050 is insuficient for this perpose, yet is the backdrop or primary document that NAPIR is using as a guideline. Bad policy.
I'm wondering if the policies are not being counter productive due to the apparently opposing nature of IP space vs route space (e.g. the one where people have to take more IP space to be routed, because of route filters, because of too many routes, because IP space is so fragmented, because IP space needs to be conserved, because everyone needs to get more IP space, becayse of route filtering, because of so many routes, because ...).
You are quite right, it's a tricky balancing act. And many of us do believe that the right balance has not been struck yet and that allocation policies need to be modified a bit to accomodate the current realities.
A bit! That is an understatment at best.
I was given some other mailing lists for dealing with those issues by someone. I'll be subscribing there.
Hopefully the NAIPR list was one of them because that is where the new policies will likely be hashed out. Send a subscribe message to naipr-request@arin.net and before posting anything, review the background material at http://www.arin.net including the list archives. At ISPCON 3 weeks ago, Kim Hubbard announced that 50 organizations had already applied for ARIN membership.
Yep. And this announcment is premature until some of the allocation pollicies are better worked out.
Or is this listed on a web page? If not, I'll offer to host just such a web page if I can get a pretty much complete list (I'll even write HTML to get it going). But I'm sure most everyone here has some access to some web space somewhere.
I think that the ISP info pages hosted at http://www.nanog.org already has a pretty good collection of pointers to mailing lists.
******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net
"The People You Know. The People You Trust." ********************************************************
Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com
The problem is that although you know your goals and you also know that you WILL reach your goals, there are other companies out there with wildly inflated goals that will never even come close to reaching them. The registry folks have to cut through the bullshit and try to avoid delegating space to companies who don't really need the space and will never use it.
One thing the registries do to help avoid that problem is allocate half a block (say, half an /18) and reserve the rest. If the rest is not claimed later, it is reassigned. Maybe that should be even more the standard practice. There is nothing to lose in allocating in the order .0, .128, .64, .192, .32, .96, .160, .224 instead of .0, .32, .64, .96, .128, .160, .192, .224. -Phil
On Sep 9, Phil Howard <phil@charon.milepost.com> wrote:
In general, is it better to have you IP space scattered amongst a lot of different /24's /25's and /26's or would it be better to collect everything into a large /19 or /18, when going to BGP4?
I would think the latter. If so, would anyone know why it is that the backbone providers are so resistant to giving out blocks to do this? Could it be because they won't be able to do anything with the small pieces that get returned and those will end up going to waste because they are so fragmented? Or perhaps they don't even have procedures in place to do anything with returned address space, yet?
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.) 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. The main failing in the plan was that I got assigned to a different project before the renumbering was completed. 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. ********************************************************* J.D. Falk voice: +1-415-482-2840 Supervisor, Network Operations fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." *********************************************************
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 +-------------------------------------------------------+
On Sep 9, Phil Howard <phil@charon.milepost.com> wrote:
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.
That's a good point...in theory, those small holes could eventually add up to bigger blocks, and the process would continue using recycled instead of newly allocated space, but that won't always be able to happen.
We need to make sure the upstream provider is given an incentive to get the downstream provider to aggregate.
You get into sticky territory there. *grin*
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 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.
Interesting idea...not sure if it would be adoped by a large group of providers, but interesting nonetheless.
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.
That wasn't us (the company I worked for at the time) who cut off the reverse DNS -- that was AGIS. Check the NANOG archives for posts regarding how I felt about that at the time. ********************************************************* J.D. Falk voice: +1-415-482-2840 Supervisor, Network Operations fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." *********************************************************
participants (5)
-
J.D. Falk -
Jeff Williams -
Michael Dillon -
Phil Howard -
Phillip Vandry