Sprint peering policy (fwd)

Tue Jul 2 01:13:10 UTC 2002

DJ> Date: Mon, 1 Jul 2002 20:10:44 -0400
DJ> From: Deepak Jain

[ snipping throughout ]

DJ> [Y]ou are running over mileage based pipes.

Exactly.  And ingress:egress is meant as an attempt to address
the issue, is it not?  If traffic flows are "close enough" to
equal in both directions, everyone feels good that nobody is
taking a free ride over the other's pipe.  No?

DJ> If, on the other hand, you are connecting your three routers
DJ> to the same cloud and peering at a NAP, you are essentially
DJ> using someone else's network. This is one of the reason large
DJ> networks put pipe-size point-to-point requirements in their
DJ> agreements -- to specifically avoid this.

Not that Large Network could create a peering fabric via its own
capacity and charge Small Network roughly half (splitting the
cost) for fabric access.  In this case, it's not so much "paid
peering" in the standard sense as it is settlement-free peering
and pay-as-you-go geographical expansion.

In the extreme degenerate case, one approaches paid peering.  Do
you mean to state that there is no possible way to find a middle
ground between pay-amount-x-to-peer-y-at-any-given-pop and
settlement-free peering?

DJ> People who think ATM or FR sucks over long distances won't do
DJ> it.

1. Such fabric could be IP-based.

2. ATM and FR don't suck inherently; they work quite well on
   small, bursty interfaces when statmuxed within sane bounds.
   (Don't blame stupid network design on the technology used.)

3. Any provider big enough to have outgrown FR and ATM probably
   can expand their footprint on their own.

DJ> Anyone who uses a large cloud like this from another network
DJ> and finds it reliable, I'd like to hear from you privately.

Anyone who use(s|d) a large cloud, I'd like to hear... along with
what reliability (is|was).  I won't stretch my case so far as to
claim that regional universities sharing a WAN and peering at a
NAP counts...

DJ> The biggest reason this is bad is because of the single point

FUD alert!

DJ> of failure issues here. A single switch in the cloud loses
DJ> its marbles and all of your PVCs, MPLS tunnels, or whatever
DJ> could bring down your entire peering fabric.

If designed improperly.  And a single router failure could bring
down an entire WAN, if said WAN were designed improperly.  Your
point?

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 <blacklist at brics.com>
To: blacklist at brics.com
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 <blacklist at brics.com>, or you are likely to
be blocked.