Peering - Benefits?
Patrick W. Gilmore
patrick at ianai.net
Thu Oct 30 12:05:58 CDT 2008
On Oct 30, 2008, at 12:38 PM, Paul Stewart wrote:
> Thanks for playing devil's advocate... I am truly trying to cover
> sides of the discussion - technically it's what we want for sure but
> 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
> 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
> 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
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
> -----Original Message-----
> From: Patrick W. Gilmore [mailto:patrick at 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.
> 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
More information about the NANOG