At 10:25 AM 10/29/96 -0800, Kent W. England wrote:

But that still begs the question of adequate defenses against default-pointing and other bad effects and the business plan which still calls for all of this to go away.

One can point default at someone whether or not they are peering with the person. I am somewhat confused by the thought that people believe that they need to be peering with someone to have that person point default at them. I could (I don't, but I could), point default at /anyone/ on the same switch fabric as me, whether they are peering with me or not. Why do people continue to tie these 2 issues together?

I now take my large ISP hat off and return to the other side of the table. I find that many of these same problems affect me if I am a small or new ISP joining up to a public exchange like the NAPs or MAEs. Now I get 10 peering requests per week and I run down the list of issues and before I know it, I'm figuratively back on the other side of the table wondering how clueless the other party is.

The public exchanges are useful for a variety of things and they are and will remain important, but the pressure for private peering points is considerable as I outlined. Take your high bandwidth traffic to/from your true peers off to private interconnects and avoid the hassle of the public bazaar for that part of the bandwidth. The traffic level justifies high bandwidth pipes for private peerings.

My suggestion to newcomers and small ISPs is to help advance your cause by latching onto the route servers and RA contractors as a way to help yourselves and your backbone peers. You need a process which can demonstrate that you are addressing the issues I outlined above. If that process were to be

accepted by

all, then perhaps it would be easier to convince the backbones not to slow the peering process, but fix it and maintain it, while continuing private interconnects as warranted.

Flame away, but try to stay on point. (Please don't respond and say that the true figure is 50 peerings per week, even though it may be more accurate.)

--Kent Speaking as a PacBell NAP consultant.

Justin Newton Network Architect Erol's Internet Services