RE: RIPE DB transition and RFC2725
Finally somebody express the same concerns as ours. I have a discussion with the RIPE staff at the RIPE-38 meeting about this. There are two seperate issues here: 1. The RFC doesn't say a implementation (like RIPE-DB v3.0) should allow foreign references ( using objects from other RR database) or not. 2. The assumption of RIPE-DB v3.0 is that all object references have to be resloved locally( ie. with source: RIPE). The 2nd issue means if any ISP with ARIN's AS number want to register a route with RIPE you have to register your PN(person) then your MT(mntner) then your AN(aut-num) with RIPE first. So each ISP has to maintain a different set of objects with each RR. AS123(in RIPE) -> MNT-AS123-RIPE -> NIC456-RIPE AS123(in ARIN) -> MNT-AS123-ARIN -> NIC456-ARIN AS123(in APNIC) -> MNT-AS123-APNIC -> NIC456-APNIC AS123(in JP) -> MNT-AS123-JP -> NIC456-JP AS123(in DE) -> MNT-AS123-DE -> NIC456-DE .... Just to remember to update all these information everytime there is a little tiny change. It is fun, isn't it ? And NO you can't get all route information from just one RR unless we all sit down and seriously talking about the GLOBAL issues. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu@cw.net
-----Original Message----- From: Frank Bohnsack [mailto:Frank.Bohnsack@de.uu.net] Sent: Friday, March 09, 2001 7:43 AM To: db-wg@ripe.net Subject: RIPE DB transition and RFC2725
Dear colleagues,
Yes, I know the deadline for transition comments is over, but after studying RFC2725 we need a confirmation for our understanding.
RFC2725 defined the need for an "as-block" object for each related "aut-num" object and an "inetnum" object for each related "route" object.
The assignment of AS blocks and IP space is managed by IANA. * http://www.isi.edu/in-notes/iana/assignments/as-numbers * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space
Does the new RIPE DB manage only "as-blocks" and "inetnums" which are assigned to RIPE ?
1/ And if I'm right, is it true that we can't store our ASes 702, 1270 and a lot of routes (assigned to ARIN) in the new RIPE database ?
2/ And is it true that we therefore can't set our route (assigned to RIPE) objects origin to our ASes ?
The solution for 1/ is moving to ARIN, but what might be the solution for 2/ ?
You say a big ISP is anyway talking to multiple IRRs, but I think customers who want to peer with these can't get complete information while using RIPE DB only.
Cheers Frank
-- Frank Bohnsack email fb@de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net
At 10:58 -0500 9/3/01, Lu, Ping wrote:
And NO you can't get all route information from just one RR unless we all sit down and seriously talking about the GLOBAL issues.
Yes indeed. I would love to see the day where the 3 RIRs can run an rps/rps-auth compliant whois server (independently of the code base used to do it). Even if people still register with the RADB, having the IP address and autnum information available in a common standard format would enable quite a few things. Joao
Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu@cw.net
Lu, Ping (plu@cw.net) on March 9:
Finally somebody express the same concerns as ours.
I have a discussion with the RIPE staff at the RIPE-38 meeting about this.
There are two seperate issues here: 1. The RFC doesn't say a implementation (like RIPE-DB v3.0) should allow foreign references ( using objects from other RR database) or not.
RFC does not prohibit foreign references. As a matter of fact, RIPE has a workaround that does this. Please also see the companion RFC RFC 2769 for making RFC 2725 checks across registries. RFC 2769 and 2725 together yield a global distributed registry. Of course, it requires cooperation form other (at lease regional) registries.
2. The assumption of RIPE-DB v3.0 is that all object references have to be resloved locally( ie. with source: RIPE).
The 2nd issue means if any ISP with ARIN's AS number want to register a route with RIPE you have to register your PN(person) then your MT(mntner) then your AN(aut-num) with RIPE first.
So each ISP has to maintain a different set of objects with each RR. AS123(in RIPE) -> MNT-AS123-RIPE -> NIC456-RIPE AS123(in ARIN) -> MNT-AS123-ARIN -> NIC456-ARIN AS123(in APNIC) -> MNT-AS123-APNIC -> NIC456-APNIC AS123(in JP) -> MNT-AS123-JP -> NIC456-JP AS123(in DE) -> MNT-AS123-DE -> NIC456-DE ....
Just to remember to update all these information everytime there is a little tiny change. It is fun, isn't it ?
And NO you can't get all route information from just one RR unless we all sit down and seriously talking about the GLOBAL issues.
Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu@cw.net
-----Original Message----- From: Frank Bohnsack [mailto:Frank.Bohnsack@de.uu.net] Sent: Friday, March 09, 2001 7:43 AM To: db-wg@ripe.net Subject: RIPE DB transition and RFC2725
Dear colleagues,
Yes, I know the deadline for transition comments is over, but after studying RFC2725 we need a confirmation for our understanding.
RFC2725 defined the need for an "as-block" object for each related "aut-num" object and an "inetnum" object for each related "route" object.
The assignment of AS blocks and IP space is managed by IANA. * http://www.isi.edu/in-notes/iana/assignments/as-numbers * http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space
Does the new RIPE DB manage only "as-blocks" and "inetnums" which are assigned to RIPE ?
1/ And if I'm right, is it true that we can't store our ASes 702, 1270 and a lot of routes (assigned to ARIN) in the new RIPE database ?
2/ And is it true that we therefore can't set our route (assigned to RIPE) objects origin to our ASes ?
The solution for 1/ is moving to ARIN, but what might be the solution for 2/ ?
You say a big ISP is anyway talking to multiple IRRs, but I think customers who want to peer with these can't get complete information while using RIPE DB only.
Cheers Frank
-- Frank Bohnsack email fb@de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net
Cengiz -- Cengiz Alaettinoglu Packet Design
participants (3)
-
Cengiz Alaettinoglu -
Joao Luis Silva Damas -
Lu, Ping