Migration to RIPE 181

All,

I basically like Michael's plan.

My own preferance would be to announce that the RIPE DB would be updated
from the PRDB *twice*, though I realize that this might seem like gratuitous
touching of the users' data.  Here is the reasoning:

For every user, there is some correct place to update their data at any
point in time.  At the moment, Europeans have two places they need to
update route information:  the RIPE.db and the PRDB.  Theoretically,
every time they change anything about the route, they need to update it
both places if they have NSFNET connectivity.  (This is has been the
situation since the RIPE.db started operation).  As of some flag day,
these users must update their data in only one place:  the RIPE.db.
Flag days are terrible things operationally, it is much kinder to give
some kind of transition time.

What I would propose is that there be an initial day when the RIPE.db
gets loaded with AS690 advisories, as Daniel suggests.  This will be
a user-visible change, but it will not affect anything operationally.
All the old processes still need to be followed that result in NACRs
being submitted to the PRDB, and the PRDB information will be what 
really ends up in the config files.  This change will bring some user 
visibility to the upcoming real change, however.

During this time, users would be encouraged to update the Metric:AS
lists in both the RIPE.db and the PRDB at the same time, so that the
two copies of the data remain in synch.  In fact, changes won't be made
much except for new nets:  Metric:AS lists don't change much unless a
net changes providers, and that isn't happening much in Europe at the
moment (unlike the US where many networks are moving from ANS to
others).  This procedure would give an awareness of what is coming up,
though; gets people used to having AS690 Metric:AS lists in their route
objects;  gets them to ask the necessary questions, etc. before the
real change.

At some flag day called "When AS690 begins using registrations directly
from RIPE", we make one more copy of the Metric:AS lists form the PRDB
to RIPE.db .  This assures that the actual data that has been used to
configure AS690 up to the last day continues to be the data that
configures AS690 the day after the cutover.  From this day on, any user
attempting to make a modification to a European net via an update to
the PRDB or RADB gets a note saying "Authority for your data has been
moved to the RIPE.db;  please make your update there."  

Alternatively, it would be possible to ignore the out-of-synch database
problem, and allow some users who updated one database but not the other 
during the transition period to suddenly lose connectivity.

I don't feel strongly about variations on this plan, but the "update
twice" approach seems to me to give the users the longest time to get
used to the new approach, and it minimizes disruption by minimizing the
number of nets that will get dropped on the flag day by copying the
operational data at the same time that the system begins to trust the
new (RIPE.db) data source.

Thoughts?

--Dale

----------

Note:  the situation is considerably simpler with MCI, since MCI is
the entity that is responsible for those Metric:AS lists for their
customers in the first place.

Note2:  we don't have a much more code to produce to be able to generate
AS690 configs from the IRR, so the transition could be pretty soon.  On
the other hand, this is a really major philosophical transition, and we
haven't gotten into the comparative testing yet (update both databses
from the same NACR input stream to see what happens).  The current NSFNET
scheme has a *lot* of ack-checking, and some ISPs are indeed holding nets
hostage when they try to move to other providers, etc.  This will all
change when folks make their own updates directly, and there is less
to prevent security breaches such as a user stealing someone else's 
net.  I can imagine this kind of issue getting messy just as we prepare
to go into production;  hence I'm not confident that the transition won't
slip a bit more.




> From M.H.Behringer at dante.org.uk Wed Dec 28 09:32:57 1994
> To: Daniel Karrenberg <Daniel.Karrenberg at ripe.net>,
>         Tony Bates <Tony.Bates at mci.net>
> From: M.H.Behringer at dante.org.uk (Michael H. Behringer)
> Subject: Re: Migration to RIPE 181
> Cc: Marten Terpstra <Marten.Terpstra at ripe.net>,
>         ca at cs.umd.edu (Cengiz Alaettinoglu), "Dale S. Johnson" <dsj at merit.edu>,
>         epg at merit.edu, rr-impl at ripe.net
> 
> Daniel,
> 
> I suggest you put out a plan on the RIPE list (or RIPE-op?) for
> automatically switching the advisory attribute, and ask if somebody would
> object if you did the change automatically for the whole DB. Honestly, I
> cannot imagine someone objecting to that. You should set a deadline for
> objections, say the 13th January (Fri), and if there are no major concerns,
> it could be done fairly soon afterwards, say the 16th (monday). (dates are
> suggestions only)
> 
> This way we could make sure that the RIPE DB contains all needed
> information when the PRDB is retired (note: I don't say the RIPE-DB is
> "ready" ;-) . I very strongly feel we should have the RIPE DB up-to-date
> when the PRDB is retired. And I don't think this should be a problem.
> 
> Michael
> 
> 
> At 2:00 pm 28/12/94, Daniel Karrenberg wrote:
> >  > Tony Bates <Tony.Bates at mci.net> writes:
> >  > We are going to automatically add an advisory
> >  > line to all routes here based on the PRDB to get it bootstrapped.
> >
> >This is right for you.
> >I would be in favour of doing the same in the RIPE RR were it not
> >that we would have to touch other people's data which we consider
> >a big nono.
> >
> >There are two possibilities:
> >
> >        - we do it anyway
> >
> >        - we generate suggested data which the maintainers concerned
> >          can then send in or modify as required.
> >
> >Either should not be a big deal.
> >
> >Comments?
> >
> >Daniel



-------- Logged at  Fri Dec 30 16:34:30 MET 1994  ---------