Gordon,
You write:
---
On december 14 Elise gerich wrote to the above recipients:
Some of the information in the RADB is "historical." It was carried over
from the PRDB for purposes of the transition from the NSFNET Backbone
Service to the current US Internet Architecture. The RA team has been
working with CA*net and ANS to reduce duplicate route objects
which are artifacts of the transition. Several months ago, approximately
3000 routes were deleted from the RADB because CA*net worked with us to
identify which routes were now being maintained in the CA*net DataBase.
Approximately, 1000 route objects have been deleted as a result of
a request from ANS more recently.
Approximately 20% of the route objects that existed at the time of
the transition have been removed.
COOK: So when you say 20% of the routes have been removed, how does one
judge what remains that is defunct and still remains to be removed???? Of
the 80% does anyone have a clue as to whether 95% of the 80% are "good" or
whether the real total of good routes might be on 50% of the 80%??
---
One of the interesting things about the Internet Routing Registry
(IRR) is that it is really just a database of databases. One of
the component databases is the RADB. Other component databases
include the ANS database, the CA*net database, the MCI database,
and the RIPE database.
Some tools which use these databases apply a preference in terms
of trust. ANS configuration generation tools, when using the IRR,
trust components in order of ANS, CA*net, MCI, RIPE, and the RADB,
treating the RADB as repository of last resort in some sense. This
is not meant to devalue it as a useful component so much as to
apply perspective to the relative integrity of each piece of the
system.
I believe that there is a natural incentive for providers to keep
their own customer routing information up to date. For historical
reasons stated above, I think that the RADB in particular is going
to be relegated to "last call" status for some time to come. CA*net
and ANS have cleaned duplicate or bogus objects from the RADB
database, and have replaced them with objects in our respective
databases. I'm not sure of the status of MCI's effort in this
regard, but we rely on MCI's own (clean) database when handling
MCI customers as noted above, so it just doesn't bother me that
much. Similarly, because we treat the RADB as last resort, the %
of good routes doesn't bother me in any excrutiating way, though
of course I'd prefer for it to match reality more than it may today.
Multihomed customers are a bit tricky, but for now that can be
solved by open communication among providers, or between provider
and customer.
Some of the tools which make use of the distributed database model
are a bit lean, a bit immature. However, improvements will come
in time. There are new tools to deal with more realistic aut-num's,
new policy specifications to deal with real life ISP policy
implementations, and new database code to deal with distribution
in several ways. Some are in test, some are in production, but
all are improving.
It's fair to say that those registries which are more natural and
comfortable for folks to use should reasonably be favored over
emotionally incorrect or truthfully inaccurate repositories.
Personally, I think that some hierarchical system may scale quite
well, though deciding the hierarchy will be fraught with the same
difficulties as was BGP-1, for example (who's closer to the top?).
For now, provider-specific registries, to the extent that there
aren't so many, seem to be doing the job in North America (due to
natural incentives), while the RIPE registry seems to be doing the
job in Europe (due to traditional comfort -- some research abroad
may help to clue me in :-) ).
My opinion...
Steve
You write:
---
On december 14 Elise gerich wrote to the above recipients:
Some of the information in the RADB is "historical." It was carried over
from the PRDB for purposes of the transition from the NSFNET Backbone
Service to the current US Internet Architecture. The RA team has been
working with CA*net and ANS to reduce duplicate route objects
which are artifacts of the transition. Several months ago, approximately
3000 routes were deleted from the RADB because CA*net worked with us to
identify which routes were now being maintained in the CA*net DataBase.
Approximately, 1000 route objects have been deleted as a result of
a request from ANS more recently.
Approximately 20% of the route objects that existed at the time of
the transition have been removed.
COOK: So when you say 20% of the routes have been removed, how does one
judge what remains that is defunct and still remains to be removed???? Of
the 80% does anyone have a clue as to whether 95% of the 80% are "good" or
whether the real total of good routes might be on 50% of the 80%??
---
One of the interesting things about the Internet Routing Registry
(IRR) is that it is really just a database of databases. One of
the component databases is the RADB. Other component databases
include the ANS database, the CA*net database, the MCI database,
and the RIPE database.
Some tools which use these databases apply a preference in terms
of trust. ANS configuration generation tools, when using the IRR,
trust components in order of ANS, CA*net, MCI, RIPE, and the RADB,
treating the RADB as repository of last resort in some sense. This
is not meant to devalue it as a useful component so much as to
apply perspective to the relative integrity of each piece of the
system.
I believe that there is a natural incentive for providers to keep
their own customer routing information up to date. For historical
reasons stated above, I think that the RADB in particular is going
to be relegated to "last call" status for some time to come. CA*net
and ANS have cleaned duplicate or bogus objects from the RADB
database, and have replaced them with objects in our respective
databases. I'm not sure of the status of MCI's effort in this
regard, but we rely on MCI's own (clean) database when handling
MCI customers as noted above, so it just doesn't bother me that
much. Similarly, because we treat the RADB as last resort, the %
of good routes doesn't bother me in any excrutiating way, though
of course I'd prefer for it to match reality more than it may today.
Multihomed customers are a bit tricky, but for now that can be
solved by open communication among providers, or between provider
and customer.
Some of the tools which make use of the distributed database model
are a bit lean, a bit immature. However, improvements will come
in time. There are new tools to deal with more realistic aut-num's,
new policy specifications to deal with real life ISP policy
implementations, and new database code to deal with distribution
in several ways. Some are in test, some are in production, but
all are improving.
It's fair to say that those registries which are more natural and
comfortable for folks to use should reasonably be favored over
emotionally incorrect or truthfully inaccurate repositories.
Personally, I think that some hierarchical system may scale quite
well, though deciding the hierarchy will be fraught with the same
difficulties as was BGP-1, for example (who's closer to the top?).
For now, provider-specific registries, to the extent that there
aren't so many, seem to be doing the job in North America (due to
natural incentives), while the RIPE registry seems to be doing the
job in Europe (due to traditional comfort -- some research abroad
may help to clue me in :-) ).
My opinion...
Steve