RE: Peering - Benefits?

["Paul Stewart" <pstewart () nexicomgroup net>]

Absolutely... I can see us dropping at least one of the transit
providers over time - with current growth we might end up keeping all of
them to meet needs though.  Just depends on how fast traffic moves from
transit to peering versus how quickly our overall requirements grow
(pretty dramatic climb right now)....

And yes, with our peering costs - the unit costs drop off considerably
as they pick up so the longer term will be that peering will be
considerably more economical than transit even with long haul costs...

Cheers!

Paul


-----Original Message-----
From: Patrick W. Gilmore [mailto:patrick () ianai net]
Sent: Thursday, October 30, 2008 1:06 PM
To: NANOG list
Subject: Re: Peering - Benefits?

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.






----------------------------------------------------------------------------

"The information transmitted is intended only for the person or entity to which it is addressed and contains 
confidential and/or privileged material. If you received this in error, please contact the sender immediately and then 
destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."