North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Peering - Benefits?

  • From: Patrick W. Gilmore
  • Date: Thu Oct 30 13:06:07 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:[email protected]]
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.