Mailing List Archive

Allan laments, summarizes and asks, perhaps rhetorically:

{ a good summary condensed }

> So, comes my curiosity, and my puzzling thoughts about the current
> state of the net. Why is it not in my best interest to talk to
> NSPX at a meet point? Why, when it is in MY customer's best
> interest to talk to EVERYONE, would I not converse, and share
> knowledge and invitations about my customer base?
>

{ more good thoughts condensed }

Many can answer better than I, and please do not let my world-view
restrain other good responses to this interesting human question.....

Here is my 'weak attempt' at the human and social side of the issue:

If we examine the Kleinrock model for 'large Internets', most conclude
that hierarchical routing, broadly defined, is the 'mathematically correct',
large internet, paradigm to emulate or to 'grow towards'.
Hierarchical routing, unfortunately, translates (in business) to 'big fish
at the top' of the hierarchy and 'little fish' at the bottom in
'Global Routing Darwinism' as the net evolves.

How does a flat model where 'everybody is free to peer with everyone' move
to a ordered, structured 'hierarchy'? My guess ... by attempting to
set up NAPS with 'rules that tend to create a routing hierarchy'.
These 'rules', written or unwritten, exist; and those in the provider
business, by the nature of business, struggle to 'survive' in the
'routing hierarchy'; many wish to 'move up', others struggle to exist,
some are 'displaced lower' in the hierarchy by those 'moving up'.

Quintessential to the dynamics of business and business relationships
is (1) money and (2) power. Seductive and self destructive, yes;
but realistically, name a 'technology for the masses' that has
changed the dynamics of human behavior for 'the better'.

Nuclear power? Broadcast television? Radio? The Press? ..... ?!

The Internet?

Yes, we communicate faster and faster, but do we communicate better?
Does this 'new form of communication' better the economic conditions
of the poor or the social condition of the oppressed?

I share in the posters lamentation that the 'Commercialization of
the Internet' is 'not pretty nor poetic and esoteric'. It has
become, obviously, "Commercial" and "Worldly". To end, please
allow me to quote from Umberto Eco, "The Name of the Rose",


" It is only petty men who seem normal." - Eco


My apologies to the erudite for the pedantic, non-technical lament.

The technical answer is hidden in the allocortex and other lower
brain functions below the neo-cortex in all humans. Greed, desire,
fear, self-preservation and superstition to name a few 'core
engines' of the lower brain.

All the 'mathematics and code-cutting in the human reticulum' are
mastered by the persuasion and influence of these little organs
just above the reticular formation in the upper brain stem.

Life in the NAPS is certainly no exception :-)

Best Regards to All,


Tim


+--------------------------------------------------------------------------+
| Tim Bass | |
| Network Systems Engineer | "Never underestimate the bandwidth |
| The Silk Road Group, Ltd. | of an in-line skater with tapes |
| | hurtling down your favorite trail."|
| http://www.silkroad.com/ | -Tanenbaum & Bass |
| | |
+--------------------------------------------------------------------------+












- - - - - - - - - - - - - - - - -

>
> Just because someone has 30% of the internet, they still have an
> interest in connecting their 30% of the net to .1% of the net, no?
>

Because they can already hit that .1% of the 'net already without
peering with that smaller provider through that smaller provider's
transit provider and peering:

1) Enables them to screw you up a little more than they otherwise could
routing-wise
2) Provides them with free 'transit' across your backbone (even if it's
to/from your customers) if the peer isn't multiple-exchange-point
connected to some of the exchanges you are.
3) Has those political 'what is a peer' problems also.

>
> -alan
>

Avi

- - - - - - - - - - - - - - - - -

>From: Alan Hannan[SMTP:alan@gi.net]

> Pondering many things.

I have certainly been trying my best to gain as complete an understanding
of these 'things' as I possibly can while constructing a backbone, and so
will offer my (hopefully not _too_ clueless) thoughts:

> Why is it not in my best interest to talk to
> NSPX at a meet point?
>
> My thought, conspiratorally, is that larger folks (NSP4) could
> care less about talking to NSP3's p% of the net, when there is a
> lower cost involved in talking to NSP4's q% of the net,
> assuming q >>> p.
>
> And yet, I fail to grasp why it is not in their best interest to
> still include that group located in p%, NSP3's customers. Perhaps
> because they'd rather have the customers?

