On Wed, May 22, 2002 at 08:24:59PM +1200, Roger De Salis wrote:

Adding to "*THE POINT*, the principal advantage from a national perspective is that nz-only traffic may be effectively directed without being forced to transit the Pacific, in search of a peer (example above.net).

That's an advantage of peering within New Zealand. It's not an advantage of using route servers. Joe - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

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. 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. 2) Citylink is crap and unreliable, and prone to black hole traffic. Now I don't believe that this was what you meant, so do you want to have another go at explaining it to me. Dean On Thu, 2002-05-23 at 10:15, Joe Abley wrote:

On Tuesday, May 21, 2002, at 10:41 , Dean Pemberton wrote:

...

So I want to tackle the issue of the WIX and APE route servers. Any why some people just don't love them.

If a network sends a prefix to another network, they are inviting the other network to send them traffic.

If a network sends a prefix to a route server, they are inviting anybody who is able to receive routes from the route server to send them traffic.

If you have business or technical criteria for selecting people to peer with, there may be advantages to knowing exactly who you are inviting to send you traffic. In most places in the world organisations enter into unilateral contracts with each other before setting up peering. If you enter into a multilateral contract with exchange participants, it's hard to stop peering with other people without stopping peering with everyone.

Where the exchange fabric is more complicated than a single switch, there is also the risk that a network-layer topology constraint might block traffic between to networks when it is sent directly, but allow traffic between each network and the route server to flow normally (think multi-vendor, multi-switch exchange running bleeding-edge code from vendors with a shaky history of software stability and interoperability). If you follow a route learnt from the route server in that case, you will blackhole the traffic. Taking care to ensure that the traffic follows the signalling path can hence be useful.

Joe

- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

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

Would the responsible abuse desk own up and get this [l]user a cleaner? --- Return-Path: Received: from mta3-rme.xtra.co.nz (mta3-rme.xtra.co.nz [210.86.15.131]) by camelot.tdce.com.au (8.11.6/8.11.6) with ESMTP id g54A25u18413 for ; Tue, 4 Jun 2002 20:02:06 +1000 Received: from Pyybfvcgn ([210.86.46.56]) by mta3-rme.xtra.co.nz with SMTP id <20020604100130.GJST22047.mta3-rme.xtra.co.nz(a)Pyybfvcgn> for ; Tue, 4 Jun 2002 22:01:30 +1200 From: neil To: terry(a)tdce.com.au Subject: Some questions MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=C814830yxu420hTI24y628r7ZlLiT9 Message-Id: <20020604100130.GJST22047.mta3-rme.xtra.co.nz(a)Pyybfvcgn> Date: Tue, 4 Jun 2002 22:01:54 +1200 Parts/Attachments: 1 OK ~4 lines Text 2 OK 96 KB Audio 3 Shown 0 lines Text 4 103 bytes Application ---------------------------------------- [ Part 1, Text/HTML 4 lines. ] [ Not Shown. Use the "V" command to view or save this part. ] [ Part 2, Audio/X-WAV 128KB. ] [ Not Shown. Use the "V" command to view or save this part. ] [ Part 4, Application/OCTET-STREAM (Name: "ICQRebootDll.txt") 138bytes. ] [ Cannot display this part. Press "V" then "S" to save in a file. ] --- Terence C. Giufre-Sweetser +---------------------------------+--------------------------+ | TereDonn Telecommunications Ltd | Phone +61-[0]7-32369366 | | 1/128 Bowen St, SPRING HILL | FAX +61-[0]7-32369930 | | PO BOX 1054, SPRING HILL 4004 | Mobile +61-[0]414-663053 | | Queensland Australia | http://www.tdce.com.au | +---------------------------------+--------------------------+ - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

I think you may be letting your previous involvement with the WIX route servers colour your judgment slightly Dean! For what it's worth I agree with Joe's summary. If I were representing a largish ISP/Telco in NZ (I'm not!) I would have a responsibility to a bunch of suits, lawyers and shareholders who would all demand accountability and profit. It is difficult to demonstrate a financial advantage and to guarantee continuity of service to existing customers from an uncontracted peering with parties unknown. This implies no criticism what so ever of the operator of the peering point nor of the route servers. It must be said however that BGP's first decision process is to ensure a valid next hop. If that next hop to the first party is passed to a third party by a second party then the third party really has no guarantee that the next hop is still valid nor that it is reachable. Given the stable platform that is APE/WIX this probably isn't a major issue, but no matter which vendor/technology/code you choose shit still happens! Regards, Phill. 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.

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. 2) Citylink is crap and unreliable, and prone to black hole traffic.

Now I don't believe that this was what you meant, so do you want to have another go at explaining it to me.

Dean

On Thu, 2002-05-23 at 10:15, Joe Abley wrote:

...

On Tuesday, May 21, 2002, at 10:41 , Dean Pemberton wrote:

...

So I want to tackle the issue of the WIX and APE route servers. Any why some people just don't love them.

If a network sends a prefix to another network, they are inviting the other network to send them traffic.

If a network sends a prefix to a route server, they are inviting anybody who is able to receive routes from the route server to send them traffic.

If you have business or technical criteria for selecting people to peer with, there may be advantages to knowing exactly who you are inviting to send you traffic. In most places in the world organisations enter into unilateral contracts with each other before setting up peering. If you enter into a multilateral contract with exchange participants, it's hard to stop peering with other people without stopping peering with everyone.

Where the exchange fabric is more complicated than a single switch, there is also the risk that a network-layer topology constraint might block traffic between to networks when it is sent directly, but allow traffic between each network and the route server to flow normally (think multi-vendor, multi-switch exchange running bleeding-edge code from vendors with a shaky history of software stability and interoperability). If you follow a route learnt from the route server in that case, you will blackhole the traffic. Taking care to ensure that the traffic follows the signalling path can hence be useful.

Joe

- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog