CIDR allocation question

Daniel Karrenberg Daniel.Karrenberg at ripe.net
Mon Apr 11 08:25:15 UTC 1994


Folks,

here is something I wrote some time ago on a very related subject.
The last paragraph actually answers the question: To my mind it is
quite OK to "reserve" a small amount of address space by rounding up.
The emphasis here is on *small* in absolute terms. 

Enjoy

Daniel



CIDR Assignment Strategy


Previously the RIPE NCC has recommended IRs to reserve some address
space contiguous to assigned address space for future expansion.
The reasoning was that this would further aggregation and keep the
routing table sizes down in the long term, while being slightly
inefficient on address space usage in the short term.

However experience has shown that the address space usage problems
created by those reservations outweigh the possible aggregation
benefits.

If a block of equal size to the one actually assigned is reserved,
address space usage is halved at the expense of doubled routing
table size. Relatively speaking this looks like a good tradeoff. In
absolute terms however substantial amounts of address space are
traded in for 1 (in words: one) additional CIDR route. If no reser-
vation were made at all and more address space is needed then
another non-contiguous block of appropriate size can always be
assigned. Since there are now two blocks these can be aggregated
into two routes instead of the one which would have resulted if a
suitable reservation had been made. Note that this small absolute
gain can only be realised if the reserved space indeed fits the
need.

The reserved space not only decreases address space usage but also
creates fragmentation of the address space which makes it difficult
to find block of appropriate size for new requests.

Considering this it does not make sense to reserve anything but very
small amounts of address space or unused parts of CIDR blocks. Thus
the current recommendation is to reserve only address space that is
needed to "round" the requested space to a suitable block boundary.






More information about the NANOG mailing list