Harvard, Well Marten has answered the database implication stuff, I'll also try adding a bit. Firstly, thanks for starting the discussion. We have 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 addresses * 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 routes. * 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 sense * 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 database? * * I know some argue that should not be necessary, eg. with the counter- * argument being "you can use 'show ip bgp <prefix>' and thereby inspect the * 'aggregator' attribute to get a handle on where to direct trouble reports" * etc. etc. However, this only works as long as the prefix is reachable, * 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 here, * 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 used for * registering assignments of natural network numbers -- the ranges * registered are not always of power-of-2 size, so cannot be represented * as a single routing prefix. I suggest "rout-pfx" as long-form name. * * 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 database * 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 eg. * "129.240/15" create keys for all the natural IP network numbers covered 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 numbers * 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 object. * * I haven't really thought much about what attributes the "rout-pfx" object * should/could contain -- there probably shouldn't be all that many, and we * can probably give a pointer for recursion via the AS where the aggregate is * originated (and we all have our ASes registered, right? ;-). * * Comments? * * - Havard