Peering - Benefits?

Thu Oct 30 17:05:58 UTC 2008

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 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.
>
> -- 
> 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.
>
>