Mailing List Archive

Re: [NIC-960209.1757] Routing Problem (fwd)
> Regional Internet registries have no control over the routing policies
> of any ISP. The IANA has instructed the Internet registries not to
> assign IP addresses based on any ISP's particular routing policy, rather
> on specific criteria including utilization efficiency. An organization
> will be assigned the number of IP addresses it can justify. If this
> number is not fully routable, that is an issue that should be taken up
> with the ISP(s) concerned.

This is just one big cop-out from the organization that CONTROLS who gets
IP blocks. 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!) 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! You are basically allowing one company to dicate policy and growth
of the Internet. It's totally unfair to smaller ISPs and sets an ugly
presedence as to just how the 'net will grow if you allow each
organization to define their own rules that affect the Internet in
general. Using old policies to justify not doing something against what
is obviously discrimination against smaller ISPs does nothing to solve
the problem.
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
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
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
> 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
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
> No circularity about it. First, you need customers. Second, if you
> already have enough customers, you get your own IP space.
>
> Until then, you get a small chunk out of somebody else's bigger IP space.

Yeah right. You try that with a growing business. Then when you finally
get enough users and corporate customers to 'justify' your own 64block and
then give them the news that their entire networks will now need to be
reconfigured how do you think they'll react. If I was that big, the amount
of money it would cost me and my end-users would not be trivial.
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
> From: "Craig A. Huegen" <c-huegen@quad.quadrunner.com>
> 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.
>
No circularity about it. First, you need customers. Second, if you
already have enough customers, you get your own IP space.

Until then, you get a small chunk out of somebody else's bigger IP space.

Them's the current rules. Now, as I noted in my earlier message, I have
long advocated that _NOBODY_ gets their own address space, and they
_only_ get addresses through the Exchanges where they are connected.

But, the rest of the IETF didn't go along with that idea. IPvB for
sure, someday.


> 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.
>
So have I. That's another good reason not to give a chunk to such a
provider in the first place.


> 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.
>
What's the problem? If you are small, you compete with the other little
folks. Demonstrate your quality.

You had better not falsely advertise that you are large. Good way to
get sued for breach of contract.


> Not every ISP has the investment capital to immediately run high-speed
> links to every NAP in the nation.

There seems to be this misconception -- that there is some _right_ to
make money off the Internet without much capital investment.

If they cannot meet the barrier to entry, then they deserve to go out of
business.


> 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?
>
I hope not.

Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
> From: "Craig A. Huegen" <c-huegen@quad.quadrunner.com>
> 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.
>
No circularity about it. First, you need customers. Second, if you
already have enough customers, you get your own IP space.

Until then, you get a small chunk out of somebody else's bigger IP space.

Them's the current rules. Now, as I noted in my earlier message, I have
long advocated that _NOBODY_ gets their own address space, and they
_only_ get addresses through the Exchanges where they are connected.

But, the rest of the IETF didn't go along with that idea. IPvB for
sure, someday.


> 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.
>
So have I. That's another good reason not to give a chunk to such a
provider in the first place.


> 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.
>
What's the problem? If you are small, you compete with the other little
folks. Demonstrate your quality.

You had better not falsely advertise that you are large. Good way to
get sued for breach of contract.


> Not every ISP has the investment capital to immediately run high-speed
> links to every NAP in the nation.

There seems to be this misconception -- that there is some _right_ to
make money off the Internet without much capital investment.

If they cannot meet the barrier to entry, then they deserve to go out of
business.


> 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?
>
I hope not.

Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
> From: "Craig A. Huegen" <c-huegen@quad.quadrunner.com>
> 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.
>
No circularity about it. First, you need customers. Second, if you
already have enough customers, you get your own IP space.

Until then, you get a small chunk out of somebody else's bigger IP space.

Them's the current rules. Now, as I noted in my earlier message, I have
long advocated that _NOBODY_ gets their own address space, and they
_only_ get addresses through the Exchanges where they are connected.

But, the rest of the IETF didn't go along with that idea. IPvB for
sure, someday.


> 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.
>
So have I. That's another good reason not to give a chunk to such a
provider in the first place.


> 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.
>
What's the problem? If you are small, you compete with the other little
folks. Demonstrate your quality.

You had better not falsely advertise that you are large. Good way to
get sued for breach of contract.


> Not every ISP has the investment capital to immediately run high-speed
> links to every NAP in the nation.

There seems to be this misconception -- that there is some _right_ to
make money off the Internet without much capital investment.

If they cannot meet the barrier to entry, then they deserve to go out of
business.


