On Wed, Nov 11, 2015 at 02:52:36PM +0100, denis wrote: > From what I understood from Gert and Randy's comments it is a user's > choice where to put a ROUTE object and there seem to be some reasons > why they sometimes choose to put it in the RIPE Database.
Be that as it may, I am not convinced (yet) that non-RIPE objects really have a place in the RIPE db. Given that today there _are_ non-RIPE objects in the RIPE db, we need to find a way to deal with those. All of us hate rogue objects and want to nail down security in such a way that the RIPE db no longer is a 'free for all to exploit' database. An example of a functional IRR does not allow foreign objects: APNIC. I've not heard of that policy leading to any issues. Randy has asserted in the past that some parties (IXPs?) require people to exclusively register in the RIPE database, but I have not found data supporting that idea so far. Even if there is an IXP who operates a route-server for which filters are build exclusively using RIPE's IRR database, that is a local choice made by that IXP to not look at other databases. I won't take a single IXP's decision to not look any further as a strong incentive to put the whole world's IRR in the RIPE database. Gert indicated that it might be beneficial for a single ASN to register all their routes (including non-RIPE space) in a single database. Gert's remark is a single datapoint, it is my personal opinion that there is no operational issue if networks spread their route-object registrations over multiple databases (e.g. APNIC space in APNIC IRR, RIPE space in RIPE IRR, etc). The benefit of pushing users to the most authoritve database is that 3 out of 5 RIRs can offer strong guarantees about the validity of a route-object if it covers space managed by that respective RIR. RIPE cannot offer the same strong guarantees as APNIC & AfriNIC can in their own IRR. Why would we not encourage the community to exploit those guarantees, and direct users to create those 'foreign' route-objects in the more authoritive IRR? > Is there some specific policy now that prohibits ROUTE objects in the > RIPE Database for AFRINIC resources? "IRR Homing" was influenced by two ideas: Nick Hilliard's "why don't we change the 'source: RIPE' line to something like 'source: RIPE-NONAUTH' for objects covering non-RIPE space" and the observation that there are 30.000 route-objects covering AfriNIC space in a database which _does_not_ offer guarantees on their validity, while at the same time there is a perfect IRR which _does_ offer those guarantees: AfriNIC's own IRR. At the time I thought it safer to first migrate AfriNIC's objects and then consider changing the "source:" attribute for non-authoritive objects. So, no such policy exists, but the IRR Homing proposal (which is in the making) will include the suggestion that creation of route-objects covering AfriNIC space at some point is no longer allowed, and instead people are referred to the AfriNIC IRR. As Tim mentioned, this is a proposal and the DB-WG will be tasked with reviewing the plan. Kind regards, Job
