Precisely my point. I think it's a neat solution.
So do I, in the absence of ...
>route servers and a unified/recursive/realtime RADB. [...]
We're discussing this precisely because you're not sure, as you say,
what course of action is best.
"I'm not sure" in this context is a euphemism for "that's a really bad idea."
Now, the folks at Sprint don't like the idea of a "unified" route
server, and I don't blaim them, since it does reduce one's independence
when it comes to setting a routing policy: the "unified" route server
only gives everyone one "view," the same view when we'd all rather be
able to make the decision ourselves of what "view" is best.
Nope. As you're about to explain yourself, the RS architecture makes it
possible to spout different truths out of each and every orifice. It is
very definitely _not_ nec'y for every RS peer to have the same view, or
that the Internet have a single great and context-insensitive "Truth".
Yes, the
route server would be configured from the RADB, and we'd all have the
right to register whatever policy for our ASes we think is best, but how
often would the route server be reconfigured to reflect updates to the
RADB?
Right now, this is the thing that makes the RS unusable. At the RPS WG in
Stockholm I heard Daniel talk about a way to improve RADB update times, and
Bill Manning and I proposed a DNS-based RADB whose rollups could be done by
anyone needing the information rather than by a central body. While I admit
that the RS doesn't have realtime updates right now, I know that it's coming.
Knowing Sean for who he is, I'm fairly sure that no RADB or RS will ever be
suitable to him. In particular...
and should we really trust such a route server? its implementation?
its administrators?
...while I would trust those things if given sufficient reason to, I know of
at least one network/routing engineer who wouldn't no matter how sufficient
the reasons seem to the rest of us. So your point is valid on that score.
As for wether an interconnect can requiere everyone to collocate a route
server for their AS, I don't see why not. It's only a few inches of rack
space; the collocated route servers don't have to be connected to the
high speed (FDDI or ATM or whatever comes along) interconnect either,
because, as I've already pointed out, the collocated route servers could
be on a totally separate, parallel, low bandwidth network (say,
Ethernet).
In legal terms, we cannot add contract terms now that a lot of peering points
are in use. There is, quite literally, "no way to require" colo'd workstations
at peering points. It doesn't matter how little rack space it takes, or that
the BGP4 traffic would be on different media like Ethernet, or whether it is
(I'm not going to take a position) a wonderful idea or not. Legally, we cannot
require it. Practically, the peering points are "open" to the extent that
folks are expected to use their GIGAhose "as they see fit."
Requiring colo'd workstations, even if we gave them away, is as impossible as
requiring that folks sign an MLPA.
Does anyone see a reason, political or technical, why collocating per-AS
route servers is not viable? Yes, the scalability does not improve as
opposed to what we have now, but PCs get better much faster than Cisco's
or Wellfleet's or NSC's or <fill in the blank>'s routers, meaning
scalability problems are pushed off far into the future ; but it is far
better, easier to handle and administrate than planning and
administrating proxy aggregation.
I think this is a reasonable architecture and if I am asked to recommend an
architecture to someone connected to a MAE or NAP, I will mention this one.
I recommend that you do the same. Perhaps you can live to see your ideal
done up in practice. But banish all expectations that either a peering point
administrator will help enforce your ideology, or that you will ever get full
voluntary buy-in from every peer.
N**2 BGP4 sessions are bad for likely values of N (100, maybe.) That won't
change just because we've got a 1GB-RAM DEC Alpha with a 300MHz processor
instead of a Cisco to do our route processing. N**2 BGP4 sessions is a bad
design no matter what you're implementing it with. In that sense, your idea
is not "viable" since it doesn't solve some of the real problems coming up.
[A fast PC with 1GB of RAM should be able to handle any NAP for the next
year to two years, by which time IPv6 could be hitting the scene]
I can't even begin to comment on that, I'm sure that I'd offend you.