> 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?
>
I hope not.

Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
At 11:01 PM 2/11/96 -0800, Robert Du Gaue wrote:

>> No circularity about it. First, you need customers. Second, if you
>> already have enough customers, you get your own IP space.
>>
>> Until then, you get a small chunk out of somebody else's bigger IP space.
>
>Yeah right. You try that with a growing business. Then when you finally
>get enough users and corporate customers to 'justify' your own 64block and
>then give them the news that their entire networks will now need to be
>reconfigured how do you think they'll react. If I was that big, the amount
>of money it would cost me and my end-users would not be trivial.
>

Creating a consortium [akin to the NAP model] of small ISP's could
easily resolve this problem, if all address space allocated to each
ISP was contiguous and could be aggregated to a larger prefix.

This has been suggested on numerous occasions.

- paul
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
On Sun, 11 Feb 1996, Robert Du Gaue wrote:

> > No circularity about it. First, you need customers. Second, if you
> > already have enough customers, you get your own IP space.
> >
> > Until then, you get a small chunk out of somebody else's bigger IP space.
>
> Yeah right. You try that with a growing business. Then when you finally
> get enough users and corporate customers to 'justify' your own 64block and
> then give them the news that their entire networks will now need to be
> reconfigured how do you think they'll react. If I was that big, the amount
> of money it would cost me and my end-users would not be trivial.

I had posted this ridicularity long time ago. As long as the Internic is
not legally controlled, there will be no help. It is still a community of
individuals running the show, without any legal supervision, nor any way
of legal recourse.

Mike



>
>

----------------------------------------------------------
IDT
Michael F. Nittmann ---------
Senior Network Architect \ /
(201) 928 4456 -------
(201) 928 1888 FAX \ /
mn@tremere.ios.com ---
V
IOS
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
On Mon, 12 Feb 1996, Paul Ferguson wrote:

> Creating a consortium [akin to the NAP model] of small ISP's could
> easily resolve this problem, if all address space allocated to each
> ISP was contiguous and could be aggregated to a larger prefix.
>
> This has been suggested on numerous occasions.

It's not only been suggested, but I believe it's been somewhat
implemented. :) Back in September '94, Chris Alan (Electriciti) and a few
others came up with an idea called PCH -- Packet Clearing House.

The primary concept was, as you suggested, connect a bunch of small ISPs
together using shared resources and address space and peer with the "big
boyz." Unfortunately I haven't been involved with it lately, so hopefully
someone that has can share if it was successful or not.


-jh-
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
> On Mon, 12 Feb 1996, Paul Ferguson wrote:
>
> > Creating a consortium [akin to the NAP model] of small ISP's could
> > easily resolve this problem, if all address space allocated to each
> > ISP was contiguous and could be aggregated to a larger prefix.
> >
> > This has been suggested on numerous occasions.
>
> It's not only been suggested, but I believe it's been somewhat
> implemented. :) Back in September '94, Chris Alan (Electriciti) and a few
> others came up with an idea called PCH -- Packet Clearing House.
>
> The primary concept was, as you suggested, connect a bunch of small ISPs
> together using shared resources and address space and peer with the "big
> boyz." Unfortunately I haven't been involved with it lately, so hopefully
> someone that has can share if it was successful or not.
>
>
> -jh-
>
>
The unfortunate requirement of such scheme to work is that
all address space allocated to the small ISP's has to be contiquous so that it
could be aggregated to a larger prefix under an autonomous system.
Given the completely arbitrary manner adopted by the Internic's
address allocation policy, (eg. 4 C's to ISP A, skip a few C's, 8 C's
to ISP B where A and B can be 4,000 miles apart) it is safe to assume
that the small chunks of C class addresses are geographically
dispersed throughout the States with many holes still unassigned or
unaccounted for. If you are talking about swamp, this is it.
However, a survey for how those chunks of address got broken up into
many different places perhaps can help in the direction of finding
such solution. If these small IP pieces can be grouped together
according to their geographic locations, there is chance that some
broken chunks may be pieced together to form large enough piece by
pure luck. If such solution exists, I am sure someone would be
interested in forming such regional consortiums to help salvage the once lost
IP addresses.


SC

SC
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
Simon,

That's what CIDR is all about; the geographical allocation of
addresses/prefixes at the point of Internet connectivity for the
purposes of aggregation. If there is no sanity in address allocation,
we cannot solve the problem.

- paul

At 01:15 AM 2/13/96 +0000, Simon Chan wrote:

