Migration to RIPE 181

Michael,

  You're right;  there's a question here that I haven't answered.  But
the answer should be reassuring:  AS690 will continue accepting NACRs
and/or Route Objects as long as necessary.

  We will create yet another RIPE-181 database called "NSF-TRANS" which
take the function of the PRDB as long as necessary.  This means that
Merit will support the following RIPE-181 databases:

   RADB - "Routing Arbiter Database":  Our public portion of the IRR

   NSF-TRANS - What the PRDB is today, including route objects from
		 the whole world.  It will be preloaded from the
		 current contents of the Informix PRDB.

We also will continue to support

   PRDB.db - The "dump" of everything AS690 knows about in 181 format

until the IRR is stable and complete enough that PRDB.db is redundant
with the rest of the information.  (PRDB.db is currently the only source
of non-European data that is available to prtraceroute and similar
tools).

  Initially, we will just continue accepting net NACRs at nsfnet-admin@
merit.edu like we have always done.  We will mechanically translate these
to RIPE-181 route objects, specifying "source:  NSF-TRANS".  For a
testing period, we will update both the Informix PRDB and NSF-TRANS 
using the same input, and we will compare their output to make sure 
that the two systems are doing the same thing.  When we are comfortable
that this new system is working, we will turn off the PRDB and make
NSF-TRANS be the operational system generating AS690 configs.  Users
will not have to be aware of any of this;  they continue to submit
net NACRs just like they always have done, and AS690 configs continue
to be generated from these.  They will begin to notice some small
changes--reports are retired, rejection messages come from RIPE-181
software rather than from a human--but the basic system remains intact.
This is why we have not worried about being aggressive about announcing
the details of the changes.  (Not to mention we're still working on 
them...)

  Within this basic transition strategy, a couple of other things can
be happening on relatively independent timeframes.  We have talked to
all the large NSPs who are running RIPE-181 (i.e. MCI) about submitting
MCI.db instead of NACRs for their NSFNET clients' updates.  Merit then
has the choice of either including MCI.db directly in the config
generation process, or of writing a trivial script to generate NACRs
from MCI.db .  (We would be willing to do this kind of exchange with
other DBs who support the advisory attribute, too).

  Also, at any time in this process, we can start accepting RIPE-181
route objects instead of NACRs.  While the Informix PRDB is still 
running, we would just grab a copy of each of those and generate a
net NACR from that information.  This process could start any time
(even today) except for one issue:  we would need to require that
each such route object be prepended with the NSFNET AUP text and
certification.  We have a petition in to the U.S. Inspector General
to allow us to skip the AUP stuff, but it is very likely that we will
not get that permission.  We're not pushing the "send in a route template"
approach until this gets cleared up, although it would be good for us
to get a beta site or two to work with on trying this.

  So...  the basic answer to your question is we will continue
supporting the PRDB functions with a RIPE-181 database called
"NSF-TRANS" until the other supporting systems are ready to replace
this.  Europeans will continue having their providers submit net NACRs
to nsfnet-admin@ merit.edu like they have been since 1988 until RIPE
feels comfortable that the advisory attribute is fully ready and
populated in the RIPE.db.

  I think that is what you were asking?  

--Dale


PS:  Thanks for making me write this down.  :-)  (And my apologies
to RIPE for not writing this discussion down for them first, but
we have done most of this verbally and they are cc'd on the first
messages about it...)

Comments and reality checks from all parties more than welcome...

--Dale



> Dale,
> 
> Thanks for your reply. I take all your points, but I'm still not sure what
> Europeans then have to do, once the PRDB is retired, and the RIPE DB is not
> ready yet to support the advisory attribute for all European nets. Because
> then you cannot reasonably use the RIPE-DB, as the info there is not
> complete, but the Europeans can't send in NACRs either, because the PRDB
> doesn't exist any longer.
> 
> My view is that the RIPE-DB *has* to be ready by the time the PRDB retires
> to not mess things up for Europe. I do not see how we (in Europe) can
> reasonably work with a unfinished RIPE-DB and no PRDB any more. Do you?
> 
> Michael
> 
> 
> 
> At 5:46 pm 21/12/94, Dale S. Johnson wrote:
> >Michael,
> >
> >  I had been thinking that this transition to using native RIPE data
> >(with advisory attributes embedded) would be a second phase of AS690
> >configurations--probably near the end of February.  It would be good
> >to get an advance start on it, however.  This change will actually be
> >very little coding work for us (just take data from an additional
> >source).  It will have considerably more effect on RIPE and end-users.
> >RIPE will need to support the advisory attribute, probably go through
> >an initial mass-loading of it (coordinated with the users), and presumably
> >deal with questions about it for the next six or so months.  (Merit
> >will of course also be offering support).  Since this change will both
> >be visible to users, and will require changes in their behavior (e.g.
> >maintaining the advisory attribute in their route objects), it would
> >be good to get started on this quite soon.
> >
> >  If the advisory attribute was in the software and initial values
> >were in place for all routes, and if we decided that users had had
> >enough advanced notice and training, then we could probably make the
> >step of converting to this data very quickly after the PRDB is retired
> >in January.
> >
> >--Dale
> >
> >
> >> From M.H.Behringer at dante.org.uk Wed Dec 21 07:57:32 1994
> >> Date: Wed, 21 Dec 1994 12:58:01 +0000
> >> To: epg at merit.edu
> >> From: M.H.Behringer at dante.org.uk (Michael H. Behringer)
> >> Subject: Re: Migration to RIPE 181
> >> Cc: dsj at merit.edu
> >>
> >> Hi Elise,
> >>
> >> Thanks for your response. I just want to quickly verify something.
> >>
> >> At 1:53 pm 20/12/94, epg at merit.edu wrote:
> >> [...]
> >> >Yes, we have an agreement with the RIPE NCC that they will support the
> >> >advisory attribute.  I believe that when the RIPE NCC implemented
> >> >181, this was forseen.  I have copied Dale Johnson who has been
> >> >coordinating with Marten on this so he can correct me if I have
> >> >gotten it wrong.
> >>
> >> I know this is foreseen in the RIPE DB, and I know this has to be done
> >> (thats why I'm asking). Does this mean that by the 15th January the
> >> advisory attribute has to be in all RIPE DB route entries, and all networks
> >> that do not have this attribute by then will not be routed through NSFnet?
> >>
> >> Or will you still keep the current config for a while, to make sure none of
> >> the nets looses US connectivity. If so, when is the deadline for dropping
> >> this?
> >>
> >> >The goal is that no one will have to register twice.  We propose to
> >> >derive the AS690 configs from the RADB and the RIPE Routing Registry.
> >>
> >> Good.
> >>
> >> Thanks for your help, Elise,
> >>
> >> Michael



-------- Logged at  Thu Dec 22 18:44:18 MET 1994  ---------