RE: Migration issues: route creation
Comment followed.
You can configure the software to resolve these references internally (by creating "dummy" objects). However, you cannot request "selective mirroring" for a particular types of objects.
What happen if you don't want to share some of the person objects ? At least, I believe APNIC has a policy to guard private information so they may not want to mirror the maintainer and person objects.
Referential integrity needs to be satisfied only within a single source. That is TEST1-MNT with RADB source and TEST1-MNT with the RIPE one are in fact different objects.
How about AS3561 in RIPE, ARIN and APNIC ? In reality this is the same AS ( assigned by ARIN but need to be present in RIPE and APNIC as well ) And this will be a route creation problem, we will need to register some route objects in RIPE that originates from AS3561 very soon. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
"Lu, Ping" wrote:
Comment followed.
You can configure the software to resolve these references internally (by creating "dummy" objects). However, you cannot request "selective mirroring" for a particular types of objects.
What happen if you don't want to share some of the person objects ? At least, I believe APNIC has a policy to guard private information so they may not want to mirror the maintainer and person objects.
I think one can filter out these objects from the mirroring stream while maintaining the correct sequence of serials.
Referential integrity needs to be satisfied only within a single source. That is TEST1-MNT with RADB source and TEST1-MNT with the RIPE one are in fact different objects.
How about AS3561 in RIPE, ARIN and APNIC ? In reality this is the same AS ( assigned by ARIN but need to be present in RIPE and APNIC as well ) And this will be a route creation problem, we will need to register some route objects in RIPE that originates from AS3561 very soon.
In current version of the database you also need to register the aut-num referenced by the origin attribute of a route object in order to register the object. Which leads to duplication of data for those ISPs that have address space and aut-num registered in different registries. Not perfect, I agree. But the problem with route creation in the new version of the database is that if we maintain the same level of security for the whole database (which means protecting the whole ASN space with as-block objects and IP space with corresponding inetnum objects) it will be _impossible_ to register respective aut-num or inetnum object in a normal way to authorize route creation (RFC2725). Another option could be that in order to allow "foreign" registrations we will maintain different levels of security (no as-block for ARIN ASNs, for example). Only routes from the RIPE address space and RIPE ASN will be properly authenticated and authorised.
Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
Regards, Andrei Robachevsky DB Group Manager RIPE NCC
participants (2)
-
Andrei Robachevsky -
Lu, Ping