|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Sprint violations (setting space aside for slow-start allocations)
>Nick - > 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 206.0.0.0/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 prefixes. > 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 :^) > Sean. Nick
|