At 18:00 +0000 2/6/98, Arron Scott wrote:
I would be interested to know what scenarios people have for using such a database. NetGate currently has a fairly complex routing table, and yet our boundary routing inside New Zealand still remains fairly simple.
Relatively simple perhaps, but as Rowan recalls we have had unpleasant enough problems all the same, and, for example, on several occassions we have been asked to "fix the routing errors on the NZIX" (and we have to explain that currently there is no simple nob to turn for such a fix). I also worry that we have been lucky so far, the potential for melt down exists (e.g., the AS 7007 disaster).
I am also slightly concerned that having these entries in a database would infer some "right of ownership" for certain address space, which would do the concept of hierarchical routing a server disservice. From my experience, any time someone enters a new entry in the RADB, even if it is a "black hole" from someone elses CIDR block they feel it gives them a right to use that given address space indefinately.
I agree there is a dangerous disconnection between the provider based address allocation administered by the registries and the controls operated within the IRR (not to mention the exposure from the number of backbone ISPs that don't even use the IRR). I gather this issue has been raised on a number of occassions but the failure to reach an agreed solution I suspect represents the true state of loose ends and grief in full implementation of provider based addressing (everywhere, not just in NZ). At 20:05 +1200 2/6/98, Rowan Smith wrote: ...
The issue arrises (as you have mentioned) when we register "our" IP Addresses against our AS. Most ISPs still have legacy IP space which "belongs" to the larger /16, /15 etc that netway currently advertise, this usually comes from companies which don't want to change.
These are hard problems but perhaps an open and frank discussion of the (I believe major) benefits of route information coordination, could help set the scene for resolution of address "ownership" angst. Surely it would represent a a serious failure of inter-provider coordination to have to live with network fragility just to avoid clear expression of what routing operator's believe they should have.
I would like to have the addresses which these organisations have been allocated by Apnic (nznic at the time), routed with our AS number. And as such stored in a database with my AS so that other local bodies that I peer with may use this information to build reliable filter-lists.
This would be advantageous to a company like ICONZ, where by if a major international outage occured (heaven forbid :), with our supplier then we would be able to come to some arrangement with another ISP that we peer with to use their international capacity albeit at a decreased performance level, this could be acheived simply by changing some routing filters, assuming that all the appropriate entries were in the RADB(s).
Indeed if ISPs currently build ad hoc filters to implement their view of the routing world in NZ, this would likely fail to handle major (and relatively rapid) changes in toplogy.
Education is required to ensure that people don't think that they own a certain IP address range indefinitely. As the internet requires the addresses to be aggregated organisations need to know this, and understand why. I think that this has been shown by the recent campaign to bring the 190.xx (or what ever it was) range back into some real size perspective.
There are enough cases already where "education" does't appear to have shifted strongly held views about address ownership, and New Zealand is no different here to other countries - pointing out the global initiatives should help but the difficulties are all too real. Again I would argue that implementation of route registry based controls would help illuminate the issues (and "Sunlight is the best disinfectant"). John --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog