Sprint violations (setting space aside for slow-start allocations)

Nick Williams nmw at haven.ios.com
Fri Sep 22 15:22:02 UTC 1995

>  > Sean Doran <smd at 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.



More information about the NANOG mailing list