Mailing List Archive

On Mon, 29 Apr 1996, Marcos Della wrote:

> Ok, I have been told repeatedly that I cannot peer with Sprint because I don't
> meet the three NAP list. Ok, what is considered a NAP by sprint? I'm
> in the process of putting a DS3 to SprintNAP so I assume that will count
> for one... PacNAP count? Mae-East or West?

Sprint, PacBell, Ameritech, MAE-East, and MAE-West all count I think.

> Whats the official list so that I don't have to keep bouncing routes for
> Sprint customers all over kingdom come or hope for route reflections on the
> various interconnect points...

MAE-East, Sprint, PacBell, and Ameritech I think.

> Also, once you do meet the criteria, who do you talk to? Talking to a Sprint
> salesman is like talking to a brick wall...

The peering contact guy. :-) Most NAPs give you a list of contacts.

P.S. Also with sprint you need a FULL DS3 east to west cost to peer.

Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
---------------------------------------------------------------------------
Phone (703)524-4800 NetRail, Inc.
Fax (703)534-5033 2007 N. 15 St. Suite 5
Email sales@netrail.net Arlington, Va. 22201
WWW http://www.netrail.net/ Access: (703) 524-4802 guest
---------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about
itself. Each day has enough trouble of its own." Matthew 6:34

On Mon, 29 Apr 1996, John Scoggin wrote:

> The other question that should be asked (and I hope some folks have looked at
> this) is whether this rule is in fact arbitrary. If there is no sound
> ENGINEERING reason, it may constitute "restraint of trade" under Chapter 2 of
> the Sherman Act (if memory serves). These types of problems can be quite
> nasty, involving treble punitive damages.

Ya, but Sprint has more money then us, and money wins. :-)

Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
---------------------------------------------------------------------------
Phone (703)524-4800 NetRail, Inc.
Fax (703)534-5033 2007 N. 15 St. Suite 5
Email sales@netrail.net Arlington, Va. 22201
WWW http://www.netrail.net/ Access: (703) 524-4802 guest
---------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about
itself. Each day has enough trouble of its own." Matthew 6:34

----------

>Whats the official list so that I don't have to keep bouncing routes for
>Sprint customers all over kingdom come or hope for route reflections on the
>various interconnect points...

Out of curiosity, does this mean you are pointing a default at
someone?

Steve

On Mon, 29 Apr 1996, Nathan Stratton wrote:

|} > the Sherman Act (if memory serves). These types of problems can be quite
|} > nasty, involving treble punitive damages.
|}
|} Ya, but Sprint has more money then us, and money wins. :-)

More importantly, Sprint (or any "larger" carrier) has content, and
customers that YOU (being a "smaller" ISP) want to provide to your
customers. Typically the larger folks are happy to get to ISP #1 via
their single transit route because there's less load on their routers
(being border or otherwise), fewer paths, etc.

However, for ISP #1 it's a different story -- if they were to peer with
the carrier life would potentially be better for them, whereas it affects
the carrier minimally in most cases. Lots of ISPs currently do not peer
with the carriers at exchange points, and simply buy transit from one;
making them dependant on that carrier <-> customer relationship.

In a perfect world, everyone would peer directly with everyone else,
however this is not the case. Carriers by nature invest substantially in
backbone infrastructure that smaller ISPs do not, to most this gives them
good reason not to provide "equal access" to ISPs that have not invested
similarly in infrastructure.


-jh-

On Mon, 29 Apr 1996, John Scoggin wrote:

> The other question that should be asked (and I hope some folks have looked at
> this) is whether this rule is in fact arbitrary. If there is no sound
> ENGINEERING reason, it may constitute "restraint of trade" under Chapter 2 of
> the Sherman Act (if memory serves).

The original poster, Marcos Della, mentioned he couldn't get any info out
of Sprint's *SALES* dept. This is half the problem. Peering is an
engineering issue far more than a sales issue and you will never get
anywhere talking to the sales dept.

Of course, the engineering dept. is too bust doing engineering to take
time out to talk to you and hold your hand, so what do you do?

Well, it's like applying for a job. Research the company, research the
position, then find the right person to send your application to. In this
case it is more like, research the technology (BGP etc...), research
the concept of peering at a NAP, and find the right engineers to talk to.