>The unfortunate requirement of such scheme to work is that
>all address space allocated to the small ISP's has to be contiquous so that it
>could be aggregated to a larger prefix under an autonomous system.
>Given the completely arbitrary manner adopted by the Internic's
>address allocation policy, (eg. 4 C's to ISP A, skip a few C's, 8 C's
>to ISP B where A and B can be 4,000 miles apart) it is safe to assume
>that the small chunks of C class addresses are geographically
>dispersed throughout the States with many holes still unassigned or
>unaccounted for. If you are talking about swamp, this is it.
>However, a survey for how those chunks of address got broken up into
>many different places perhaps can help in the direction of finding
>such solution. If these small IP pieces can be grouped together
>according to their geographic locations, there is chance that some
>broken chunks may be pieced together to form large enough piece by
>pure luck. If such solution exists, I am sure someone would be
>interested in forming such regional consortiums to help salvage the once lost
>IP addresses.
>
>
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
> purposes of aggregation. If there is no sanity in address allocation,
> we cannot solve the problem.

Let's not forget that the problem is poor router/protocol design and that
it can be solved. CIDR is a band-aid.
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
At 12:18 PM 2/13/96 -0500, Jon Zeeff wrote:

>
>> purposes of aggregation. If there is no sanity in address allocation,
>> we cannot solve the problem.
>
>Let's not forget that the problem is poor router/protocol design and that
>it can be solved. CIDR is a band-aid.
>

CIDR is a hell of a lot more than a band-aid. It extends the life of
IP v4 for an indiscriminate amount of time, and while v6 may be just
around the corner [according to some sources], the same type of CIDR
mechanisms will still be needed.

Let's not be naive.

- paul
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
On Tue, 13 Feb 1996, Jon Zeeff wrote:

> > purposes of aggregation. If there is no sanity in address allocation,
> > we cannot solve the problem.
>
> Let's not forget that the problem is poor router/protocol design and that
> it can be solved. CIDR is a band-aid.

Jon, I've been waiting for you to solve it. So when can we see the final
product? ;)

-dorian
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
>
> At 12:18 PM 2/13/96 -0500, Jon Zeeff wrote:
> >
> >Let's not forget that the problem is poor router/protocol design and that
> >it can be solved. CIDR is a band-aid.
> >
To which Paul responds....
>
> CIDR is a hell of a lot more than a band-aid. It extends the life of
> IP v4 for an indiscriminate amount of time, and while v6 may be just
indeterminate <-- Intended?
> around the corner [according to some sources], the same type of CIDR
> mechanisms will still be needed.
>

Heck of a BandAid... like a heart transplant.
Now if we could just get brain transplants.... :)

--bill
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
Jon,

>CIDR is a band-aid.

No. CIDR is the way it *should* have been done.

elliot
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
At 10:54 AM 2/13/96 -0800, bmanning@ISI.EDU wrote:


>>
>> CIDR is a hell of a lot more than a band-aid. It extends the life of
>> IP v4 for an indiscriminate amount of time, and while v6 may be just
> indeterminate <-- Intended?

Okay. Busted. :-)


>> around the corner [according to some sources], the same type of CIDR
>> mechanisms will still be needed.
>>
>
> Heck of a BandAid... like a heart transplant.
> Now if we could just get brain transplants.... :)
>
>--bill
>

What would we do with them if we had them?

- paul
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
On Tue, 13 Feb 1996, Simon Chan wrote:

> unaccounted for. If you are talking about swamp, this is it.
> However, a survey for how those chunks of address got broken up into
> many different places perhaps can help in the direction of finding
> such solution. If these small IP pieces can be grouped together
> according to their geographic locations, there is chance that some
> broken chunks may be pieced together to form large enough piece by
> pure luck. If such solution exists, I am sure someone would be
> interested in forming such regional consortiums to help salvage the once lost
> IP addresses.

I don't believe it requires "pure luck." I would hope that a group of
individuals would be able to convince the InterNIC into delegating a /16,
in return for either an equal amount of smaller CIDR blocks or somewhere
in the neighborhood. If some of those smaller delegations happened to be
continguous, the InterNIC would then have the responsibility and option of
turning them into a larger block or simply re-delegating them out to new
organizations at their discretion.

Small providers are the ones that tend to have the smaller CIDR blocks
(/18 and above). If a number of these organizations were to "join"
together using an exchange point mechanism, with multiple long-haul
carriers connecting (e.g. NSPs) to a single point, you could achieve a
good level of aggregation.

For example, rather than the "Internet," having to deal with 8, /19
announcements, the rest of the world would see a single /16 announcement.