Perhaps NSP4 believes (likely correctly) that NSP3 will pay NSP4 (or
someone peering with NSP4), to ensure that NSP3 customers can talk to the
(larger set of) customers served by NSP4?

> Just because someone has 30% of the internet, they still have an
> interest in connecting their 30% of the net to .1% of the net, no?

Or expect the .1% to find a way to them?


> Perhaps the geographic cost investment in transit to far-reaching
> customers is sufficient. Somehow that doesn't answer the question
> for me.

> I'm not talking about transit, I don't think it's necessarily in
> NSP3's interest to carry NSP4's traffic to NSP1. But NSP3-NSP4 I
> can see as beneficial, w/ no dalliance.

Clearly this issue is rooted in economics, involving costs (including the
labor costs involved in maintaining what would be a large number of peering
relationships) as well as the maximization of revenue potential. We have
lost prospective customers because of our lack of NAP peering
relationships, when the customer hadn't the faintest idea what the concept
meant ("asking if we "paired" with anybody). My mental image of the whole
picture is that, if NSP4 is going to accept traffic from a West Coast
customer of NSP3 and haul it to their East Coast customer, they expect to
be able to hand the return traffic back to you on the East Coast, not haul
it to a single peering location in one part of the country. This is not
transit in the sense that it crosses into other networks, yet it certainly
requires the use of national infrastructure.

I'm not sure this answers the question fully for me, either.

> -alan
>
> "baring my heart for the wrath of all"

May it bring us all closer to cluefullness... :)
--
Jim Browning



- - - - - - - - - - - - - - - - -

Let's look at a hypothetical situation. ISP1 peers at MAE-E and
buys transit from MCI there. Now they ask Sprint to peer with them. Let's
look at how they reach sites on the west coast.

Without peering, MCI gives the packets to Sprint at MAE-East and
Sprint returns packets to MCI at some west coast nap. That is, MCI and
Sprint share the coast-to-coast traffic.

With peering, Sprint must take the packets all the to MAE-E as it
has a shorter AS path. All the coast-to-coast cost is borne by Sprint.

Do you get that? Now do you understand the 3 NAP rule?

David Schwartz

On Thu, 9 May 1996, Alan Hannan wrote:

> So, comes my curiosity, and my puzzling thoughts about the current
> state of the net. Why is it not in my best interest to talk to
> NSPX at a meet point? Why, when it is in MY customer's best
> interest to talk to EVERYONE, would I not converse, and share
> knowledge and invitations about my customer base?
- - - - - - - - - - - - - - - - -

>
> Let's look at a hypothetical situation. ISP1 peers at MAE-E and
> buys transit from MCI there. Now they ask Sprint to peer with them. Let's
> look at how they reach sites on the west coast.

This is a violation of the rules of Mae-East: it is not to be used for
customer connections. ISP1 must have a private connection to MCI.

Erik


> Without peering, MCI gives the packets to Sprint at MAE-East and
> Sprint returns packets to MCI at some west coast nap. That is, MCI and
> Sprint share the coast-to-coast traffic.
>
> With peering, Sprint must take the packets all the to MAE-E as it
> has a shorter AS path. All the coast-to-coast cost is borne by Sprint.
>
> Do you get that? Now do you understand the 3 NAP rule?
>
> David Schwartz
>
> On Thu, 9 May 1996, Alan Hannan wrote:
>
> > So, comes my curiosity, and my puzzling thoughts about the current
> > state of the net. Why is it not in my best interest to talk to
> > NSPX at a meet point? Why, when it is in MY customer's best
> > interest to talk to EVERYONE, would I not converse, and share
> > knowledge and invitations about my customer base?
- - - - - - - - - - - - - - - - -

>From: Erik Sherk[SMTP:sherk@uunet.uu.net]

