disadvantages of peering with own IP transit customers
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 pays for smaller amount of Mbps. On the other hand, this can be somewhat compensated with higher price per Mbps if the amount of traffic on the IP transit connection is lower. However, are there any other disadvantages/concerns when peering with own IP transit customers? regards, Martin
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 pays for smaller amount of Mbps. On the other hand, this can be somewhat compensated with higher price per Mbps if the amount of traffic on the IP transit connection is lower. However, are there any other disadvantages/concerns when peering with own IP transit 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.
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 pays for smaller amount of Mbps. On the other hand, this can be somewhat compensated with higher price per Mbps if the amount of traffic on the IP transit connection is lower. However, are there any other disadvantages/concerns when peering with own IP transit 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.
participants (3)
-
Mark Tinka -
Martin T -
Paul Stewart