Routing prefixes in the RIPE database?

Superb !!!,
	just what we want. We'll take his offline for some more
discussion if that's okay.

		--Tony.

 Laurent Joncheray <lpj at 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 at 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 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 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 at 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