>> From: David Schwartz aka Joel Katz[SMTP:stimpson@stimpson.igc.net]
>> Let's look at a hypothetical situation. ISP1 peers at MAE-E and
>> buys transit from MCI there. Now they ask Sprint to peer with them.
Let's
>> look at how they reach sites on the west coast.
>
>This is a violation of the rules of Mae-East: it is not to be used for
>customer connections. ISP1 must have a private connection to MCI.
>
>Erik

Are you saying that MFS will not allow a private connection between two
routers located at the MAE facility, even if the connection is _not_ made
using the MAE FDDI switch, but is instead a direct (e.g. HSSI or AIP)
connection between the two routers?? If so, I haven't seen any
documentation to that effect...
--
Jim Browning


- - - - - - - - - - - - - - - - -

On Fri, 10 May 1996, Erik Sherk wrote:

> >
> > Let's look at a hypothetical situation. ISP1 peers at MAE-E and
> > buys transit from MCI there. Now they ask Sprint to peer with them. Let's
> > look at how they reach sites on the west coast.
>
> This is a violation of the rules of Mae-East: it is not to be used for
> customer connections. ISP1 must have a private connection to MCI.

True. Serves me right for composing a quick example. Let's change
the example to say they get the transit through a private T3.

DS

- - - - - - - - - - - - - - - - -

.

So ISP1 peers at MAE-East and has a private serial circuit to MCI
(or someone elses) router at the MAE (not using MAE infrastructure).
Same result. And same result even if ISP1 peers at the MAE and sends
all its traffic to any MCI site 'near' (in network terms) MAE-East,
ust as long as MCI gives the traffic to Sprint there.

Alex Bligh
Xara Networks


- - - - - - - - - - - - - - - - -

> >From: Erik Sherk[SMTP:sherk@uunet.uu.net]
>
> >> From: David Schwartz aka Joel Katz[SMTP:stimpson@stimpson.igc.net]
> >> Let's look at a hypothetical situation. ISP1 peers at MAE-E and
> >> buys transit from MCI there. Now they ask Sprint to peer with them.
> Let's
> >> look at how they reach sites on the west coast.
> >
> >This is a violation of the rules of Mae-East: it is not to be used for
> >customer connections. ISP1 must have a private connection to MCI.
> >
> >Erik
>
> Are you saying that MFS will not allow a private connection between two
> routers located at the MAE facility, even if the connection is _not_ made
> using the MAE FDDI switch, but is instead a direct (e.g. HSSI or AIP)
> connection between the two routers?? If so, I haven't seen any
> documentation to that effect...
> --
> Jim Browning
>
>
>
I interpret it slightly differently. I think he is saying that if you
buy transit from MCI, you can't do it across MAE East, but instead would
need a private connection to MCI. Presumably this could be done at the
MAE East site, as long as it did not congest the MAE East net.

Owen
- - - - - - - - - - - - - - - - -

On 9 May 96 at 22:09, Alan Hannan wrote:

> And yet, I fail to grasp why it is not in their best interest to
> still include that group located in p%, NSP3's customers. Perhaps
> because they'd rather have the customers?

[pessimistic mode on]...that's kinda my gut level feeling, considering the way
some of the national providers, and recent announcements by some of the RBOCs,
tend to lead the uninitiated to believe the only way to reliably connect in a
time sensitive and cost effective manner is with the big boys.

_dave_(seemingly obligatory and definitely bandwidth wasting .sig)
- - - - - - - - - - - - - - - - -

In message <199605100309.WAA25431@westie.gi.net>, Alan Hannan writes:
>
> So, WHY would an NSP enter into a peering agreement with another
> person? Why, to profit from the one side of the connection, to
> enable an entity [labeled A] to talk with some other entity [labeled
> B]. In most cases, NSP1 had as customer A, and NSP2 had as customer B,
> and obv. it was in their best interest to meet somewhere to talk
> to each other. NSP1 added value to A, by providing a path to B.
> NSP2 added value to customer B by providing a path to A.


Maybe because their routers fall over beyond some number of direct
peers and they have a problem with the idea of going through the RA's
router servers to avoid that problem (whether the problem is real or
imagined, present company included - not sure if a smiley or a frown
is needed here).

This results in a need/desire to prioritize.

