On Wed, Sep 11, 2002 at 06:48:08PM -0400, Joe Abley said:
On Thu, Sep 12, 2002 at 10:02:10AM +1200, Simon Blake wrote:
On Wed, Sep 11, 2002 at 05:10:39PM -0400, Joe Abley said:
Just out of interest, what's the benefit in running yet another RPSL database?
WIX has 50+ private ASN peers, AFAIK you can't put info about private ASN into the public RPSL services, so if you want the value RPSL provides for private ASN (and I ohh so do), you run your own database.
... or you use globally-unique ASNs. Using private ASNs for non-private applications is surely broken, especially when it's so trivial to obtain a globally-unique one.
From my perspective, it *is* private usage - I want RPSL to manage the peers of the route servers on APE and WIX. If it gets used in a wider sense by the NZ Internet, then that's well and good.
You might argue that it's inefficient use of a finite resource for enterprises (in the AS1918 sense) that are not transit providers to be allocated globally-unique ASNs, and I might agree with you. That's not a problem that's going to be solved in New Zealand, though; that's a problem that will be managed by IANA and the RIRs with allocation policies until someone comes up with a multi-homing and routing system that scales better than the one we have.
Surely. But we all work with the tools we have, and there is a perception that global ASN are hard to obtain. I don't know if that's true (I haven't asked for one for years), but the perception is still there.
I'm not talking about ingress filtering done by the WIX route servers. By "responsibility for the quality", I mean:
+ having a route propagation path which is different to the packet forwarding path, which is a general problem of route servers on non-trivial layer-2 exchange fabrics;
Sure, but that's an equally good arguement for fixing the exchange fabric, since if you're under some kind of partial reachability cloud, then you're not getting full value for your connection anyway. WIX has never had such problems (presumably because its L2 fabric is primarily under the control of a single administrator). I have seen it happen on APE a couple of times though, so I agree that it is an issue. Eitherway, I think it's a compelling argument to fix the fabric, rather than abandon route servers.
+ having no contract/support relationship/whatever between operators connected to the route server, which is a general problem of multi-lateral peering.
Sure. We have various contracts available if people want to look at them, but generally, people don't. Funny, that :-). We're not seeking to supplant bilateral peering with the route servers, and we never will. What I am seeking to achieve is "lowest common denominator" peering where every entity attached to WIX/APE can advertise routes that it regards as "free", and listen to the "free" routes from other peers. Every entity can define "free" in whatever way it likes, and "none of my routes", "all of my routes" and "local Wellington or Auckland routes" are all valid definitions.
Nope. I don't remember making any comments ever about what ingress policy you were using for the route servers. I do remember making comments about it being generally hard for *other* people to come up with a sensible ingress policy for their session to the route server, though, which is quite different.
Sure, and I believe the RPSL stuff we've got planned with Andy will go a long way to helping peers make sensible ingress policy for their route server sessions.
I was objecting to the idea that operators who don't use the route servers must be bad or stupid, or be otherwise unworthy of attracting customers, because I don't think that's reasonable; there are arguments for not using them, just as there are arguments *for* using them.
Undoubtedly. I just think the arguements for peering with the route servers are significantly stronger than the arguements for not peering with the route servers, but then I'm biased :-). Cheers Si - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog