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