Let me turn the question around a bit. Suppose N small providers peer
at M places and together represent p% of the Internet. If they simply
appear at one NAP and don't contract for transit, they may reach
100%-(%p/(M-1)) of the Internet. Is that something to encourage? If
they must contract for transit and as a result reach all major
interconnects, they get 100% (possibly minus a small epsilon for other
reasons). They then don't need to be at any of the NAPs. Are some
providers trying to show up at one NAP only with the aim of not
contracting for transit through anyone even though they can't really
reach others like themselves at a different interconnect?

Curtis

ps- this is a tangent but - I think ANS has a problem with using the
RS since at one point we announced everything to the RS and started
giving transit connectivity to people that were not transit customers
of ANS. The technical barrier to fixing this at that time was an
inability to express outbound policy adequately (no support for
as-paths). This technical barrier is almost gone except we have code
that uses as-macros and we'd have to exapnd the as-macros and
expresses this policy in our aut-num. So the ball is in our court
(along with too many others). The other issue is we have no
management access to the RS and so if any of this isn't configured
and/or working right on the RS we can't easily tell if it is. The
issue in general for most providers is they want direct control over
their peerings and import and export policy.

pps- I suppose the other solution is to get routers that can handle
the peerings directly. :-)
- - - - - - - - - - - - - - - - -

> Let me turn the question around a bit. Suppose N small providers peer
> at M places and together represent p% of the Internet. If they simply
> appear at one NAP and don't contract for transit, they may reach
> 100%-(%p/(M-1)) of the Internet. Is that something to encourage? If
> they must contract for transit and as a result reach all major
> interconnects, they get 100% (possibly minus a small epsilon for other
> reasons). They then don't need to be at any of the NAPs. Are some
> providers trying to show up at one NAP only with the aim of not
> contracting for transit through anyone even though they can't really
> reach others like themselves at a different interconnect?

Or, possible some small providers buy a multi-megabit circuit from a
large provider who gives them transit. The small provider then connects
at a single NAP and picks up bilateral peering sessions with a bunch
of people there. The result is offloading traffic from their
"transit link", which stands a good chance of being priced as a
"burstable" link. (pay for what you use) That gives the small
provider an economic incentive to operate in this manner.

No comment on whether this is a good idea or bad, but I understand
the thinking.

davec

- - - - - - - - - - - - - - - - -

> Or, possible some small providers buy a multi-megabit circuit from a
> large provider who gives them transit. The small provider then connects
> at a single NAP and picks up bilateral peering sessions with a bunch
> of people there. The result is offloading traffic from their
> "transit link", which stands a good chance of being priced as a
> "burstable" link. (pay for what you use) That gives the small
> provider an economic incentive to operate in this manner.
>
> No comment on whether this is a good idea or bad, but I understand
> the thinking.
>
> davec

Quite a few CIX members operate this way. The interesting question in my
mind is whether the "big guys" (defaultless nets, for the purposes of this
discussion) think that this represents unfair competition or not.
- - - - - - - - - - - - - - - - -

We have a transit connection here _and_ a connection to mae-west.
The mae-west connection's best use is to get traffic to and from
other medium-sized regional providers without visiting either our
or their transit provider (often different ones, so we're saving a lot
of hops and potential congestion points here)

There's also those nationwide providers (like UUnet) who apparently find
it in their best interest to peer with regional networks to take advantage
of the increased performance that parties on both sides get when it happens.
I think this makes for a lot of happy customers on both sides of the
situation, because any increase in performance or reliability between my
network and the nationwide network's customers translates into fewer
complaints by those customers that "the net's broken today". Sprint had
an engineer on the phone with our operations center just a couple days ago,
trying to resolve a complaint originating with a Sprint customer that our
network was unreachable... had Sprint been peering with us, instead of
relying exclusively on our transit provider who happened to be having an
outage, Sprint would have had a happier customer and that Sprint engineer
wouldn't have had to make that phone call. Last I checked, paying a skilled
NOC person for a few hours could pay for months worth of the bandwidth that
we'd "get for free" if Sprint peered with us at just a single coast.