The last part is the easiest, because all you need to do is attend a few
NANOG meetings in person. A nice side effect is that the speakers at the
NANOG meetings will educate you in some of the things you need to know and
help you find out what you don't know yet. Basically, if there is anything
that you don't understand from one of the presentations, that indicates an
area in which you need to do further study in order to reach an acceptable
level of competence.

Just remember the plain English meaning of the word "peer". It refers to
an individual who is at the same level as you. Same level of power (CEO
vs. engineer), same level of skill (PhD vs undergrad) and so on.


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

The other question that should be asked (and I hope some folks have looked at
this) is whether this rule is in fact arbitrary. If there is no sound
ENGINEERING reason, it may constitute "restraint of trade" under Chapter 2 of
the Sherman Act (if memory serves). These types of problems can be quite
nasty, involving treble punitive damages.

I have never been a lawyer (or played one on TV :-), but I can recall
handling disbursement of suit awards while a programmer in a bank Trust
Department...

> On Mon, 29 Apr 1996, Marcos Della wrote:
>
> > Ok, I have been told repeatedly that I cannot peer with Sprint because I don't
> > meet the three NAP list. Ok, what is considered a NAP by sprint? I'm
> > in the process of putting a DS3 to SprintNAP so I assume that will count
> > for one... PacNAP count? Mae-East or West?
>
> Sprint, PacBell, Ameritech, MAE-East, and MAE-West all count I think.
>

From the NSF Solicitations:
MAE-East
Sprint NAP
AADS NAP
PacBell NAP

These are the formal NAPs. I don't know what Sprint thinks of
when the term "NAP" is used.

--
--bill

According to Nathan Stratton:
>
> On Mon, 29 Apr 1996, Marcos Della wrote:
>
> > Ok, I have been told repeatedly that I cannot peer with Sprint because I don't
> > meet the three NAP list. Ok, what is considered a NAP by sprint? I'm
> > in the process of putting a DS3 to SprintNAP so I assume that will count
> > for one... PacNAP count? Mae-East or West?
>
> Sprint, PacBell, Ameritech, MAE-East, and MAE-West all count I think.
>
> > Whats the official list so that I don't have to keep bouncing routes for
> > Sprint customers all over kingdom come or hope for route reflections on the
> > various interconnect points...
>
> MAE-East, Sprint, PacBell, and Ameritech I think.
>

As per the NSF 93-52 solicitation and award, there are 3 official Primary NAPSs
and one Interconnect point (secondary NAP):

San Francisco NAP (Pacbell & Bellcore)
New York NAP (Sprint - actually in Pennsaucken New Jersey)
Chicago NAP (Ameritech & Bellcore)

The interconnect point (secondary NAP):

Washington DC (MFS DataNet - aka DC NAP and Mae-East).

--curtis

>|} > the Sherman Act (if memory serves). These types of problems can be quite
>|} > nasty, involving treble punitive damages.

Unfortunately for Nathan, this above is wrong.

There are very real engineering reasons for not peering
if someone is at one NAP/MAE. Also since Sprint and MCI
do have published policies, if they made exceptions to them
they could get sued for discriminating against some competators
(not all, makes a big legal difference).

So in fact, unless Sprint and MCI want to give away
service to all people that connect to the MAEs/NAPs,
they MUST have a policy, and MUST abided by it.
(And as soon as that happens, I know of a Texas company
that will drop lines into MAE-East and force peering
with Sprint and MCI, etc., needless to say I don't see that
happening, so I will have to build a backbone to three NAPs
just like everywhere else.)

And there is the issue of actually having peering capacity
available. (Not only do some want free service to the
carrier's customers, but they want the carrier to replace all
of the carrier's routers).

I understand that when capacity is available, a number of the carriers
would not be adverse to discussing having someone that does
not meet the full requirements for peering, PAY to get peering,
thus offseting the backbone costs. (This should cost less than
full transit since its just inside the carrier's backbone, but
this partly depends on the true incremental cost of the paths
and prefixes.)

>|} Ya, but Sprint has more money then us, and money wins. :-)
>
>More importantly, Sprint (or any "larger" carrier) has content, and
>customers that YOU (being a "smaller" ISP) want to provide to your
>customers. Typically the larger folks are happy to get to ISP #1 via
>their single transit route because there's less load on their routers
>(being border or otherwise), fewer paths, etc.


