At 08:22 AM 8/18/95 IST, Hank Nussbacher wrote:
>On Thu, 17 Aug 1995 14:57:40 -0700 (PDT) Bill said:
>>>
>>> I assign /22s to ISPs. When they use them up I give them another /22.
>>> Private companies that show a need for a /24 are assigned a /24.
>>>
>>
>>Ah. here is the rub. When you ISP buddies come back, you should ask
>>them to return the origianal /22 for a /20. That way, the total size
>>of the routing system stays the same!
>
>Great idea. Know ANYONE who does that? The best I can do is give them a
>/20 (in addition to the original /22) if their growth warrants it.
>
Hank,
I like your idea.
At first, you suggested giving the ISP a string of /22s. This could end
up having a possibly large number of prefixes assigned to the same ISP.
Then Bill suggested growth by requiring an exchange of an old /22 for a
new /20. (And the next time requiring an exchange of the new /20 for a
newer /18.) This could end up requiring this ISP's customers to renumber
more frequently than the customers of its competitors, all due to a possibly
quite reasonable judgement call by the registry.
Your lastest idea provides an interesting compromise. If the ISP exhausts
the initial /22, give them a new /20 and let them keep the /22. This does
not achieve Bill's goal of a *constant* number of prefixes, but it does do
the following:
<> it keeps the growth in the ISP's prefixes logarithmic as a function of its
customer base (not as good as constant, but better than linear),
<> it allows the registry to grant as big or as little an initial prefix length
without biasing the market in favor of one ISP over another, and
<> it doesn't require as aggressive a rate of renumbering by customers as Bill's
stricter notion.
This is probably what many registries do now.
The trouble with either your original (string of /22s) idea or Bills
(strict exchange with constant number of prefixes) idea is that it puts too
much weight on the registry's decision on how big a prefix to grant to a new
ISP or an existing ISP in a rapidly growing market. If the registry grants
too short a prefix, then address space is wasted. If the registry grants
too long a prefix, then:
[] under your original idea, routing table entries grow linearly, and
[] under Bill's idea, the ISP's customers have to renumber too soon.
By growing logarithmically, the registry doesn't have as much hanging on its
initial prefix length decision, and the competitive field is more level.
Two footnotes:
** as another person noted, you can optimize by leaving gaps around your initial
prefix assignment and sometimes collapse blocks of a single ISP, and
** you could still require renumbering, though a little less aggressively than
Bill does, by requiring the initial /22 to be returned, say, when the ISP's
4th prefix (a /16) is granted. At any rate, the 'renumbering cloud' hanging
over the head of new customers should not depend on their choice of ISP.
-- Guy