The unfortunate thing is when regional providers turn into national
providers and lose their incentive to peer with other regionals
(eg. formerly-BARRNet, who isn't interested in peering with me because
I'm only on one coast, even though, with quickest-exit, all the traffic
between the west coast part of BBN Planet and our network would be
crossing the west-coast interconnect only... seems silly for me to have
to go buy a router and a DS3 to the east coast just so regional traffic can
stay local and avoid the extra hops imposed by us each using our transit
providers)

I understand that nationwide providers don't want to provide me with
"free transit", so, I suggest the following solutions (directed at
those nationwide providers who don't peer with me, and networks like mine):

1. Peer with me anyway, but don't accept any of my routes into your
network... that allows me to do the same thing I would do if I were
nationwide and doing quickest-exit (feed all traffic destined for your
nationwide network into it at the west coast) without giving me the
benefit of the return path... this is no more asymmetric than we've got
now, and at least accelerates the one direction. I've got a transit
provider, so I'm going to hand you the very same packets eventually...
you might as well take them off my hands at the interconnect, rather
than have them presented to you by my transit provider.

2. Even better, accept my routes into your network but only use them
within region... I know this isn't nearly as easy as #1, so I don't
expect it to happen, but it would be a significant performance benefit
for the local traffic your customers in the region are generating which
is headed towards me. Once outside the region, of course, you ignore the
direct routes from me and just give them to my transit provider.

Meanwhile, the interconnect is still mighty useful for getting traffic
around the area, so even without peering with everybody who's there, we
see a lot of performance gains that our customers (and the customers of
the other networks) appreciate. There's no way we can pick up all of the
regional business, and I think most of our competition knows that they're
in the same situation, and that's what makes regional peering work.

-matthew kaufman
matthew@scruz.net

Original message <199605110144.VAA26028@neteng.nis.newscorp.com>
From: Dave Curado <dcurado@neteng.nis.newscorp.com>
Date: May 10, 21:44
Subject: Re: Worldly Thoughts
>
>
> Or, possible some small providers buy a multi-megabit circuit from a
> large provider who gives them transit. The small provider then connects
> at a single NAP and picks up bilateral peering sessions with a bunch
> of people there. The result is offloading traffic from their
> "transit link", which stands a good chance of being priced as a
> "burstable" link. (pay for what you use) That gives the small
> provider an economic incentive to operate in this manner.
>
> No comment on whether this is a good idea or bad, but I understand
> the thinking.
>
> davec
>
>-- End of excerpt from Dave Curado


- - - - - - - - - - - - - - - - -

Original message <9605110249.AA04557@wisdom.home.vix.com>
From: Paul A Vixie <paul@vix.com>
Date: May 10, 19:49
Subject: Re: Worldly Thoughts
>
> Quite a few CIX members operate this way. The interesting question in my
> mind is whether the "big guys" (defaultless nets, for the purposes of this
> discussion) think that this represents unfair competition or not.
>-- End of excerpt from Paul A Vixie

This is a _very_ interesting question in light of what I just posted...
the CIX has the (odd, these days) feature that peering is mandatory for all,
and so large providers don't get to choose whether or not they want to
haul traffic across the country for these people.

-matthew kaufman
matthew@scruz.net

ps. We'd already be at CIX if certain providers had more than a T-1's worth of
bandwidth available out of there, specifically to take advantage of the
"mandatory peering" situation. Heavily-loaded small pipes to interesting
places aren't useful, though.

- - - - - - - - - - - - - - - - -

> This is a _very_ interesting question in light of what I just posted...
> the CIX has the (odd, these days) feature that peering is mandatory for all,
> and so large providers don't get to choose whether or not they want to
> haul traffic across the country for these people.

There is no such thing as mandatory peering. Several folks on the SMDS cloud
purposely do not peer with certain other folks on the same cloud. Everybody
peers with the CIX routers, though, and with third-party BGP routes that means
most traffic is just point to point. (The SMDS access lists are not perfect,
so there are some in-and-out cases for various endpoint pairs.)

> ps. We'd already be at CIX if certain providers had more than a T1's worth
> of bandwidth available out of there, specifically to take advantage of the
> "mandatory peering" situation. Heavily-loaded small pipes to interesting
> places aren't useful, though.

The link you're alluding to is probably SprintLink's. It runs at or near
capacity for most of every day, and while that's usually an indicator that
a larger pipe is called for, it's also an indicator that the link is of use
to at least some folks.
- - - - - - - - - - - - - - - - -

At 11:47 PM 5/10/96, Matthew Kaufman wrote:

>I understand that nationwide providers don't want to provide me with
>"free transit", so, I suggest the following solutions (directed at
>those nationwide providers who don't peer with me, and networks like mine):
>
> 1. Peer with me anyway, but don't accept any of my routes into your
> network... that allows me to do the same thing I would do if I were
> nationwide and doing quickest-exit (feed all traffic destined for your
> nationwide network into it at the west coast) without giving me the
> benefit of the return path... this is no more asymmetric than we've got
> now, and at least accelerates the one direction. I've got a transit
> provider, so I'm going to hand you the very same packets eventually...
> you might as well take them off my hands at the interconnect, rather
> than have them presented to you by my transit provider.

Interesting... it does avoid the transit issue, so it's worth considering to
some extent. I'll note that the current west-coast interconnects are not
exactly lacking traffic so there may be cases where it may not be advisable
to peer anyway if adds more traffic to the interconnect.

> 2. Even better, accept my routes into your network but only use them
> within region... I know this isn't nearly as easy as #1, so I don't
> expect it to happen, but it would be a significant performance benefit
> for the local traffic your customers in the region are generating which
> is headed towards me. Once outside the region, of course, you ignore the
> direct routes from me and just give them to my transit provider.

It becomes very entertaining to scale the above model (although it does
provide an excuse to use nearly every BGP routing feature in IOS. :-)

/John


- - - - - - - - - - - - - - - - -

> >From: Erik Sherk[SMTP:sherk@uunet.uu.net]
>
> >> From: David Schwartz aka Joel Katz[SMTP:stimpson@stimpson.igc.net]
> >> Let's look at a hypothetical situation. ISP1 peers at MAE-E and
> >> buys transit from MCI there. Now they ask Sprint to peer with them.
> Let's
> >> look at how they reach sites on the west coast.
> >
> >This is a violation of the rules of Mae-East: it is not to be used for
> >customer connections. ISP1 must have a private connection to MCI.
> >
> >Erik
>
> Are you saying that MFS will not allow a private connection between two
> routers located at the MAE facility, even if the connection is _not_ made
> using the MAE FDDI switch, but is instead a direct (e.g. HSSI or AIP)
> connection between the two routers?? If so, I haven't seen any
> documentation to that effect...

MFS has nothing to do with this. The issue is using the shared
Internet resource (namely the GIGA Switch) to connect customers.
The original members of Mae-East aggreed to this when we set up
the first peering sessions. The exchanges are for peer to peer
traffic, not customer to vendor traffic.

Erik
- - - - - - - - - - - - - - - - -

> > Are you saying that MFS will not allow a private connection between two
> > routers located at the MAE facility, even if the connection is _not_ made
> > using the MAE FDDI switch, but is instead a direct (e.g. HSSI or AIP)
> > connection between the two routers?? If so, I haven't seen any
> > documentation to that effect...
>
> MFS has nothing to do with this. The issue is using the shared
> Internet resource (namely the GIGA Switch) to connect customers.
> The original members of Mae-East aggreed to this when we set up
> the first peering sessions. The exchanges are for peer to peer
> traffic, not customer to vendor traffic.

Note that this differs mightily from the DEC NAP that I've been helping to
create down in Palo Alto. There are four GIGAswitches (two FDDI and two
ATM) and it is very much expected that some folks will buy colocation space
from DEC and cross-connect over to their transit provider du jour. Someone
who just wants to put their servers close to the "backbone" should not and
will not be connected to the public GIGAswitches. Running transit routers
and doing all the BGP and RADB work to get peering working and keep it
working is much too complicated for the average server owner.
- - - - - - - - - - - - - - - - -

] > Or, possible some small providers buy a multi-megabit circuit from a
] > large provider who gives them transit. The small provider then connects
] > at a single NAP and picks up bilateral peering sessions with a bunch
] > of people there. The result is offloading traffic from their
] > "transit link", which stands a good chance of being priced as a
] > "burstable" link. (pay for what you use) That gives the small
] > provider an economic incentive to operate in this manner.

] Quite a few CIX members operate this way. The interesting question in my
] mind is whether the "big guys" (defaultless nets, for the purposes of this
] discussion) think that this represents unfair competition or not.

