nanog mailing list archives
Re: [NIC-960209.1757] Routing Problem (fwd)
From: Sean Donelan <SEAN () SDG DRA COM>
Date: Sat, 17 Feb 1996 15:25:09 -0600 (CST)
Yes, so why not take you address space from you upstreem provider and yes, when you need to change it. We started with 1 /24 then, /23 then /19, all from Sprintlink. We then added a MCI connection and the Internic gave us a /18, then we got connected to a NAP, the NIC gave us one more /18. Yes, we had to renumber off the /24, /23, and are still working on the /19. The point is that the NIC has no idea how long you will be in business, or if you need the space at all. I am provding access to right now 10 ISP, that will be gone in a year, and have watch that many die so far.
Obviously you don't know the right people. While some startup ISP's get a /19. Other startup ISP's with no customers get a /14. And why renumber if you can get IANA to align an entire /8 before you even have customers? Perhaps there are some unpublished criteria being used to distinguished between these ISP's market projections. The published criteria don't seem to be sufficient to explain these dispararities. Since these allocations happened before these startup ISP companies had any customers, I don't understand what method for evaluating "effective utilization" would lead to these companies getting such large allocations. Other than relying on rosy engineering diagrams and optimistic market studies. The phase of the moon seems to be as good an explaination as any. The backing of a large cable or bell operating company isn't a good predictor of success. Yet these type of companies seem to be getting larger than average allocations for their ISP businesses before having any customers. Whatever happened to all those set-top boxes for interactive television? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
Current thread:
- Re: [NIC-960209.1757] Routing Problem (fwd), (continued)
- Re: [NIC-960209.1757] Routing Problem (fwd) Jonathan Heiliger (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Michael Dillon (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Jonathan Heiliger (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Paul Ferguson (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Jon Zeeff (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Dorian Kim (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) elliot (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Jon Zeeff (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Paul Ferguson (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) bmanning (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Paul Ferguson (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Kai (Feb 13)
- Re: [NIC-960209.1757] Routing Problem (fwd) Sean Donelan (Feb 17)
- Re: [NIC-960209.1757] Routing Problem (fwd) Walter O. Haas (Feb 20)
- Re: [NIC-960209.1757] Routing Problem (fwd) Scott Mace (Feb 20)
- Re: [NIC-960209.1757] Routing Problem (fwd) Dave Siegel (Feb 21)
- Re: [NIC-960209.1757] Routing Problem (fwd) Ehud Gavron (Feb 21)
- Re: [NIC-960209.1757] Routing Problem (fwd) Paul A Vixie (Feb 22)
- Re: [NIC-960209.1757] Routing Problem (fwd) Scott Mace (Feb 21)
- Re: [NIC-960209.1757] Routing Problem (fwd) Scott Mace (Feb 20)