Has PSI been assigned network 1?

Eric M. Carroll eric at enfm.utcc.utoronto.ca
Wed Apr 19 20:28:53 UTC 1995

>  I agree with the idea of Routing Registry (although i'm more than sceptical
>  about RADB in its present form, replacing distributed computation with
>  a cental box not controlled by the service providers).

This is an excellent point, and raises a path that CA*net has tried to
implement. I believe that the IRR has to follow "paths of
administrative trust" model, and not a central registration model,
since it is an administrative overlay on the routing protocol.  What I
mean is this: ISPs should run (or contract to run) their own routing
registry (think of CA*net and RIPE as contracted database providers to
member service providers in this model). This routing registry
*database* gets signed using PGP and exchanged *in bulk* with its
immediate peer neighbors and a central repository.  ISPs then generate
their configurations on this database.  The IRR is the union of all
ISP databases. Each ISP is responsible for the consistency and
validity of its own database. The important point is that as databases
are moved, they are signed, and this leaves a clear and specific audit
trail of who certifies the validity of the registered prefixes.

The central repository (the RA) acts in two roles: registry of last
resort (although this will not scale for the entire Internet) and as a
contracted central depository to assist the NAP routing for NSF. This
central depository provides the opportunity for interesting reporting
on configuration/topology/policy problems and issues.

Their are many religious objections to RIPE-181. However, my view is
that the facility it provides (a standard policy language and software
to implement it) is so important, just the fact that it exists now is
enough for me. When Nirvana arrives, I will deploy it. Until then, I
will use RIPE software, and thank them and the RA (Merit/ISI/IBM)
profusely for the work they have done.

Eric Carroll	University of Toronto Network & Operations Services
		External Networking Facilities Management
		CA*net Network Engineering

More information about the NANOG mailing list