One can also accomplish this with a lot less thought by simply making each
allocation be as far away from all other allocations as possible within a
given CIDR block. For example, allocate xx.xx.0/24 first, xx.xx.128/24
second, xx.xx.64/24 third, xx.xx.192/24 fourth, xx.xx.32/24 fifth, etc.

If one only allocates 50% of the space using that kind of an algorithm,
then every single prefix can be doubled to become a /23. If one only
allocates 25% or the space, then every single prefix can be quadrupled to
become a /22.

Of course, we'd have to convince the authorities that 25% to 50%
utilization of a CIDR block in this manner is a good thing so we could get
new /16 or bigger blocks...

Which is the entire problem. We go through about 512 Class C's in roughly
6 weeks (at least last time I checked). The InterNIC won't give out more
CIDR blocks until we have utilized 90% or more of our blocks (read that

We get a /15 prefix from the NIC, and in 6 weeks, it's 100% assigned, and
within 8 weeks of the initial assignment, 95% of the entire block is routing.

What I would rather do, is chop everything into little bits by relative
location to a NAP, and summarize a huge CIDR block with a specific MED (for
those that will take it). Then, it doesn't matter how message my core
get's with /22's, everything looks clean from the outside.