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