re: Sprints definition on NAPs (question)
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, 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
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-
|} > 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?
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?
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 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
participants (7)
-
Arun Welch -
Enke Chen -
Jeremy Porter -
John Scoggin -
Jonathan Heiliger -
Michael Dillon -
Nathan Stratton