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
