RIPE DB transition and RFC2725

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
>