nanog mailing list archives
Re: Peering Policies and Route Servers
From: Matt Zimmerman <mdz () netrail net>
Date: Tue, 30 Apr 1996 15:10:13 -0400 (EDT)
On Mon, 29 Apr 1996, Michael Dillon wrote:
I think that you will find it much easier to get Sprint, MCI et al. to peer with you at multiple NAP's if you have a reputation and that reputation is a good one. The people at the large NSP's are rightly conservative at making new peering decisions because the network is now so big and so important to customers that they cannot risk significant network failure. If you want to peer, you will have to prove that your actions will not endanger the network fabric especially the fabric of the NSP who you are negotiating peering with. This is not an unsolvable problem.
There is no question of the risk involved in peering. Since caution is most often the best way to approach risk, it needs no justification either. What is being debated is whether or not the emerging policies of large NSPs reflect this approach. I would have no objection to a requirement of proof...it's requirements of money and resources that have small corporations complaining. [technical competence] [networking experience] [familiarity with current events]
In addition you have to develop a reputation of competence and this demands that you physically attend several NANOG meetings and perhaps some IETF's. There is nothing that can establish a reputation better than personal contact. Of course, once you become a face and not just an email address, even the "no" responses to a peering request are likely to lead to some more explanation of "why?" so that you can remedy the situation.
These are all valuable resources in running an NSP...these are, in fact, several of our goals here. Certainly some (most notably personal appearances) are limited by available resources, but all are necessary to some extent. However... - Is a small staff necessarily an incompetent one? - Is a company which has operated on a small scale necessarily doomed to failure in a large scale endeavor? - Does a scarcity of resources necessarily indicate an inability to efficiently utilize available resources? These all seem to be generalizations made by peering policies which discriminate against smaller providers. Meeting Sprint and MCI's peering conditions requires only minimal competence. What it takes is money.
The time required to go through these rites of passage will also allow you to get your national network infrastructure built out so it is not a loss. You *CAN* operate a national (or even international) network without peering agreements. You *CAN* grow into being an NSP. You may even discover that there are some benefits to multiple bilateral peering/exchange points as opposed to becoming yet another NSP at an octopus-like NAP.
For the record, I fully realize the value of peering at multiple exchange points. :-) Though it seems to have been interpreted as such, my crusade is not to win peering arrangements at a NAP. My whining serves the far larger (and more interesting) purpose of pointing out the arguable wisdom of certain policies (which just happen to be detrimental to the pursuit of my goals). // Matt Zimmerman Chief of System Management NetRail, Inc. // mdz () netrail net sales () netrail net // (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]
Current thread:
- Peering Policies and Route Servers Ali Marashi (Apr 29)
- Re: Peering Policies and Route Servers bmanning (Apr 29)
- Re: Peering Policies and Route Servers Ali Marashi (Apr 29)
- Re: Peering Policies and Route Servers Nathan Stratton (Apr 29)
- Re: Peering Policies and Route Servers M. Christopher Davies (Apr 29)
- Re: Peering Policies and Route Servers Nathan Stratton (Apr 29)
- Re: Peering Policies and Route Servers Jeff Young (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers M. Christopher Davies (Apr 29)
- Re: Peering Policies and Route Servers Michael Dillon (Apr 29)
- Re: Peering Policies and Route Servers Nathan Stratton (Apr 29)
- 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 bmanning (Apr 29)
- 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)
- <Possible follow-ups>
- 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)