Re: [NIC-960209.1757] Routing Problem (fwd)
From: Robert Du Gaue <rdugaue@calweb.com> To: Network Registration Role Account <netreg@internic.net> cc: nanog@merit.edu, cidrd@IEPG.ORG, iepg@IEPG.ORG, iab@isi.edu, iesg@isi.edu, dennis.mcconnell@nolte.com, noc@pagesat.net, norman@pagesat.net
So kind of you to include so many lists. (:-{ I truncated the CC to the appropriate list for NA service providers.
How the hell can I be a successful ISP when first, I probably can not justify 64 blocks (and if I do Sprint may change it to 128 anyways!)
Let's think about this for a moment. How do you define "successful"? If you mean, you already have lots of customers signed up before you ask for your first block, then of course you won't have any problem justifying 64 or more C's. And you will be able to afford to run your own continental links to the various NAPs. I do not see how having no customers signed up qualifies as successful.
and second if the blocks I get are not routed through one of the MAJOR backbone proivders then they are useless to me and my end users!
On the other hand, are you saying you are "successful", but you are not running your own continental network? Why then, you must be connected to "one of the MAJOR" providers, correct? It only takes one. You get your addresses from them, not from the global pool. As an alternative, I have long advocated that you get your addresses from an Exchange, and that Exchange arrange for connectivity to the rest of the net. There is more than one such Exchange in your region.
Using old policies to justify not doing something against what is obviously discrimination against smaller ISPs does nothing to solve the problem.
I don't know what "old policy" you are referring to. The warning about small unaggregated routes is relatively new. Please be more specific. I cannot parsed your sentence. What specific problem are you complaining about, and what is _your_ solution? Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
On Sun, 11 Feb 1996, William Allen Simpson wrote:
From: Robert Du Gaue <rdugaue@calweb.com>
How the hell can I be a successful ISP when first, I probably can not justify 64 blocks (and if I do Sprint may change it to 128 anyways!)
Let's think about this for a moment. How do you define "successful"?
It's a Catch-22. To provide the multi-homed, reliable services that many successful providers offer their customers, you need your own IP space. If the InterNIC isn't handing out blocks of routable size, you can't exactly have the most flexibility with your links.
If you mean, you already have lots of customers signed up before you ask for your first block, then of course you won't have any problem justifying 64 or more C's. And you will be able to afford to run your own continental links to the various NAPs.
A good point, but I, as a customer, am looking for a provider which is stable already; I'm not going to sign up to a service which says "we'll become multi-homed and fully accessible just as soon as we get X customers". I've seen others sign up for services which promise this--you find they go down quickly because they tend to not meet the X customer line.
I do not see how having no customers signed up qualifies as successful.
You have to offer services that people want, with good quality, before you can expect many customers to sign up. If you need X customers before you can provide those services, then you end up in the Catch-22 loop again.
On the other hand, are you saying you are "successful", but you are not running your own continental network? Why then, you must be connected to "one of the MAJOR" providers, correct? It only takes one. You get your addresses from them, not from the global pool.
Not every ISP has the investment capital to immediately run high-speed links to every NAP in the nation. But, that aside, are your customers going to use your service if they know that the Y% of people on the net using SprintLink are going to be unable to reach your network? /cah
participants (2)
-
Craig A. Huegen -
William Allen Simpson