Sprint violations (setting space aside for slow-start allocations)
nmw at haven.ios.com
Thu Sep 21 21:11:29 UTC 1995
> Good points. You also join the registries in making
>one of the two very persuasive arguments in favour of
>relaxing (perhaps some, perhaps all) of 220.127.116.11/8 by
>one bit, to allow in /19s.
Not necessarily. Allow prefixes longer than /18 in areas of space where
no allocations have taken place, and then only to make sure that the
NICs have pools of space they can use for slow-start allocations.
> Slow-start is a good idea, and we have the RIPE /19
>legacy to prove it. Now we need to look at whether this
>can be done with /18s without exhausting IPv4 too soon,
>as there are some real concerns about doubling the maximum
>number of prefixes many routers will see.
Yes, but a fast ramping slow-start policy should make it possible to
avoid unnecessary allocations or allocation of too many long prefixes.
Perhaps a formula can be agreed upon for slow-start allocations that
uses certain heuristics to determine when to end or ramp up slow-start
for a given applicant. Unfortunately there is no easy way for a registry
to make sure an applicant is actually using existing allocations well
enough. One heuristic I propose be used, among others, is to consider
wether the applicant is multi-homed or has entered into contracts that
will make it multi-homed, the reason being that for multi-homed,
regional ASes it is far easier to deal with large allocations than small
allocations. I speak from experience. For me it was hard to internally
allocate a /20 in an aggregatable manner, but a /18 and a /16 were far
easier to handle in such a way as to allow that AS to take advantage of
its multiple paths to the net and yet announce only [relatively] short
> I also see no problem about working out case-by-case
>arrangements for putting holes into our filters in the
>future, taking everybody's various costs into consideration.
Ah, but if inconsistent space allocations or utilizations force many
holes into your filters, then your filters become hard to manage, and
then turn around time for handling special cases that require you add
holes to your filters increases.
Which is why I'm proposing having a pool for allocating /21s separate
from a pool for allocating /20s separate from a pool for allocating
/19s, etc.. Aggregation of /20s in the /20 allocation pool should be
allowed (i.e. filters should allow prefixes shorter than /20 in the /20
pool), but NICs should not allocate /19s in the /20 pool (though they
should consider reserving /19s in the /20 pool, allocating only the
first halves to slow-start customers). And so on. This policy should
simplify filter writing and result in more consistent allocation and
utilization of IPv4 address space, thus causing fewer special cases.
If some pools are exhausted, new ones can be created in the 206 to 239
range, or perhaps by then Class A subnets will be generally usable, or
perhaps IPv6 will have taken the world :^)
More information about the NANOG