past vs future use

[Stephen Sprunk]

At 18:19 29-06-97 +0100, you wrote:
>> That't the normal way for an ISP to "grow up"...but what about ISP's that
>> start out with deep pockets?  Say you just sold a long distance company or
>> string of video rental stores and decide to start up a regional ISP with
>> multiple connections to the net on day 1, etc.  What if you decide instead
>> to start up a new backbone company that plans to sell connectivity to
>> ISP's?  Do you sell connections to small handful of customers telling them
>> you'll be renumbering them in a few weeks?
>
>  Exactly!  I think that Stephen's model above is approiate for some
>rookies in the ISP business.  I am not sure whom on this list said this,
>but the real trick in starting up an ISP is not having to renumber.

Unless you have exceedingly deep pockets (which the majority of garage ISPs
starting up do not), it is not likely you will be able to avoid renumbering.

If you are going to be starting a regional backbone, you will probably
immediately satisfy the requirements for (at least) a /19.  Get sufficient
committments from your customers that you will be able to SWIP 80% of a /19
immediately, and you should be able to get it.  Note that your customers
either need to SWIP 80% of their allocations or directly use 25%
immediately and 50% within one year.

>The "Stephen senerio", just above is a poor one and as you say sure wouldn't
>apply to a startup with reasonable resources and my response to his
>post.

Please don't name it after me, as I didn't come up with it (and if things
were up to me I'd do it very differently).  Hmmm, let's call it RFC 2050 or
"Slow Start".

>It seems obvious to me, and you it seems as well, that either
>Stephen has never done any startup ISP buisness, or/and has little
>idea as to how to plan well.  No offense, Stephen.  >;)

I have indeed been in the startup ISP business.  Again, I don't endorse the
model I presented in any way; I was merely clarifying the currently
expected procedure since many people seem to be unclear.


Stephen