Superb !!!, just what we want. We'll take his offline for some more discussion if that's okay. --Tony. Laurent Joncheray <lpj@merit.edu> writes: * I am working on a new whois server for the RIPE-DB which * uses radix tree (instead of hash table) to store the ip * numbers. It should solve your problem of aggregate. * Wait 2 or 3 weeks. * -- lpj * > * > Harvard, * > Well Marten has answered the database implication stuff, I'll * > also try adding a bit. Firstly, thanks for starting the discussion. We ha * ve * > been thinking about this for a while and do have a draft for the * > representation almost done (we're currently bogged down with the PRIDE * > guide but should have something soon I hope), plus as Marten said * > we plan to have an aggregrate object and just needs to be written up. * > Initially the plan with the aggregate object is fairly simple. This * > will contain the aggregate (stored in net/len format we think !!!, but * > acceptable as input in at least the three forms marten showed) * > and who (which AS, ASes) aggregates it with the database doing the tricky * bit * > of finding more and less specific matches, plus possibly an option * > of who you are aggregating for if the recursive indexing is too * > tricky. Which comes to the biggest problem of all which is the * > re-writing of the indexing system in the DB as Marten said. * > We also want to preserve ranges in the inetnum field * > and allow them to be submitted but * > perhaps give warning for non-cidr alligned boundaries. * > * > I'd very much like to see aggregates in the DB as soon as we can as * > well. I see several large aggregates (len 15 by you (AS224) is the * > biggest by the way ;-)) now being aggregated * > * > I see 81 aggregates in the global Internet as of last night. Some * > certainly without their more specific routes, check * > * > ftp.ripe.net:ripe/as/router/cidr-routes * > * > So there is an ever pressing need for this and we do know it is an * > issue. * > * > We will try to get the drafts for the representation and the aggregate * > object as soon as we can. * > * > One question I have also is are all the current aggregates atomic ? * > Also, are sites already considering making use of AS-sets. I ask this * > becuase this could also effect what goes into the aggregate object. * > * > * > --Tony. * > * > * > Havard Eidnes <Havard.Eidnes@runit.sintef.no> writes: * > * Sorry to those of you who see this twice, I mis-spelt one of the addr * esses * > * and want both groups to receive copies of any resulting discussion. * > * * > * - Havard * > * * > * ------------------------------ * > * * > * Message-Id: <9403092125.AA28955@ravn> * > * To: routing-wg@ripe.net * > * Cc: db-gw@ripe.net, hostmaster@sunet.se, hostmaster@uninett.no * > * Subject: Routing prefixes in the RIPE database? * > * Date: Wed, 09 Mar 1994 22:25:48 +0100 * > * From: Havard Eidnes <Havard.Eidnes@runit.sintef.no> * > * * > * Hi, all. * > * * > * I've been thinking about what we should do wrt. routing prefixes that * are * > * not "natural" network numbers, ie. what should be done about CIDR rou * tes. * > * This was prompted by fear that the Merit people would get "confused" * > * because the routing prefixes we send in NACRs for these days are not * > * directly found in the RIPE database, but it would perhaps also make s * ense * > * as seen from a general perspective to register routing prefixes (ie. * CIDR * > * routes) in the RIPE database. * > * * > * Point for discussion: * > * * > * 1) should we try to register routing prefixes as such in the RIPE dat * abase? * > * * > * I know some argue that should not be necessary, eg. with the counter- * > * argument being "you can use 'show ip bgp <prefix>' and thereby inspec * t the * > * 'aggregator' attribute to get a handle on where to direct trouble rep * orts" * > * etc. etc. However, this only works as long as the prefix is reachabl * e, * > * so... Also, how will this show up in the BGP routing table if it isn * 't * > * really BGP routes which are aggregated, but the aggregate is "locally * > * originated" in the AS in question? If I am correct in my guesses her * e, * > * this all points in the direction of registering the prefixes * > * administratively. * > * * > * If there is consensus that we should try to register routing prefixes * in * > * the database, I have the following proposals/suggestions: * > * * > * 2) the routing prefix should be a separate object from the "inetnum" * > * object. The reasoning behind this is that "inetnum" is mostly use * d for * > * registering assignments of natural network numbers -- the ranges * > * registered are not always of power-of-2 size, so cannot be represe * nted * > * as a single routing prefix. I suggest "rout-pfx" as long-form nam * e. * > * * > * 3) the format when registering a routing prefix could be * > * <IP-prefix>/<bitlen>, eg. "129.240/15" or "129.241.0.0/15" or the * > * obvious in-between. * > * * > * 4) lookup of a "natural IP network number" with WHOIS in the RIPE dat * abase * > * should give as result all the routing prefixes it is a part of, as * well * > * as the traditional "inetnum" output. * > * * > * Hint for implementation in the RIPE database: from a routing prefix e * g. * > * "129.240/15" create keys for all the natural IP network numbers cover * ed by * > * this prefix with pointers to the routing prefix object. This should * be a * > * fairly straight-forward approach (say I who haven't really hacked on * the * > * RIPE software... ;-) Side-effect: lookup of unassigned network numbe * rs * > * within a routing prefix after this change will no longer give the "No * > * entries found for the selected source(s)" result when whois is used, * but * > * instead the routing prefix(es) will be returned, but no inetnum objec * t. * > * * > * I haven't really thought much about what attributes the "rout-pfx" ob * ject * > * should/could contain -- there probably shouldn't be all that many, an * d we * > * can probably give a pointer for recursion via the AS where the aggreg * ate is * > * originated (and we all have our ASes registered, right? ;-). * > * * > * Comments? * > * * > * - Havard * > * * * -- * Laurent Joncheray, E-Mail: lpj@merit.edu * Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 206 * 5 * Ann Arbor, MI 48109, USA Fax: +1 (313) 747 374 * 5 * "This is the end, Beautiful friend. This is the end, My only friend, the en * d" JM