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