Wow, so we just do this in a few hundred places and you've lowered the
overall routing table by 8 * N(hundred). The main problem, as we all
know, is this isn't a stable marketplace. Not only is there fierce
competition for staff, but also for customers. Why would a number of
small providers want join together?


-jh-
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
Sprint's filtering of routes based on prefix-length has made the popular
press: Communications Week International, Oct.20,1995 (as far as I can
tell from the website).
Please take a look at:

http://techweb.cmp.com/techweb/cwi/current/153newssprint.html

The article unfortunately quotes me completely out of context: I was
never asked by the correspondent in question (Christy Hudgins-Bonafield),
nor informed that I would be quoted, or things would have been portrayed
a little different, as I cannot remember having uttered words
that could be interpreted as

"Schlichting said Sprint's action disrupted an international conference of
600 government and civilian participants in Kazakhstan late last month."

I am somewhat upset that it took using the new big brother tool
'http://altavista.digital.com' to find this reference , today. Needless to
say, it came up with other interesting digital footprints of my past.


Small fact sheet:

- BelCom was a client of a Sprint reseller at the time, and was not
victim of Sean's policy, but WOULD have been , if we had been a non-Sprint-
connected network at the time

- connectivity was impaired by not having an entry of the network (a /22)
in the routing registries (who was responsible for this remains unclear,
people at ANS and the Sprint INSC were ultimately helpful with this issue)

- the conference was a great success, the real-IP connectivity was "The"
killer at the conference. Indeed it was so successful, that we decided
to present the Internet at the regional Oil&Gas show the week after,
with DEC's support and contributions (which shall not go umnmentioned here)

Note, that at the time I had full justification for an independent network
number block, as the plan was to multi-home said network in both Moscow
and New York, with growth expections beyond rationality (confirmed by success
and follow-up inquieries resulting from the shows).

BelCom (net worth: $25M) has been decapitated by Comsat Corp. (net: $900M)
since, in what I call a 'corporate crime in progress' : the failure to
successfully usurp BelCom into Comsat's empire has led to an internal
power-struggle at Comsat, with Beltway-Lions fighting over the control of
a $900M company. Can you say 'chopped heads' , 'body bags' , anyone ?
For control over one billion dollars, people will do anything. I have never
seen people act so ugly in my life. As one of the managers, I am getting
dragged into a mess of lawsuits at this time, with the DC boys and girls
sending gov't agencies my way, the whole charade: if you thought COINTELPRO
was a joke, think again: DC stands for District of Crime, and
Norman Schwartzkopf meant this literally.


In most likeliness, we will see a new chapter of the entire filtering issue
very soon: I am working on a new New York-Moscow IP link for a new company
at this time: same issues, same story, just a different name.

To Sean Doran: I was rather impressed by your recent statement, call it
commitment to your business: reselling IP wholesale, with the goal of
preserving functionality of the network as a whole, and a commitment to
what I previously believed to be untrue: not to squeeze the small guys
out of the market with arbitrary new filtering rules. Yet, I think
it's necessary to not follow this policy indefinitely into the future:

- we need faster routers. Cisco does not provide them at this time.
Where will they come from ? Take a look at the 'gigarouter' (URL lost
right now): it seems to implement what we have been talking about before:
a general purpose unix-type engine for route processing, with interface
cards with memory to hold complete static routing tables. The two
components talk on a separate bus with each other, both can be upgraded
independently. MCI uses them for the experimental vBNS.

- IPv6 will not solve aggregation issues the way we would like to see it:
we will see a greater trade-off for non-optimal routes (number of hops,
length) in favour of more aggregation, though. What is growing faster:
link speed, or processing power ? We all know the answer.

In the end, engineering will prevail over filtering, and when this is
reality, I expect the route filtering to disappear: if it doesn't,
it will go the way 800 numbers have gone: it took a significant change
in technology to accomplish number portability, but it was done because
the customers wanted it, and because AT&T (rightfully) feared to lose
a lot of business, yet had to cave in to external pressure, and to
Judge Greene.

If you don't want to see the equivalent of Judge Greene on the Internet,
you (major NSPs) will soon dedicate significant resources to solving
the problems mentioned here.

bye,Kai

------------------------------------------------------------------------
Kai Schlichting
Independent Telecommunications Consultant
Internet Consultancy : Cisco, Livingston, BSDI, SunOS, Linux spoken here
New York City, NY
kai@netcom.com
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
On Tue, 13 Feb 1996, Jonathan Heiliger wrote:

