UUNET peering policy

Tue Jan 16 06:57:39 UTC 2001

sean at donelan.com (Sean Donelan) writes:

> In the past, some providers have specified peering requirements such
> as "must use a Cisco 7000 with SSP".

Not only that, we used to insist on particular brands of DSU/CSU.  <winge>

> If you are concerned about congestion, you should specify a performance
> requirement covering congestion, not some internal architecture design
> of the other network.  How the other network chooses to solve the congestion
> problem should be up to them.

Congestion problems on the other guy's network are of course their problem,
and you're right that backhaul from the peering point "inward" is not something
a peering agreement ought to cover other than in the most general terms ("thou
shalt not bother to boost the speed of our peering connection if the only
effect it will have is to move the point of congestion one hop further toward
you" or some such).

I was referring, though, to congestion over the peering connection itself.
This is very much the proper domain of a peering agreement, since it controls
the benefit (or lack of such) each party will receive in exchange for their
effort.

Interestingly, some peering agreements insist on certain topological points
because one or both of the "peering partners" have weak backbones toward
some of their peering points.  For example, "if we reach 10Gb/s in Walla
Walla, then we agree to add the next 10Gb/s in some other city."

> By saying you should treat the other provider as a black box I mean you
> should be able to tell if the other provider is meeting or not meeting
> their performance requirements WITHOUT examination of how much they are
> paying for their circuits, what type of routers they are using, or how
> they design their internal network.

I completely agree.  (I changed your "with" to a "WITHOUT" above, btw.)
-- 
Paul Vixie <Paul.Vixie at MMFN.COM>
CTO and SVP, MFN (NASDAQ: MFNX)

AboveNet, PAIX, and MIBH are subsidiaries of Metromedia Fiber Network, Inc.