North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Sprint peering policy (fwd)

  • From: Deepak Jain
  • Date: Mon Jul 01 20:13:38 2002

1) I am sure we could bounce all our signals off of satellites too. We could
pick a provider for our telecom needs that does not do mileage sensitive
pricing, or we could just buy transit from another provider and run tunnels.
That really isn't the point, you are running over mileage based pipes. If I
don't want to run over a cloud (which is subject to nasty, hard to diagnose
failures) I shouldn't have to. If you can convince your peer to do this with
you,  then you don't have a peering problem, do you?

2) The costs of these clouds tend to be significantly more than the cost of
each underlying circuit then there is a management piece on top of it. If
you have small enough usage this makes sense and your peer feels good about
it, then you are great. If, on the other hand, you are connecting your three
routers to the same cloud and peering at a NAP, you are essentially using
someone else's network. This is one of the reason large networks put
pipe-size point-to-point requirements in their agreements -- to specifically
avoid this.

Either way, if your peer likes the idea, you are in great shape. People who
think ATM or FR sucks over long distances won't do it. Anyone who uses a
large cloud like this from another network and finds it reliable, I'd like
to hear from you privately. A few NAPs did things like this for sites within
a LATA, but you still have to like ATM a lot to make it worth it.

The biggest reason this is bad is because of the single point of failure
issues here. A single switch in the cloud loses its marbles and all of your
PVCs, MPLS tunnels, or whatever could bring down your entire peering fabric.
This defeats at least one of the reasons for multiple connections.

Deepak Jain
AiNET

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
E.B. Dreger
Sent: Monday, July 01, 2002 5:12 PM
To: [email protected]
Subject: RE: Sprint peering policy (fwd)



DJ> Date: Mon, 1 Jul 2002 16:58:10 -0400
DJ> From: Deepak Jain


DJ> You achieve price symmetry when push/pull ratios match or
DJ> approach each other because the amount of bits x distance for
DJ> each party is more equal.  This is what many tier-1's would
DJ> consider an equal peering relationship.

Alternatively, two providers could peer via a { cell | packet }-
switched fabric, splitting the cost.

ISP1:  NYC, SJC, CHI
ISP2:  LAX, SJC, SEA

A cloud connects the five cities.  ISP1 and ISP2 split the cost,
and exchange traffic via the cloud.  Suddenly traffic ratios
become less important, and traffic levels become the primary
justification metric.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <[email protected]>
To: [email protected]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[email protected]>, or you are likely to
be blocked.