Routing prefixes in the RIPE database?

	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 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 at 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 at ravn>
>   * To: routing-wg at ripe.net
>   * Cc: db-gw at ripe.net, hostmaster at sunet.se, hostmaster at uninett.no
>   * Subject: Routing prefixes in the RIPE database?
>   * Date: Wed, 09 Mar 1994 22:25:48 +0100
>   * From: Havard Eidnes <Havard.Eidnes at 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
> 


-- 
Laurent Joncheray,                                 E-Mail: lpj at merit.edu
    Merit Network Inc, 1071 Beal Avenue,           Phone:  +1 (313) 936 2065
    Ann Arbor, MI 48109, USA                       Fax:    +1 (313) 747 3745
"This is the end, Beautiful friend. This is the end, My only friend, the end" JM