Towards a Disjoint IRR

  > "Dale S. Johnson" <dsj at merit.edu> writes:
  > 
  >    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 

I am in favour as far as the RIPE RR is concerned.
A few observations:

+ Changed dates can generally be trusted.

+ We have no (or only very few) north american data.
  We will purge it after coordination with the user if 
  we come across it.

+ If you suspect you have newer data, please tell the user asking where he
  wants to be registered. If the user is European suggest registering in
  the RIPE RR.

  >    AND WHICH HAS ADVISORY AS690 LINES, remove that net from the RADB?

Usually we are not happy about modifying user data. After requests from
our users and some evaluation we are prepared to make an exception for
the 'advisory: AS690' attributes, provided we can receive a complete list
of them from you at the flag day. We will then add those to the RIPE RR
and tell the users.

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

That is why I like it.

  > The disadvantages of pruning the RADB include:
  > 
  > This is modification of user data on a massive scale.

This is only a problem if the data was really added by the users and not
derived from something else.

  > Some users (e.g. multi-homed users) may need to be registered in more
  > than one registry.

So what?

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

That is a possibility. I would like to see the others flagged as well
though.

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

That's what we will probably do w.r.t. the advisory: AS690 thing.

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

Yes.


Daniel



-------- Logged at  Mon May 1 18:15:35 MET DST 1995  ---------