Towards a Disjoint IRR

Dale,

Comments below.

Dale S. Johnson (dsj at merit.edu) on April 27:
> All,
> 
> 1) The PRDB is about to be retired.  (Oh?  You say you've heard that
>    one before?  ;-|   Quite possibly on Monday, May 8.  (Annoucements
>    will be made to rr-impl, as well as to nanog)).
> 
>    So:  If you are currently picking up prdb.db, please make sure you
>    are also picking up the radb.db and including it in ALLSEARCH so
>    that traceroutes (etc.) via your server will continue to work.
> 
> 2) We've talked about this informally before, but I'd like a group
>    discussion before we call it final:
> 
>    Once the PRDB route objects are copied/merged into the RADB,
>    should we purge all the RADB route objects that are duplicated
>    in other IRR databases?  Specifically, should we go through the
>    lists of routes registered in MCI.db, CA*Net.db, and RIPE.db,
>    and for each net registered in any of those dbs AND WHICH HAS
>    ADVISORY AS690 LINES, remove that net from the RADB?

I think this may be OK if the object in radb.db was created from
prdb. However, if it was created explicitly by someone in that domain,
we should not delete it.

(To be more explicit, Ripe is the European registry, but if a domain
in Europe also wants to register with RA, we should not say no, vice
versa.)

> 
> The advantage of pruning the RADB in this way is that the IRR becomes
> more disjoint:  generally, a route will be registered only in one 
> registry in the IRR.  Users will not have two (or more) updates to
> make for each route;  the possibility of conflicting information
> is greatly reduced.  [Enke and Craig are working on resolving *lots*
> of conflicts between the prdb.db and the mci.db as we speak].
> 
> The disadvantages of pruning the RADB include:
> 
> This is modification of user data on a massive scale.
> 
> Some users (e.g. multi-homed users) may need to be registered in more
> than one registry.
> 
> There is a possibility that the PRDB data is more up-to-date than the
> data in the other registries.  (The "changed date" is reliable in
> the prdb.db.  How safe is it to trust the RIPE changed dates, and
> to only delete PRDB-transferred nets that have older changed dates
> than what is in the other registries?)
> 
> 
> We can mitigate the Changing Users Data problem by sending out an
> announcement of this plan, and then asking for anyone who does *not*
> want their duplicated nets pruned from the RADB to send us a list of
> either the Origin ASs or the Route IPs that they want us to leave
> alone.
> 
> 
> My own feeling is that a disjoint IRR is the correct vision, and that
> this kind of pruning once, as a transition step from the PRDB, is
> an appropriate step.  (Especially with the announcement and exception
> list described above).

It is a bad thing to have the same data registered in multiple places
with conflicts, because one does not know which data to trust.
However, we should leave it to the users to decide which places to
register.

Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California
http://www.isi.edu/div7/people/cengiz.home



-------- Logged at  Fri Apr 28 23:24:21 MET DST 1995  ---------