Re: Operational Issues with 69.0.0.0/8...
Sean Donelan, May 14 1998 (three employers ago, so this should not be taken as representing the official position any of my past, present or future employers)
Yakhov, Elise, Mark, and Bill - 1994 as part of the RA project, bringers of the RAdb.
This gets to the heart of the matter. It is now 8 years later and RADB is not catching on. But during the same time period some other UMich people worked on a more general purpose directory service called LDAP and that one is catching on. LDAP technology can be made to do the job that we need done and instead of having to create tools from scratch we can leverage a lot of commercial tools to deal with the core functions. --Michael Dillon
Sean Donelan, May 14 1998 (three employers ago, so this should not be taken as representing the official position any of my past, present or future employers)
Yakhov, Elise, Mark, and Bill - 1994 as part of the RA project, bringers of the RAdb.
This gets to the heart of the matter. It is now 8 years later and RADB is not catching on. But during the same time period some other UMich people worked on a more general purpose directory service called LDAP and that one is catching on. LDAP technology can be made to do the job that we need done and instead of having to create tools from scratch we can leverage a lot of commercial tools to deal with the core functions.
--Michael Dillon
The implementation (RAdb/RPSL/IRR/LDAP/SWIP/rwhois) is, to a large degree, immaterial. The idea of publishing the IANA/RIR/ISP reserved pool in a tagged format that is machine parsable is the key. That we are unable to get to that point is telling. Its fairly easy to identify the IANA reserved /8 blocks. Its harder to identify the RIR reserved space (space delegated to RIRs that is not yet delegated to downstreams). Harder yet, identifying ISP reserved space (space delegated to ISPs that is not yet delegated to downstreams/endsystems). You should ask yourself, why is it important at one level and not important elsewhere? If you want a comprehensive map of IP space not in active use, then make the compelling case for it and build the tools that are so easy to use, everyone will adopt them. I've not seen a compelling case for just the IANA and not the RIRs or just the IANA and RIRs but not the ISPs. I've seen a compelling case for -EVERYONE- to participate in tracking IP space in use, but the tools that cover the range of useage are jsut not here. LDAP is not the cureall. Its a tool and some folks can make it work. Its too much overhead for most folks and for some parts of the delegation heirarchy. Now we could have the debate on -WHY- ldap/whois is considered so important. The applications use things like DNS mappings and routing announcements. These are critical for network operations. ldap/whois are not. --bill
This gets to the heart of the matter. It is now 8 years later and RADB is not catching on. But during the same time period some other UMich people worked on a more general purpose directory service called LDAP and that one is catching on. LDAP technology can be made to do the job that we need done and instead of having to create tools from scratch we can leverage a lot of commercial tools to deal with the core functions.
you are confusing an application service, radb, with an underlying store protocol, ldap. e.g., show me a routing db in ldap that has 10% the use of radb. by your reckoning, sql is the technology, as ripe, apnic, and many others use it as the *store* for their routing databases. randy
On Tue, 10 Dec 2002 Michael.Dillon@radianz.com wrote:
Yakhov, Elise, Mark, and Bill - 1994 as part of the RA project, bringers of the RAdb.
This gets to the heart of the matter. It is now 8 years later and RADB is not catching on.
It doesn't have anything to do with query serialization method. RADB is a kludge forcing ISPs to make their routing infrastructure to depend on an external and centralized resource, and introducing an extra step (which takes non-negligible amount of time) to their customer installation process. The better way of dealing with the problem of bogus routes is strong authentication of the actual routing updates, whith key being allocated together with the address block. Solves unused address space reclaimation problem, too - when the key expires, it becomes unroutable. I always thought that RADB was a temporary band-aid, but it seems that there was no progress in the field for quite a few years. Unfortunately, trying to do some new stuff in the field is nearly impossible - when VCs hear "backbone routing" they slam the door. --vadim
On Tue, 10 Dec 2002, Vadim Antonov wrote:
On Tue, 10 Dec 2002 Michael.Dillon@radianz.com wrote:
Yakhov, Elise, Mark, and Bill - 1994 as part of the RA project, bringers of the RAdb.
This gets to the heart of the matter. It is now 8 years later and RADB is not catching on.
It doesn't have anything to do with query serialization method.
RADB is a kludge forcing ISPs to make their routing infrastructure to depend on an external and centralized resource, and introducing an extra step (which takes non-negligible amount of time) to their customer installation process.
The better way of dealing with the problem of bogus routes is strong authentication of the actual routing updates, whith key being allocated together with the address block. Solves unused address space reclaimation problem, too - when the key expires, it becomes unroutable.
<snip> Of course, who would maintain the key databases and do you mean every route would need a key with the central registrar or would it be carved up to eg authority on /8 level or lir level which could be /22s.. seems at some point you still have to go back to a central resource and if you dont have a single resource you make it complicated? Steve
On Tue, 10 Dec 2002, Stephen J. Wilcox wrote:
The better way of dealing with the problem of bogus routes is strong authentication of the actual routing updates, whith key being allocated together with the address block. Solves unused address space reclaimation problem, too - when the key expires, it becomes unroutable.
Of course, who would maintain the key databases and do you mean every route would need a key with the central registrar or would it be carved up to eg authority on /8 level or lir level which could be /22s.. seems at some point you still have to go back to a central resource and if you dont have a single resource you make it complicated?
There's a big difference: address allocation (and key distribution) is off-line, and is not involved in operation of the routing system. Its failure doesn't cause network malfunction, just aggravation of new customers. OTOH, invalid RADB data can easily prevent network from operating, on a massive scale. --vadim
On Tue, Dec 10, 2002 at 06:24:42AM -0800, Vadim Antonov wrote:
There's a big difference: address allocation (and key distribution) is off-line, and is not involved in operation of the routing system. Its failure doesn't cause network malfunction, just aggravation of new customers.
Hmmmm. Didn't this entire thread start with "just aggravation of new customers" - to wit, folks in 69/8 having problems reaching places with filters that haven't been updated? s/filters that haven't been updated/key databases that have not been updated/, and it looks like we're right back where we started... -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Hmmmm. Didn't this entire thread start with "just aggravation of new customers" - to wit, folks in 69/8 having problems reaching places with filters that haven't been updated?
s/filters that haven't been updated/key databases that have not been updated/, and it looks like we're right back where we started...
Key databases: Using cryptography to authenticate routing updates gets messy very soon. Then, there will again be the same problem of the Public Key Infrastucture not getting updated or something like that. Harsha.
On Tue, 10 Dec 2002, Harsha Narayan wrote:
Key databases: Using cryptography to authenticate routing updates gets messy very soon. Then, there will again be the same problem of the Public Key Infrastucture not getting updated or something like that.
Hard to do it right, yes, but not impossible. (Actually I did strong crypto for a living last few years, so I think I have somewhat informed opinion on the subject :) --vadim
Hi, It would require a PKI and also require every router to support it. Harsha. On Tue, 10 Dec 2002, Vadim Antonov wrote:
On Tue, 10 Dec 2002, Harsha Narayan wrote:
Key databases: Using cryptography to authenticate routing updates gets messy very soon. Then, there will again be the same problem of the Public Key Infrastucture not getting updated or something like that.
Hard to do it right, yes, but not impossible. (Actually I did strong crypto for a living last few years, so I think I have somewhat informed opinion on the subject :)
--vadim
On Tue, 10 Dec 2002, Harsha Narayan wrote:
Using cryptography to authenticate routing updates gets messy very soon. Then, there will again be the same problem of the Public Key Infrastucture not getting updated or something like that.
It would require a PKI and also require every router to support it.
Not every... borders are enough. PKI is not that complicated, too; and routers already have some implementation of it embedded (in VPN parts). --vadim
participants (7)
-
bmanning＠vacation.karoshi.com -
Harsha Narayan -
Joel Baker -
Michael.Dillon＠radianz.com -
Randy Bush -
Stephen J. Wilcox -
Vadim Antonov