Towards a Disjoint IRR

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?

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).

Is there any disagreement with this?

--Dale

============ From: Enke Chen 

> From enke at mci.net Wed Apr 26 17:11:58 1995
> To: dsj at merit.edu
> cc: merit-ie at merit.edu, rr-types at mci.net
> Subject: Purge data from the RADB
> Date: Wed, 26 Apr 1995 17:11:22 -0400
> 
> Dale, 
> I know that people are working very hard on having the 
> discrepancies between the MCI RR and the PRDB (thus RADB)
> resolved.  That is a good thing.  But for near-to-longer term, 
> the concern we have here is how the data in the RADB would 
> be handled and how discrepancies would be resolved.  For 
> example, MICHnet now registers their route objects in the 
> MCI RR, and MICHnet only has connection to MCI.  Will the 
> data in the RADB related to the MICHnet be purged to avoid 
> discrepancies in the future?
> 
> It seems reasonable for the IRR to be distributed, and consist
> of (almost) disjoint information from the MCI RR, CAnet RR, 
> RADB (supports ANS config and others).  However, it is not 
> clear if the issue of multiple registrations can be avoided.  
> I remember that there was discussion about maintaining a list 
> of RR preference (or order of authorities) for each AS.  Is this 
> something in the plan?
> 
> This issues seem to be mainly releted to the RA.  But feel 
> free to forward to the rr-impl list if necessary. 
> 
> -- Enke



-------- Logged at  Fri Apr 28 21:49:48 MET DST 1995  ---------