Cool - Thanks for that - Cleared your points up nicely. Now I need to hear from more people. Dean On Thu, 2002-05-23 at 11:01, Joe Abley wrote:
On Wednesday, May 22, 2002, at 04:35 , Dean Pemberton wrote:
Ok I'm trying to keep track of all the responses, so that Simon Blake can address as many concerns as he can.
Let me see if I can distil your one down.
Which one? I made two :)
1) If people can't be sure where every single prefix in a peering session comes from, then they shouldn't bother peering at all.
That's not what I meant.
If two organisations peer, then there is a business relationship between them, and an operational relationship. Each relationship probably has constraints.
For example, $large_US_operator might have some business constraints which dictate the kind of organisations they want to peer with, since to their way of thinking, every peer is a lost transit opportunity. Hence they might insist that to qualify for peering you need to offer service in a certain number of cities, and run a US-wide backbone of a certain capacity, etc. At a more basic level, the business constraints might specify a minimum wind-down period in the event that one party wants to stop peering.
Operational constraints might include timeliness in responding to support calls, network abuse policies, and technical policies regarding route propagation.
With a unilateral contract between two operators, such constraints are fairly simple to test, and the contract will specify appropriate actions if the constraints are not met. If your peer starts to fall short of what you require in a peer, you can stop peering with them. You can adapt your contracts to suit the individual requirements of individual peers.
With a multilateral contract between an operator and an exchange point, the point of enforcement and control is shifted to the exchange point operator. The exchange point suddenly becomes responsible for making sure that policies are followed, and you might lose the ability to de-peer with just one other operator if they are causing you headaches. You no longer have the ability to customise your contracts to individual peers. You lose control.
Sending routes to a route server for dissemination to other exchange point participants is a naturally multilateral exercise. The loss of control (especially in markets like Europe and the US where peering is big business, and where peering contracts are treated as assets) is a problem for lots of people. Popular multilateral peering agreements in the US and Europe are rare.
Now, formal contracts between peers in New Zealand might be the exception rather than the rule, but the principle remains. If you want to stop your prefixes propagating to $ISP because they are blackholing your traffic and their phone is continually busy, but your only means of peering is through the route server, then you either have to put up with the complaints from your customers or stop peering with everybody. You lose the ability to fix problems yourself.
2) Citylink is crap and unreliable, and prone to black hole traffic.
I was thinking of the LINX, actually, in London. They have a multi-site, multi-switch, multi-vendor exchange fabric over which these kind of phenomena are relatively common; they are about to split the exchange in half, in fact, one half exclusively Foundry and the other exclusively Extreme to avoid the interop issues. It's worth noting that the LINX shifts a lot of traffic, though, and hence their requirement for bleeding-edge switch interfaces (and consequently software) probably makes them more prone to this than other, simpler exchanges.
It's not an issue of being crap and unreliable, as the LINX is demonstrably successful and popular. A non-trivial layer-2 fabric which separates control-plane and data-plane traffic at layer-3 leaves you prone to black holes.
Now I don't believe that this was what you meant, so do you want to have another go at explaining it to me.
Joe
- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog