On Oct 30, 2008, at 12:38 PM, Paul Stewart wrote:
Thanks for playing devil's advocate... I am truly trying to cover both sides of the discussion - technically it's what we want for sure but the top of the food chain looks beyond just what a technical team wants to do as I'm sure we're all plagued by sometimes ...
In our specific case, after factoring in ALL costs in an extensive analysis - transit and peering end up very close .. peering being a very slight amount above transit in our case. At the end of the day it's almost a moot point from a cost perspective (you can tell I'm not a bean counter lol)
If it is break even, the "intangibles" of peering clearly make it a winner. Plus, as traffic increases, I bet the "cost" of peering goes down. And everyone's traffic is increasing.
I would argue though that even with 4 transit providers (which we have now), that peering is an excellent venue to take on - even for the time/management involved. Of course that opinion I can only speak for our situation in that regard..;)
Perhaps dropping to 3 or even 2 transit providers is in order when you start peering? That would allow you to give larger commits, reducing unit costs. You still have plenty of vectors if you can peer off a significant fraction of your traffic. For instance, lets say you can peer at least 25% of your traffic (a pretty modest amount). If you split your traffic evenly across four providers, this lets you drop one with no loss of redundancy. Plus you get all the other things peering is good for. -- TTFN, patrick
-----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Thursday, October 30, 2008 12:15 PM To: NANOG list Subject: Re: Peering - Benefits?
On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote:
so far there have been some good values articulated and there may be more (reach, latency, diversity of path, diversity of capacity, control, flexibility, options, price negotation) and some additional costs have been mentioned (capex for peering routing, opex for the peering itself + cross connects + switch fees + additional time spent troubleshooting routing events).
are there others?
Almost certainly.
But I'm sure the OP has a nice list to at least get him started of peering benefits. Interestingly, no one has mentioned the downside of peering. Just to play devil's advocate, allow me to mention some "cons" about peering: If you drop all peering and push traffic to transit providers, you can frequently get lower price per bit. Picking 2/3/4 transit providers and committing large amounts to them gives you flexibility, control, reliability, lowers your CapEx, and lowers your network complexity which can (should) lower your OpEx. There are others, but you get the point.
Just be sure to consider everything when deciding whether to peer.
-- TTFN, patrick
P.S. Obviously, I think peering is better for the "network" I run, but that cannot and should not be generalized to every network on the Internet.