Migration issues: route creation

Further into the subject.

About the new RIPE-DB software V3.X, is that a requirement when mirroring we
have to import
ALL the objects in order to satisfy the database referencial integerity ?

For example, when we mirror with RIPE, if the route object point to a mntner
object (thru mnt-by ) do we have to have that mntner object imported also ?

If the answer is YES then does a mirroring agreement mean we have to share
all the objects ?


Ping Lu
Cable & Wireless USA
Network Tools and Analysis Group
W: +1-703-292-2359
E: plu at cw.net


> -----Original Message-----
> From: Lu, Ping [mailto:plu at cw.net]
> Sent: Monday, February 12, 2001 10:27 PM
> To: 'SchmitzJo at aol.com'; andrei at ripe.net; reimp-mig-tf at ripe.net;
> db-wg at ripe.net; routing-wg at ripe.net
> Subject: RE: Migration issues: route creation
> 
> 
> I think that's me :) Let's talk about the GLOBAL issues and 
> the practical
> use of RR.
> 
> For all RIRs like RIPE, ARIN, APNIC and so on. They are in a 
> regulartory
> position so they OWN  all the objects (AN, PN, MT) and they 
> seldom need to
> CROSS-REFERENCE with other RIRs. So the self-contained assumption (all
> references should be resloved locally ) is fine with RIR.
> 
> But for the LIRs (especially the ISPs) RR has a more 
> practical use, like
> auto-generated access-lists and as-path filters. Almost all 
> the major ISPs
> have their own tools or use the public tool like RAToolSet to 
> pull data from
> RR then auto-generate the configiuration for their routers.
> 
> Now here is the fun part.
> 
> As a global player we have to create a list of objects ( AN, 
> RT ) from all
> the RIRs and with any public peer (registered in one of the 
> RIRs ) we have
> to create a list of rather private objects ( MT, PN, RO ). 
> But it becomes
> too difficult to duplicate those private objects with  up-to-date
> information, so the best way is to REFERENCE their LEGAL 
> objects in any one
> of the RIRs ( of course if the AS itself agree us to do so ). 
> This is where
> the GLOBALLY UNIQUE nic-hdl comes in and in a more generic 
> sense, how about
> GLOBALLY UNIQUE maintainer name ?
> 
> Does this sound like domain name system ? Sooner or later RR 
> has to face the
> GLOBAL issue like DNS, IP address and E-MAIL did.
> 
> We have already seen some of the global issues showed up in 
> the RR domain (
> referral, globally unique nic-hdl ) and there will be more and more
> name-collision in the future.
> 
> So why not adopt a naming system like DNS or E-MAIL ?
> 
> Here is my favorite quote from RFC2622
> -----------------------------------------------------
>    <nic-handle> is a uniquely assigned identifier word used 
> by routing,
>       address allocation, and other registries to 
> unambiguously refer to
>       contact information.  Person and role classes map NIC handles to
>       actual person names, and contact information.
> -----------------------------------------------------
> 
> Hmmm! So RPSL already specify the need to use information from OTHER
> REGISTRIES. 
> 
> I rest my case.
> 
> Ping Lu
> Cable & Wireless USA
> Network Tools and Analysis Group
> W: +1-703-292-2359
> E: plu at cw.net
> 
> 
> > -----Original Message-----
> > From: SchmitzJo at aol.com [mailto:SchmitzJo at aol.com]
> > Sent: Monday, February 12, 2001 7:32 PM
> > To: andrei at ripe.net; reimp-mig-tf at ripe.net; db-wg at ripe.net;
> > routing-wg at ripe.net
> > Subject: Re: Migration issues: route creation
> > 
> > 
> > Dear Andrei,
> > 
> > you wrote that there will be problems creating duplicates of 
> > aut-nums and 
> > routes in other registries if they do not formally belong 
> > there due to the 
> > authorization rules introduced with the RPSL transition at 
> RIPE. You 
> > suggested two solutions:
> > 
> > > Possible solutions to this problem are:
> > >  
> > >  1. Send such registration requests to the Database Administration
> > >  (ripe-dbm) who will perform registration by overriding 
> > security (and
> > >  performing necessary checks before). This puts additional load on
> > >  ripe-dbm and creates duplicate objects in the RIPE database and
> > >  "foreign" IRR.
> > >  
> > >  2. Do not allow such registrations. In this case some ISPs 
> > will need to
> > >  change their peering policy and accept routing information from a
> > >  "foreign" IRR.
> > >  
> > >  Your comments and suggestions are highly appreciated.
> > >  
> > I did not yet see an answer to your question. However, I 
> > believe that your 
> > first suggestion should *not* be followed. I definitely would 
> > want to avoid 
> > opening "side" paths to enter data into the RIPE database. 
> > Using ripe-dbm 
> > should be the exception for special requirements. For 
> > everything else, the 
> > robots should be used.
> > 
> > Regarding duplication: this had originally been introduced to 
> > help people 
> > along while mirroring was not working. With RIPE having 
> > transitioned to RPSL, 
> > we will have compatible formats again, and do not need 
> > duplication anymore - 
> > under the prerequisite that you are properly coordinating 
> > with RADB and any 
> > other major IRR. I am inclined to say, that avoiding 
> > duplication is the 
> > purpose of the effort!
> > 
> > Looking at your second proposal, I believe that you are 
> > saying the right 
> > thing, but phrased it a little different. Peering policy is 
> > probably a term 
> > which may be confused with routing policy - and nobody needs 
> > to change its 
> > routing policy by looking at several IRRs now. Actually, I 
> > believe that there 
> > is not much of an issue: Smaller ISPs have always registered 
> > in only one IRR; 
> > only bigger providers with international reach have entered 
> > their information 
> > into several IRRs and duplicated data, but then also using 
> > data from all IRRs 
> > they registered into. It should not be too much of a pain 
> to use this 
> > information to continue with this practice after the RPSL 
> transition.
> > 
> > Those parties who do not agree, speak up loudly now!
> > Thanks
> >    Joachim
> > 
> > --- JS395-RIPE -- standard disclaimer ---
> > 
>