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
Havard, Thanks for starting this disussion. Here's some comments from a database implementation point of view, and some things we have discussed here at the NCC wrt aggregates and/or prefixes. There's two things in our view here: - the RIPE database should become classless ie move to general classless type addressing that can be of the form: <begin> - <start> # very general <begin> <mask> <begin>/<bits> we like the first form as general representation to keep them similar to what we have now. The other two could be accepted by the software, but would be rewritten to the first one. Of course extra flags could be added to the database to force a different representation, and tools to convert from one to the other are reasonably simple. - the RIPE database should contain aggregates the idea here is to create a new object that would indicate someone that would aggregate for someone else; proxy aggregation. Now, the first thing we should try and figure out is if we move all routing information into a new object, or do we keep the "inetnum" object for this, with the classless extensions above, and something special for proxy aggregation. Personally I have no strong feelings either way. Now, for implementation: * 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. We thought of this one as well of course, and the move to anything classless would mean a redesign of IP netnumber indexing in the database. We know we have to do this, but we have not yet found a suitable way of implementing this right now. The new indexing would then be real classless, so it would conists of something like ranges, and anything in that range would match that object, including hostaddresses even (with classless you cannot tell anymore what is a hostaddress and what is a netaddress in some cases). Disadvantage is that nets that have no "inetnum" but do fall in a aggregate or prefix or something like that that object will show up. You could even explain that as a feature ;-) I'd say, let's get some discussion on this. Also people who have ideas on indexing classless IP numbers are more than welcome. -Marten
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
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@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
-- Laurent Joncheray, E-Mail: lpj@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
Superb !!!, just what we want. We'll take his offline for some more discussion if that's okay. --Tony. Laurent Joncheray <lpj@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@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@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 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@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
Tony, The RWHois work that Mark and I have developed will do bit level reduction of a query. This will work in the CIDR environment. It also addresses the delagation needs of the current Internet environment. Below is the debug on the RWhois server trying to find an aggregate. If you want more information let us know .... we even have slides explaining the protocol. Scott %RWhois (by Network Solutions) V-B0.2 slam.internic.net 193.1.1.0 run_search: trying template |non-referral| file |data/whois| run_search looking for |193.1.1.0| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.1.0| run_search: trying template |non-referral| file |data/whois| run_search looking for |33QWQX193.1.1.0| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.1.0/24| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.0.0/23| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.0.0/22| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.0.0/21| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.0.0/20| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.0.0/19| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.0.0/18| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.0.0/17| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.1.0.0/16| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.0.0.0/15| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.0.0.0/14| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.0.0.0/13| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.0.0.0/12| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.0.0.0/11| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.0.0.0/10| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.0.0.0/9| run_search: trying template |referral| file |data/referral/referral| run_search looking for |33QWQX193.0.0.0/8| %whois.ripe.net:43
participants (5)
-
Havard Eidnes -
Laurent Joncheray -
Marten Terpstra -
scottw＠internic.net -
Tony Bates