Re: Has PSI been assigned network 1?

[Curtis Villamizar <curtis () ans net>]

In message <199504191750.NAA18978 () titan sprintlink net>, Vadim Antonov 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.
>
> NACRs were so big headache that our implementation people dance
> around when they hear that there won't be any NACRs.
>
> 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.

To register a new route, we need prefix, prefix length, home AS.  The
rest is helpfull, like contact information for when things are broken,
or might break.  If the AS is already known, we have policy for it, so
you don't need to bother figuring out which AS and ENSS to route
through as you did with each NACR.  If new AS keep popping up, you can
define an AS macro such as:
  SPRINT-DIRECT-ATTACHED-CUSTOMERS-WITH-UNIQUE-AS 
and then specify that each new AS falls into the AS macro and so get
the policy treatment for the AS macro.

> 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).

I'm surprised your trouble ticketing system doesn't support a "next
action timer" that allows you to get notification after some time
period, like when the new circuit is supposed to be turned up, or when
the routing reconfiguration is supposed to have been completed so you
can then check connectivity.

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

I agree on the security note.  It should be more secure.  Then again
accepting route advertisements with no validation whatsoever isn't
very secure either.

> 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).

First - the current spec is RIPE-181.  

AS 690 has about as complex a set of policies as anyone I can imagine.
RIPE-181 can handle our import policy just fine.  We've suggested some
minor syntax changes that would substantially reduce the number of
lines required to express this (without defining a few thousand macros
to accomplish this), but the current syntax does provide the needed
flexibility.  Our export policy cannot be expressed in RIPE-181
because some of our export policy is AS path based.  An AS path
extension has already been proposed (or at least batted around on the
rps mailing list).

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

Thanks for sharing your insights on this topic.

Curtis

btw- I correected the Cc (which I botched in the first place) from
  prs () isi edu to rps () isi edu.