[195287] in North American Network Operators' Group
Re: BGP peering question
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jul 13 15:28:04 2017
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAPkb-7AkyicjjDKD6kOK=YZ-xxxh2Sb=OKridhqcfWktaxxGyw@mail.gmail.com>
Date: Thu, 13 Jul 2017 12:27:56 -0700
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
If you develop a well tuned process for creating BGP sessions and even a =
moderate
system for monitoring not the individual sessions, but meaningful =
traffic events on
your network, then, maintaining a large number of peers and a =
promiscuous peering
policy is not such a daunting process.
As a general rule, promiscuous peering improves efficiency and keeps =
your options for
traffic delivery open. Restrictive peering generally has the opposite =
effect.
Route servers are a lazy form of promiscuous peering, with an attendant =
fate sharing
which can produce suboptimal results. YMMV.
I=E2=80=99ve worked for several networks of various sizes and observed =
the industry in general
for many years. As a general rule, a restrictive peering policy is a =
great way to lose
momentum in the market and convert a major ISP into a bit-player (e.g. =
SPRINT), whereas
promiscuous peering can be a key component in moving a trivial ISP into =
a major player
in the industry (e.g. HE).
Again, YMMV.
Owen
> On Jul 13, 2017, at 11:04 , Baldur Norddahl =
<baldur.norddahl@gmail.com> wrote:
>=20
> Speaking as a small ISP with 10 to 20 Gbps peak traffic. We are heavy
> inbound as a pure eyeball network.
>=20
> We use the route servers. We only maintain direct BGP sessions with a =
few
> large peers. Think Google, Netflix, Akamai etc.
>=20
> The reason for this is simply administrative overhead. Every BGP =
session
> has to be configured and monitored. We know that it will not move a =
large
> percentage of our traffic. We simply do not have the ressources =
currently
> when the gain is so little.
>=20
> Anyone who wants to pass traffic efficiently to us can either use the =
route
> server or they can peer with Hurricane Electric. The later option will =
get
> the traffic to us almost as efficiently as peering directly with us. =
In
> this sense we outsourced the peering to them.
>=20
> Regards
>=20
> Baldur
>=20
> Den 11. jul. 2017 18.42 skrev "craig washington" <
> craigwashington01@hotmail.com>:
>=20
>> Hello,
>>=20
>>=20
>> Newbie question, what criteria do you look for when you decide that =
you
>> want to peer with someone or if you will accept peering with someone =
from
>> an ISP point of view.
>>=20
>>=20
>> Thanks.
>>=20
>>=20
>>=20
>>=20
