William Herrin herrin-nanog at dirtside.com
Sat Aug 15 10:29:46 CDT 2009

```On Sat, Aug 15, 2009 at 2:34 AM, Randy Bush<randy at psg.com> wrote:
>> 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 at 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
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.

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 at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

```