sean@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@MMFN.COM> CTO and SVP, MFN (NASDAQ: MFNX) AboveNet, PAIX, and MIBH are subsidiaries of Metromedia Fiber Network, Inc.