We've a defaultless net, but I'm not sure that I'm considered a
'Big Guy'. Hell, we only route 1% of the internet, but maybe if I
lost my aggregates I could be bigger ;)

The hidden metric that davec above doesn't consider is latency.

If I peer at a NAP, I forgo the latency my upstream 'multi-megabit
circuit' incurs.

This is a consideration, you know.

-alan
- - - - - - - - - - - - - - - - -

mk@skruz:
] > ps. We'd already be at CIX if certain providers had more than a T1's worth
] > of bandwidth available out of there, specifically to take advantage of the
] > "mandatory peering" situation. Heavily-loaded small pipes to interesting
] > places aren't useful, though.

vix:
] The link you're alluding to is probably SprintLink's. It runs at or near
] capacity for most of every day, and while that's usually an indicator that
] a larger pipe is called for, it's also an indicator that the link is of use
] to at least some folks.

The interesting thing here is to ask WHY SL hasn't upgraded the
line.

The fact that the line hasn't been upgraded could imply that the CIX
isn't of use to SL.

-alan

- - - - - - - - - - - - - - - - -

On Sat, 11 May 1996, Paul A Vixie wrote:

> > > Are you saying that MFS will not allow a private connection between two
> > > routers located at the MAE facility, even if the connection is _not_ made
> > > using the MAE FDDI switch, but is instead a direct (e.g. HSSI or AIP)
> > > connection between the two routers?? If so, I haven't seen any
> > > documentation to that effect...

