[179800] in North American Network Operators' Group
No subject found in mail header
daemon@ATHENA.MIT.EDU (Paul Stewart via NANOG)
Thu May 7 18:22:07 2015
To: "'Mark Tinka'" <mark.tinka@seacom.mu>, "'Martin T'" <m4rtntns@gmail.com>,
<nanog@nanog.org>
In-Reply-To: <5549DF9D.8040109@seacom.mu>
From: Paul Stewart via NANOG <nanog@nanog.org>
Reply-To: Paul Stewart <paul@paulstewart.org>
Errors-To: nanog-bounces@nanog.org
Date: Thu, 7 May 2015 22:22:06 +0000 (UTC)
Return-Path: <paul@paulstewart.org>
X-Original-To: nanog@nanog.org
Delivered-To: nanog@nanog.org
Received: from host1.paulstewart.org (host1.paulstewart.org [45.55.171.145])
by mail.nanog.org (Postfix) with ESMTPS id 292352C02B0
for <nanog@nanog.org>; Thu, 7 May 2015 22:22:05 +0000 (UTC)
Received: from pstewartmobile (198-84-181-190.cpe.teksavvy.com [198.84.181.190])
by host1.paulstewart.org (Postfix) with ESMTPSA id 7FAC04B410;
Thu, 7 May 2015 18:22:03 -0400 (EDT)
From: "Paul Stewart" <paul@paulstewart.org>
To: "'Mark Tinka'" <mark.tinka@seacom.mu>,
"'Martin T'" <m4rtntns@gmail.com>,
<nanog@nanog.org>
References: <CAJx5YvEg5Jvna2_aiNHnnCqu-pAvwT08+fJv-ZZUVowBKADnRQ@mail.gmail.com> <5549DF9D.8040109@seacom.mu>
In-Reply-To: <5549DF9D.8040109@seacom.mu>
Subject: RE: disadvantages of peering with own IP transit customers
Date: Thu, 7 May 2015 18:22:02 -0400
Message-ID: <00ca01d08914$3ea3d560$bbeb8020$@paulstewart.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQI1fAgkLwv88ahoHAiOqkfvPbgf+wEn3LyznJ3xRXA=
Well said Mark ...
There's a certain large transit provider that this all the time and I =
never understood why ...
Paul
-----Original Message-----
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mark Tinka
Sent: Wednesday, May 6, 2015 5:32 AM
To: Martin T; nanog@nanog.org
Subject: Re: disadvantages of peering with own IP transit customers
On 6/May/15 11:20, Martin T wrote:
> Hi,
>
> what are the disadvantages of peering(announcing own and all customers
> prefixes) with own IP transit customers? One disadvantage is obviously =
> that amount of traffic on IP transit link is lower and thus customer=20
> pays for smaller amount of Mbps. On the other hand, this can be=20
> somewhat compensated with higher price per Mbps if the amount of=20
> traffic on the IP transit connection is lower. However, are there any=20
> other disadvantages/concerns when peering with own IP transit=20
> customers?
- Potentially odd routing if customers are unfamiliar with how BGP =
really works, i.e., upload from customer hits the commercial link, but =
return traffic to customer
follows the peering link since peering links generally have a =
higher LOCAL_PREF than commercial links.
- Since more traffic is return to (eyeball-heavy) customers, you =
increase investment on your peering side with no corresponding gain in =
revenue, as peering is,
well, free.
- Any special policies you accord to peers will now be enjoyed by =
this customer also, since they also are a peer.
- Issues that could be caused by deliberate inconsistent routing =
from the customer's part in an effort to direct more traffic into the =
peering link.
- Complicated controls you may put in place to ensure the customer =
does not abuse your network from a peering standpoint (or vice versa), =
e.g., Internet in
VRF's, peering in VRF's, e.t.c., and the issues that come with =
all that complexity.
- Complications with the commercial contract - a growth in your =
customer's traffic out of balance with how much money you're earning =
from them.
- Confusion between your customer, their account manager, the =
engineering team and the operations teams on how the service is meant to =
be delivered,
operated, billed for, e.t.c.
- A host of other things I haven't thought about.
All in all, don't peer with customers if you don't have to. That should =
be your #1 and #2 peering policy rules. Too much commercial and =
technical confusion will surely ensue.
Mark.
