RIPE DB transition and RFC2725
- Previous message (by thread): RIPE DB transition and RFC2725
- Next message (by thread): RIPE DB transition and RFC2725
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Lu, Ping
plu at cw.net
Fri Mar 9 18:06:08 CET 2001
Comments followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu at cw.net > -----Original Message----- > From: Cengiz Alaettinoglu [mailto:cengiz at packetdesign.com] > Sent: Friday, March 09, 2001 11:24 AM > To: Lu, Ping > Cc: 'Frank.Bohnsack at de.uu.net'; db-wg at ripe.net > Subject: RE: RIPE DB transition and RFC2725 > > > > Lu, Ping (plu at 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. > The wrokaround means DISABLE integrity checking. That's an option for RIPE-DB v2.x (RIPE-181) but we haven't tried RIPE-DB v3.x yet. Also the workaround raises another question: How do you authorize the route creation from a foreign AS ? That's exactly the issue from Andrei's previous email (subject: Migration issues: route creation). And the solution to this needs to be discussed further. ( Hi, Andrei, any more suggestions from the community yet ?) > > 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 at cw.net > > > > > > > -----Original Message----- > > > From: Frank Bohnsack [mailto:Frank.Bohnsack at de.uu.net] > > > Sent: Friday, March 09, 2001 7:43 AM > > > To: db-wg at 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 at 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 >
- Previous message (by thread): RIPE DB transition and RFC2725
- Next message (by thread): RIPE DB transition and RFC2725
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]