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