Peering is a lot of work.

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

Justin Newton
Network Architect
Erol's Internet Services

I think this is due to the fact that Kent consults for PacBell NAP, which
is ATM, which requires a PVC between peers. The PVC is setup only if both
parties agree, it is torn down if one dissents.

Obviously things are different at a FDDI NAP.


At the PacBell Nap for instance, you *couldn't* just point default at anyone on
the same switch fabric -- because you need to set up a peering (mapping) within
the switching fabric first, before you do any route peering. Until this happens
there would be no unwanted traffic.