![nanog logo](/images/nanog-logo.png)
nanog mailing list archives
Re: Peering Policies and Route Servers
From: avg () postman ncube com (Vadim Antonov)
Date: Tue, 30 Apr 1996 01:14:09 +0800
There are two good reasons to peer only with backbones of comparable size: 1) technical -- this allows to do hot-potato routing with minimal resulting delay assymetry 2) economical -- peering at IXP is favouring smaller folks in cost/benefit game. For a large ISP the percentage of additional destinations the small ISP offers is smaller, and so is the benefit of peering. ANd extra peerings are far from "free". They produce extra paths which need to be processed by routers, and so translate in shorter lifetime of the equipment -- which means very real money. It also reduces effectiveness of aggregation and increases risk of catastrophic failures (large ISPs spend significant part of engineering resources and practice rather strict controls on configuration process to ensure sanity of routing; they also have to _trust_ each other. Most of garbadge in routing tables comes from small ISPs, and is usually hard to fix (no 24hr NOC etc). So the "three IXPs" limitation is specifically designed to ensure equality of sizes (to a some extent), other provisions of BLIAs ("blia" is a common profanity in Russian, btw :) include 24hr NOC etc. Thus, far from being anti-competitive restrictions those policies only serve to level the playing field -- as players who skip investment in infrastructure, engineering and operations would get unfair advantage otherwise. No sane NSP would refuse peering with a new nationwide DS-3 backbone -- providing that it is something more than hot air. The plank is going to be raised to OC-3 pretty soon, though.... --vadim
Current thread:
- Re: Peering Policies and Route Servers, (continued)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers Enke Chen (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)
- Re: Peering Policies and Route Servers Elise Gerich (Apr 30)
- Re: Peering Policies and Route Servers Paul A Vixie (Apr 30)
- Re: Peering Policies and Route Servers Elise Gerich (Apr 30)
- Re: Peering Policies and Route Servers Paul A Vixie (Apr 30)
- Re: Peering Policies and Route Servers Paul Ferguson (Apr 29)
- Re: Peering Policies and Route Servers Curtis Villamizar (Apr 30)
- Re: Peering Policies and Route Servers Cengiz Alaettinoglu (Apr 30)
- Re: Peering Policies and Route Servers Steve Heimlich (Apr 29)
- Re: Peering Policies and Route Servers Vadim Antonov (Apr 30)
- Re: Peering Policies and Route Servers Peter Lothberg (Apr 30)
- Re: Peering Policies and Route Servers bmanning (Apr 30)
- Re: Peering Policies and Route Servers Tim Salo (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)
- Re: Peering Policies and Route Servers Paul Ferguson (Apr 30)
- Re: Peering Policies and Route Servers Rob Gutierrez (Apr 30)
- Re: Peering Policies and Route Servers Curtis Villamizar (Apr 30)
- Re: Peering Policies and Route Servers John Curran (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
(Thread continues...)