MFS will allow this in MAE EAST I am aware of. However the connecting
circuit (eg. ethernet or FDDI cable) has to be provisioned by MFS and a
monthly cross-connect fee.

---
Stephen Balbach "Driving the Internet to Work"
VP, ClarkNet due to the high volume of mail I receive please quote
info@clark.net the full original message in your reply.

- - - - - - - - - - - - - - - - -

> vix:
> ] The link you're alluding to is probably SprintLink's. It runs at or near
> ] capacity for most of every day, and while that's usually an indicator that
> ] a larger pipe is called for, it's also an indicator that the link is of use
> ] to at least some folks.
>
> The interesting thing here is to ask WHY SL hasn't upgraded the line.

I've been told that they consider the T1 adequate.

> The fact that the line hasn't been upgraded could imply that the CIX
> isn't of use to SL.

When the link went down due to a cross connect problem, an engineer and
his manager inside SL worked all day and most of a night to get it restored.
- - - - - - - - - - - - - - - - -

[.keep in mind that it's been over 18 months since I was a CRL employee]

Robert writes:
>Wouldn't have anything to do with the fact that it is a major cross connect
>between many providers and Sprint? CRL comes to mind.

CRL is also at MAE-W and the NAP, I would presume peering with Sprint at
those locations as well as at CIX. It might be useful to compare lists
of who's at CIX and at MAE-W and PB-NAP and see who's CIX-only, but I
doubt CRL would be on that list. I could be wrong, though...


-george william herbert
gherbert@crl.com
Most Assuredly Not speaking for CRL

- - - - - - - - - - - - - - - - -

>
> > vix:
> > ] The link you're alluding to is probably SprintLink's. It runs at or near
> > ] capacity for most of every day, and while that's usually an indicator that
> > ] a larger pipe is called for, it's also an indicator that the link is of use
> > ] to at least some folks.
> >
> > The interesting thing here is to ask WHY SL hasn't upgraded the line.
>
> I've been told that they consider the T1 adequate.
>
> > The fact that the line hasn't been upgraded could imply that the CIX
> > isn't of use to SL.
>
> When the link went down due to a cross connect problem, an engineer and
> his manager inside SL worked all day and most of a night to get it restored.
>
Wouldn't have anything to do with the fact that it is a major cross connect
between many providers and Sprint? CRL comes to mind.

Rob

- - - - - - - - - - - - - - - - -