Routing prefixes in the RIPE database?

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