Re: Request for Comments on a topological address block for N. Calif.
| Right now, larger ISPs aren't getting large | blocks, and they are allocating things in non-contiguous non-growable | blocks, neither of which is good. Nothing is being done to organize | topological assignments at all, which is seriously not good. If some registry were to give me a /8, I would carve that up right now into ten chunks (one per SprintLink POP as of a couple weeks from now) and subdivide those to take into account possible growth into new cities before the current allocations to end users were exhausted, and allow for unexpectedly heavy or unexpectedly light allocations to customers from those prefixes. However, those ten chunks would be the only individual prefixes announced out of AS1239 to the rest of the world, in the entire /8. Some parts of the world would even see the /8 and not the ten individual per-POP prefixes. This is what is done now with smaller chunks of address space: Block Name IP Addresses ------------------------------------------------------------------------------- East 198.67.0/17 198.69/16 199.0/16 204.117/16 204.180/16 204.183/16 204.215/16 205.160/15 205.244/15 206.105/16 West 198.68/16 199.2/16 204.94/16 204.119/16 204.182/16 204.212/16 205.162/15 206.107.128/17 South 199.1/16 204.96/16 204.181/16 204.214/16 204.251/16 205.240/15 206.61.0/17 206.104/16 North 198.70/16 199.3/16 204.95/16 204.120/16 204.248/16 205.242/15 206.106/17 NorthEast 204.97/16 204.213/16 204.249/16 205.246/15 206.106.128/17 SouthWest 204.118/16 204.250/16 206.61.128/17 206.107.0/17 ICM-Atlantic 198.67.128/17 NYSERNet 204.168/16 205.232/16 and with a best-fit algorithm for allocation to customers (all done in nifty software written by Vadim Antonov), we do pretty well in terms of site-aggregation and keeping lots of subnets of these out of our backbones. Unfortunately, the allocations we've been getting haven't been very big, and so we end up having to introduce things as long as 17 bits to the world, where we might have only had to announce /16s and /15s with a larger delegation from a registry. Block Name Total Free Used Free Blocks Cs Cs 1 2 4 8 16 32 64 128 256 512 1024 -------------------------------------------------------------------------- East 2863 233 91% 1 1 1 1 1 West 2176 51 97% 1 1 1 1 South 2176 47 97% 1 1 1 1 1 North 1920 218 88% 1 1 1 1 1 NorthEast 1408 211 85% 1 1 1 1 1 SouthWest 768 173 77% 1 1 1 1 1 NYSERNet 512 129 74% 1 1 ICM-Atlantic 128 122 4% 1 1 1 1 1 -------------------------------------------------------------------------- TOTAL 11951 1184 90% 6 5 2 5 4 5 4 5 So, beacause we are clever and do a mix of provider-based and geography-based allocation (but it is a mix of both, with an emphasis on the provider part), we end up with blocks that are starving, but a single huge allocation that isn't full enough to have a new large allocation done by the registry. Sean.
| Right now, larger ISPs aren't getting large | blocks, and they are allocating things in non-contiguous non-growable | blocks, neither of which is good. Nothing is being done to organize | topological assignments at all, which is seriously not good.
If some registry were to give me a /8, I would carve that up right now into ten chunks (one per SprintLink POP as of a couple weeks from now) and subdivide those to take into account possible growth into new cities before the current allocations to end users were exhausted, and allow for unexpectedly heavy or unexpectedly light allocations to customers from those prefixes.
However, those ten chunks would be the only individual prefixes announced out of AS1239 to the rest of the world, in the entire /8.
Some parts of the world would even see the /8 and not the ten individual per-POP prefixes.
This is what is done now with smaller chunks of address space:
....
Sean.
I expect that if Sprintlink were to propose a rational plan to renumber and -return- the older delegations that they would be provided with a large, single block that Sean could pursuade Sprintlink to carve up in the fashion that he indicated. It would go a long way in reducing the size of the global routing system. --bill
I expect that if Sprintlink were to propose a rational plan to renumber and -return- the older delegations that they would be provided with a large, single block that Sean could pursuade Sprintlink to carve up in the fashion that he indicated. Methinks that this is backwards. Sprintlink clearly has a rational plan. Obviously they cannot possibly return an older delegation until they can get more address space. It would go a long way in reducing the size of the global routing I count 45 prefixes. IMHO, someone needs to be following RIPE's guidelines and should be assigning shorter prefixes to Sprint on a per-block basis. Tony
Sean, Currently Sprint receives the largest sized CIDR block the InterNIC is permitted to allocate. If you have a requirement for an even larger block than please submit the justification and I will be glad to pass it onto the IANA for approval. Kim Hubbard InterNIC Registry
Unfortunately, the allocations we've been getting haven't been very big, and so we end up having to introduce things as long as 17 bits to the world, where we might have only had to announce /16s and /15s with a larger delegation from a registry.
Block Name Total Free Used Free Blocks Cs Cs 1 2 4 8 16 32 64 128 256 512 1024 -------------------------------------------------------------------------- East 2863 233 91% 1 1 1 1 1 West 2176 51 97% 1 1 1 1 South 2176 47 97% 1 1 1 1 1 North 1920 218 88% 1 1 1 1 1 NorthEast 1408 211 85% 1 1 1 1 1 SouthWest 768 173 77% 1 1 1 1 1 NYSERNet 512 129 74% 1 1 ICM-Atlantic 128 122 4% 1 1 1 1 1 -------------------------------------------------------------------------- TOTAL 11951 1184 90% 6 5 2 5 4 5 4 5
So, beacause we are clever and do a mix of provider-based and geography-based allocation (but it is a mix of both, with an emphasis on the provider part), we end up with blocks that are starving, but a single huge allocation that isn't full enough to have a new large allocation done by the registry.
Sean.
participants (4)
-
bmanning＠ISI.EDU -
Kim Hubbard -
Sean Doran -
Tony Li