--
Jeremy Porter, Freeside Communications, Inc. jerry@fc.net
PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-339-6094
http://www.fc.net
- - - - - - - - - - - - - - - - -

On Wed, 1 May 1996, Jeremy Porter wrote:

> >|} > the Sherman Act (if memory serves). These types of problems can be quite
> >|} > nasty, involving treble punitive damages.
>
> Unfortunately for Nathan, this above is wrong.
>
> There are very real engineering reasons for not peering
> if someone is at one NAP/MAE. Also since Sprint and MCI
> do have published policies, if they made exceptions to them
> they could get sued for discriminating against some competators
> (not all, makes a big legal difference).

Ok, so what about Interpath, CAIS, and a bunch more that are peering with
MCI and are at only 1 NAP?

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

> needless to say I don't see that
> happening, so I will have to build a backbone to three NAPs
> just like everywhere else.)
>

Not that this'll do you any good, since Sprint's current policy is no new
peers until the end of summer, at which point it may become a product (how
they plan on charging is anyone's guess) in which case they'll start peering
again.

...arun
- - - - - - - - - - - - - - - - -

On Wed, 1 May 1996, Nathan Stratton wrote:

> Ok, so what about Interpath, CAIS, and a bunch more that are peering with
> MCI and are at only 1 NAP?

I just wanted to apologize for using the names of to providers, many
people have informed me that this was a bad idea. After I hit the alt-X, I
kinda wished I could bring it back. I am vary sorry if I offended either
company, and just wanted to publicly say "I screwed up, and I am sorry."


Nathan Stratton CEO, NetRail, Inc. Tracking the future today!
---------------------------------------------------------------------------
Phone (703)524-4800 NetRail, Inc.
Fax (703)534-5033 2007 N. 15 St. Suite 5
Email sales@netrail.net Arlington, Va. 22201
WWW http://www.netrail.net/ Access: (703) 524-4802 guest
---------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about
itself. Each day has enough trouble of its own." Matthew 6:34


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

IMHO, it is a fair statement that these peers face great uncertainty.
There should not be any loss of connectivity as their transit provider
should take care of business.

-- Enke

> Date: Wed, 1 May 1996 09:14:44 -0400 (EDT)
> From: Nathan Stratton <nathan@netrail.net>
> To: Jeremy Porter <jerry@fc.net>
> CC: loco@MFST.COM, nanog@merit.edu

> On Wed, 1 May 1996, Jeremy Porter wrote:
>
> > >|} > the Sherman Act (if memory serves). These types of problems can be q
uite
> > >|} > nasty, involving treble punitive damages.
> >
> > Unfortunately for Nathan, this above is wrong.
> >
> > There are very real engineering reasons for not peering
> > if someone is at one NAP/MAE. Also since Sprint and MCI
> > do have published policies, if they made exceptions to them
> > they could get sued for discriminating against some competators
> > (not all, makes a big legal difference).
>
> Ok, so what about Interpath, CAIS, and a bunch more that are peering with
> MCI and are at only 1 NAP?
>
- - - - - - - - - - - - - - - - -

At 09:14 AM 5/1/96 -0400, you wrote:
>On Wed, 1 May 1996, Jeremy Porter wrote:
>
>> >|} > the Sherman Act (if memory serves). These types of problems can be
quite
>> >|} > nasty, involving treble punitive damages.
>>
>> Unfortunately for Nathan, this above is wrong.
>>
>> There are very real engineering reasons for not peering
>> if someone is at one NAP/MAE. Also since Sprint and MCI
>> do have published policies, if they made exceptions to them
>> they could get sued for discriminating against some competators
>> (not all, makes a big legal difference).
>
>Ok, so what about Interpath, CAIS, and a bunch more that are peering with
>MCI and are at only 1 NAP?

Probably because they were peering with MCI before the policy, but thats
just a guess.


Justin Newton * You have to change just to stay
Internet Architect * caught up.
Erol's Internet Services *

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