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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of E.B. Dreger Sent: Monday, July 01, 2002 5:12 PM To: nanog@merit.edu 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 <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.