On Sat, Aug 15, 2009 at 2:34 AM, Randy Bush<randy@psg.com> wrote:
I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp.
the swamp preceeded cidr
Randy, Correct. Disaggregate classful blocks overwhelming the routers was part of the problem. CIDR was part of the solution. That's what I said.
and, if you had a bit of simple arithmetic clue, you would realize that, unless you are prescient, you will always run out of some classes before others.
Of course. That's what reserves are for: a resource you move into place after you discover where it's needed. Whether its a reserve force in a military action, the reserve slack in your unix disk partition or the emergency fund in your bank account, this is a long solved problem in human endeavor. On Sat, Aug 15, 2009 at 3:03 AM, Nathan Ward<nanog@daork.net> wrote:
Read about how sparse allocation/binary chop stuff works. You get the same amount of routes in your IGP table (or less) but it's much more flexible.
Sparse allocation says that you maximize the potential expansion of an allocation by simply changing its netmask. That means your first two allocations go at 0% and 50% (allowing either to expand to half your space), your next two go at 25% and 75% (allowing any to expand to 1/4th of your space) and so on. Let's try some of Randy's simple arithmetic on sparse allocation. Start with: /32 Sparsely allocate 200 /56's Total remaining space: in excess of /33. In fact, you haven't consumed a single /48. Expandability by altering the netmask: to /40 Largest allocation still possible: only /40 See the problem? You've eaten 8 bits of capability long before you've consumed even half of your space. In fact, when you do consume close to half your space, the largest remaining block is a meager /47 and your expandability of all those /56's is only to /47. Software developers very rarely fragment a resource pool on purpose because of precisely this problem. On the other hand, consider an escalating pools (aka classful) scenario: /32 broken into four pools: /34 for the /60 pool /34 for the /56 pool /34 for the /48 and larger pool /34 for the reserve pool Assume that: 90% of allocations are /60 9.9% are /56 0.1% are /48 or larger 100,000 allocations into this strategy you haven't tapped the reserve pool and it's probably still possible for you to allocate a /35 from the /48+ pool. And the price for this structure is that a small number of the registrants will have more than 1 but less than 4 routes (one each of /60, /56 and /48+) as opposed to sparse allocation improves the probability that they'll have only 1 route. On the other hand, 100,000 allocations in to the fore-mentioned sparse allocation, while there's a higher probability of each user having only 1 route, the largest users will need many more than 1. You've used a total of /42, maybe a little more of your space but your largest remaining free space is only /48. So if you need to accomodate a /44 customer, you'll have to give him 16 discontiguous /48's. Sparse is a farce. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004