Peering is a lot of work.

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. :slight_smile:

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
and your backbone peers. You need a process which can demonstrate that you
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
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.)

Speaking as a PacBell NAP consultant.