> Wow, so we just do this in a few hundred places and you've lowered the
> overall routing table by 8 * N(hundred). The main problem, as we all
> know, is this isn't a stable marketplace. Not only is there fierce
> competition for staff, but also for customers. Why would a number of
> small providers want join together?

Well actually, there isn't a fierce competition for customers and I
somehow doubt that there is much competition for staff. The market is
growing by leaps and bounds. The value of the Internet exists only
because service providers work co-operatively and exchange traffic with
each other. In just about every market there are STILL new startup ISP's
who are succeeding. Yes, there are failures, but the failure rate is very
low and it's only the most incompetent fools or incredibly unlucky ISP's
who are having problems.

There are definitely advantages for a lot of small ISP's banding together
by buying access through a 3rd-party exchange point. One is that they now
gain the benefit of the exchange point's technical staff. The small ISP
needn't learn all the details about BGP peering because the exchange
point does it for him. And when the exchange point technical people can
help out the small ISP's (their customers) with technical problems that
are beyond the ability of the small ISP's own staff.

There is a limit to the size an ISP can grow to and still provide
top-notch quality service. In every market I am aware of, ISP's who focus
on quality service are reaping the rewards in spite of often higher
prices than their competition. Therefore I believe that the market
naturally has room for many small ISP's and will continue to do so. The
"exchange point" concept also provides opportunities for the more
technically sophisticated ISP's who are tired of handholding dialup
customers. Many new dialup customers have NEVER USED A COMPUTER BEFORE!
Anyway, such an ISP can drop or de-emphasize their dialup services and
become an exchange point by focussing on providing leased-line services
to other ISP's.

How is this relevant? Well, if you want to encourage greater aggregation
in the global Internet, one way to do so is to explain to ISP's how a
more structured Internet can be of benefit to them by allowing them to
focus on a market niche and become real good at that rather than try to
be a jack-of-all-trades ISP who hasn't time to do any one thing very
well. This kind of structure may make it easier to get knowledge about
renumbering filtered down to the masses or it may indeed make renumbering
less urgent.

Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
>
> > unaccounted for. If you are talking about swamp, this is it.
> > However, a survey for how those chunks of address got broken up into
> > many different places perhaps can help in the direction of finding
> > such solution. If these small IP pieces can be grouped together
> > according to their geographic locations, there is chance that some
> > broken chunks may be pieced together to form large enough piece by
> > pure luck. If such solution exists, I am sure someone would be
> > interested in forming such regional consortiums to help salvage the once lost
> > IP addresses.
> > SC
>
> Neat! Garbage collection on the IP address space. The computer
> really *is* the network!
>
> -David

Perhaps you might have received a note from the IPGR robot
asking if your address space can be reclaimed? If not,
expect one or more in future.

More info at NAONG next week and PIER at IETF.

--
--bill
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
On Mon, 12 Feb 1996, Paul Ferguson wrote:

[How to get a block]

> Creating a consortium [akin to the NAP model] of small ISP's could
> easily resolve this problem, if all address space allocated to each
> ISP was contiguous and could be aggregated to a larger prefix.

But, this would require working with your direct competition in your
local geographic area.

Ain't gonna happen.

No way, No How.

The whole point of getting the bigger address space is to be better than
your competition (multi-homed, etc etc.)

(not that I don't *WANT* it to happen, it just isn't going to.)

-abc
\ Alan B. Clegg
Just because I can \ Internet Staff
does not mean I will. \ gateway.com, inc.
\ <http://www.gateway.com/>
Re: [NIC-960209.1757] Routing Problem (fwd) [ In reply to ]
On Thu, 15 Feb 1996, Alan B. Clegg wrote:

> On Mon, 12 Feb 1996, Paul Ferguson wrote:
>
> [How to get a block]
>
> > Creating a consortium [akin to the NAP model] of small ISP's could
> > easily resolve this problem, if all address space allocated to each
> > ISP was contiguous and could be aggregated to a larger prefix.
>
> But, this would require working with your direct competition in your
> local geographic area.
>
> Ain't gonna happen.
>
> No way, No How.

Wrong. It already is happening in some regions. You won't see any direct
competition in the Internet business for at least two more years unless
you see monsters under your bed and the CIA are listening in on your
brain.

The Internet market is miniscule. It is growing fast. It will continue to
grow fast. No one company can hope to grow fast enough to dominate in any
particular city. That's why you don't have to work with your local
competition, you just have to work with your other local ISP's in
building your local Internet infrastructure and growing your local
Internet market..

Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

1 2  View All