Paul A Vixie previously wrote:
If the multiple AS paths are only known to a colocated workstation running
GateD, then the iBGP from that workstation to the router(s) will only
include one view of each prefix. And the workstation can fall back on
VM during times when the number of prefixes or views exceeds planning.
And finally, the workstation's memory is probably not going to be limited
Precisely my point. I think it's a neat solution.
I clearly think that colocated workstations are better than route processors
inside the routers themselves. I'm less certain that they are better than
route servers and a unified/recursive/realtime RADB. I'm not sure at all
that any interconnect can, should, or ever shall require this kind of dual-
routing setup for its members. In other words, why are we discussing this?
We're discussing this precisely because you're not sure, as you say,
what course of action is best.
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. 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? and should we really trust such a route server? its implementation?
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,
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.
[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]