Has PSI been assigned network 1?

Thu Apr 20 10:40:38 UTC 1995

  > Vadim Antonov <avg at sprint.net> writes:
  > Well, there is a big _if_:  if things will work w/o RADB (and they
  > will, for no sane provider will use RADB as the sole source of
  > exterior information at peering points, not for at least before
  > it became the proven and stable service) -- people will forget
  > to update things, cut the corners, etc.

We have such a proven and stable service in Europe: The RIPE Routing
Registry. Yes we could do more to get it populated better but that
is a matter of appropriate resources which we do not have at this
point. As a matter of fact I am quite envious of the amount of
money NFS spends on the RA.

We also have a number of useful tools that make use of the registry.
These were developed with money from real service providers (European
and US).

We also have a number of providers that use the registry (albeit not
exclusively) in configuring their routers. I understand from them
that it actually helps them limit the complexity involved.

  > RADB got to be easy to use to become real.  The e-mail interface
  > of NACRs is close to uselessness, and too big headache to deal with.
  > Waiting time on processing is simply ridiculous.

Do not confuse the transport mechanism with the update mechanism.
We support only e-mail as a transport at this point and get no 
flak about it because the update itself is automatic and turnaround 
times are consequently low. The main factor is the e-mail transit time.

  > There should be a host accepting telnet sessions for on-line
  > updates (which have to be installed *immediately*, so whoever
  > added a network can test connectivity and go ahead).

See above.
We have working code for interactive updates but before deployment we need
to solve authentication and authorisation issues. Since mail works very
well this is not a high priority at present.

  > There should be well-defined and useful interface to service
  > providers databases.

We have that at the moment: Make a dump of your database in RIPE-181
format and we will copy it. It is crude. It works. We are working on 
improving it.

  > It should be secure.

Please define secure. ;-)

We have and authorisation and authentication framework for updates.
See ripe-120 for details.

  > RADB should be able to implement _existing_ routing policies,
  > not the subset which can be defined in RIPE-81  (it currently
  > can't, there are places which use a lot of _very_ hairy stuff).

In a routing policy description language such as RIPE-181 tradeoffs have
to be made between complexity and power of expression.  In RIPE-181 we
have made some design decisions towards limiting complexity.  The main
reason for this is that all ISPs will have to learn the language! 

The RPS working group will work to expand power of expression while
hopefully retaining enough simplicity for the majority of cases to prevent
your "implementation people dance around" when it gets replaced eventually.

  > Without that i do not see RADB being successful or useful beyond the
  > point of filtering updates from particularly obnoxious peers.

Maybe you should contribute to the RPS working group, especially in the
area of suggesting features needed where RIPE-181 lacks the expressive
power you need.

Daniel