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. 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. 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. | If Sprint is not doing a good job of aggregating its announcements, | filter them, eventually they'll get around to aggregating everything | they can. There certainly is some aggregation that should be done downstream from Sprint. We try to encourage people to aggregate what they can aggregate, but some outside pressure to do so probably would help... Sean. P.S.: | So how about agreeing on pools of address space for small allocations? I think you found a good topic!
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
Sean Doran <smd@icp.net> writes: Slow-start is a good idea, and we have the RIPE /19 legacy to prove it.
It is not legacy. We are using it in 193/8 and 194/8 and currently we do not intend to do differently in any new /8 we might start. /18 is just too much of an allocation for a garage with a couple of <your favourite modem hub>. We cannot and will not refuse to allocate address space to such garages until someone comes up with a *resonable* policy of what is an eligible garage. I can understand that some sugest that a reasonable policy is to require connections to a at least two <major transit provider>, but I postulate that <major transit provider> can never be defined in a rasonable way. So please define which garages shall be eligible for an allocation and get the RIPE community to agree. Mind this is easier than the Internet community. Folks: Here is an issue!!!!
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.
My experience tells me that it is too big. We are not doing slow start long enough however to quantify that.
| So how about agreeing on pools of address space for small allocations? I think you found a good topic!
Check out ripe-127. Daniel
Sean Doran <smd@icp.net> writes: Slow-start is a good idea, and we have the RIPE /19 legacy to prove it.
It is not legacy. We are using it in 193/8 and 194/8 and currently we do not intend to do differently in any new /8 we might start. /18 is just too much of an allocation for a garage with a couple of <your favourite modem hub>. We cannot and will not refuse to allocate address space to such garages until someone comes up with a *resonable* policy of what is an eligible garage. I can understand that some sugest that a reasonable policy is to require connections to a at least two <major transit provider>, but I postulate that <major transit provider> can never be defined in a rasonable way.
So please define which garages shall be eligible for an allocation and get the RIPE community to agree. Mind this is easier than the Internet community.
There are probably a number of ways, but none hard enoughfor a determined garage to get around. Charging for delegations should work better; hey, InterNIC has just decided it's ok for it to charge for domain names, why not IP address space?! But how would you set your prices?? What's more costly to the net? Large unused blocks assigned to folk who won't use them efficiently? Or lots of small, hard to route blocks that cost large providers money? Perhaps instead of charging a fee for address delegations the registries might require a security deposit. This deposit would be given back when the applicant gives enough proof of using its address space well enough (e.g. customer lists with phone numbers, addresses, and IP address space delegated to them). A fee could then be charged to the applicant for the registries' troubles verifying the applicant's claims. The fee would be relative to the amount of work the registry would have to do to check out the applicant. The deposit could be a sum that is related to the size of the block in question (e.g. $100 for a class C, $2000 for a /20, $5,000 for a /19, etc...). When an applicant has proven reliably that it can effeciently use its delegations (i.e. when the applicant has proven it's not a garage business), then the whole process might be relaxed or done away with for that applicant. Anyways, if InterNIC told noone of its plans to charge for domain names, perhaps they'll soon drop a bomb shell about their plans to charge for address space delegation; as I mention above, it's hard to price address space delegations when there are two large costs: one proportional to the size of the delegation, and on inversely proportional to the same. [I don't know that the InterNIC told noone of its plans to charge for domain name registration and use; but apparently they didn't tell NANOG, which is important enough.]
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.
My experience tells me that it is too big. We are not doing slow start long enough however to quantify that.
Which is why I'm proposing that some pools of space be set aside for slow-start allocations of /21s, /20s and /19s.
| So how about agreeing on pools of address space for small allocations? I think you found a good topic!
Check out ripe-127.
I will, but remember, if we're to agree on setting aside pools of space for slow-start, then it should be done in a consistent manner, so that filters can be written a bit more easily. This means setting aside, say, 207/8 for slow-start pools, and then breaking up that /8 into smaller blocks for slow-start allocation of each of the three or four sizes used in slow-start (/21, /20, /19) and then delegating sub-blocks of those sub-blocks to the various registries; if a /8 is too small for this, then two or thre /8s should be set aside for it. Registries and providers must agree to some extent on the above methinks.
Daniel
Nick
Nick Williams <nmw@haven.ios.com> writes:
There are probably a number of ways, but none hard enoughfor a determined garage to get around. Charging for delegations should work better;
Just for the record: The RIPE NCC is charging for registration services for quite some time now. We do not charge for addresses, but for the service. The charges are annual subscritions per local registry dependent on a self-determined size of the registry. For details see ftp://ftp.ripe.net/ripe/new-registry/billing.txt. This has indeed worked to help aggregation as newly starting garages tend to obtain address space from their provider rather than subscribe to the RIPE NCC's registry services.
I will, but remember, if we're to agree on setting aside pools of space for slow-start, then it should be done in a consistent manner, so that filters can be written a bit more easily. This means setting aside, say, 207/8 for slow-start pools, and then breaking up that /8 into smaller blocks for slow-start allocation of each of the three or four sizes used in slow-start (/21, /20, /19) and then delegating sub-blocks of those sub-blocks to the various registries; if a /8 is too small for this, then two or thre /8s should be set aside for it. Registries and providers must agree to some extent on the above methinks.
193/8 minimum allocation is /19 194/8 minimum allocation is /19 Daniel
participants (3)
-
Daniel Karrenberg -
Nick Williams -
Sean Doran