At 04:21 PM 26-10-96 -0400, Robert Laughlin wrote:

I am trying to feel sorry for the poor burdened Large ISP.....:)

I sincerely do feel sympathy for those large ISP network engineers. I see their faces at NANOG over the years and wonder when they will ever get out from under it all. Sometimes I'm sure it feels like they would only ever be free of the pressure if they were to slip an ampersand in the wrong place in a cisco config file. :-) Being sympathetic, I could present some arguments in favor of private peerings from an outsider's point of view. 1) Workload. If I get 20 peering requests per week, how many are significant in terms of traffic flows? 2) Cluelessness. If I get 20 peering requests each week from people I never heard of, how do I estimate my level of effort to complete a standard agreement? 3) Damage. Since any peering I setup is subject to default-pointing, BGP route flaps, inaccurate prefix data, and a host of other problems that I find difficult to proactively defend, how much work am I going to take on maintaining any given peering? See 2) above. 4) Provisioning. With 20 peering requests per week, what is my level of effort for their provisioning process? How much work will I have to expend while my peer gets their connections up, their routers running, and their end of the BGP session going? 5) Staffing. How do I explain to my boss the value of putting 1.5 FTE on peering agreements out of my total staff of 3 FTE, when he is anxious for me to complete my AGS+ swap-out, my DS-3 backbone buildout, and the web farm facility? Sometimes I worry that the big ISPs are going to stop peering altogether (actually they stop and start) and sometimes I wonder why they keep going turning the crank on endless peerings with telcos, CAPs, regional ISPs, garage ISPs, Web-farms-masquerading-as-ISPs, etc. Of course, it's because it's good for business when market shares are less than 15%. Now, on the other hand, if there were a process (and it is forming) whereby an ISP went through a natural process registering routes, setting up connections, peering with the route server, attending NANOG tutorials given by the Routing Arbiter, reading the drafts and RFCs, asking questions of the route server support staff... it might be a whole lot easier to turn the crank on a lot of peerings and perhaps the backbone ISPs would start to think that this is the way to handle 20 peer requests per week. 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. 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.