Joe's point about Merit is where this get's interesting to me. Obviously, WIX and APE should move to a Arbitrated network in my opinion, if you are providing the route server, then you provide the only rational filtering point. On the issue of running the database though, this data may well reach beyond the realm of WIX and APE and their customers, for instance NetGate could use it to Clear directly etc. Wouldn't it be nice if we could trust that ISOCNZ and DomaiNZ could provide a useful cost-effective and more regionally acurate alternative to Merit !!! Well, I'm allowed to dream aren't I !!! Arron Scott Telecom NZ On Wed, 10 Nov 1999, Joe Abley wrote:

On Wed, Nov 10, 1999 at 10:30:59AM +1300, Simon Blake wrote:

...

On Tue, 9 Nov 1999, Jamie Clark wrote:

...

WIX has obviously worked well without filters so far.

It comes and goes. Generally, it works fine, and that's probably a reflection on the stability of the NZ net, or at least, the bit that peers in wellington. In general, it's changes (additions of new peers) that can cause temporary hiccups (Actrix advertising 4000 prefixes yesterday being a good example).

Originally, there was only one peering point, in Hamilton. It used OSPF, which you couldn't filter, but that was generally ok because it was more important to connect people to the exchange quickly and easily than it was to worry about filtering problems. When your only route out is through the exchange, you don't necessarily need to worry much about filtering.

Now there are three exchanges as well as private peering links in the network, some operators have a choice of as many as six routes for their domestic traffic to take as it leaves their network. This requires some traffic engineering that previously was not particularly necessary.

The proliferation of domestic peering also means that finger trouble at one particular operator now has (in some cases) six times as many ways to cause problems for other operators, in a manner that is quite possibly six times harder to debug.

All this adds up to the fact that when Angry Customer calls up to find out why his Angry Customer can't talk to someone else's Angry Customer, you need some idea of how things _ought_ to look before you can figure out what has broken.

Publishing route policy makes that easier. It also makes it easier to filter with some confidence, which is also a good thing. If Atrix release 4000 prefixes into the network, and you pick them up and trust them, then it's your fault for not filtering. Don't yell at Actrix :)

The tools required to set up and run an RPSL registry are all freely available, but it _is_ something that needs to be set up professionally and run as such, in my opinion. A flaky database which contains out-of- date information because people can't update it is probably worse than no database at all.

Merit now charge US$200/year to keep records in their database. In the absense of a similar facility elsewhere (e.g. in NZ) that is as stable as Merit's, I would say that was good value for money.

...

My policy at the moment tends to vary, depending on the customer. If the peer is an ISP (ie, if they have their own ASN), then I assume they know what they're doing,

You missed out the ":)"

...

and I don't filter incoming or outgoing updates, unless requested by the peer.

Warning! Warning!

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