For example, take a naive approach: your router crashes. It comes back
up. It receives 130,000 prefixes that it needs to validate. For each
prefix, your router must do an LDAP query.
Then take a smarter approach: your router crashes. It comes back up and
your network management system (NMS) pushes a special after-the-crash BGP
filter set to it. It receives 130,000 prefixes, most of which pass through
the filter just fine. The NMS collects the rejects, queries them against
an LDAP server asynchronously and builds a better BGP filter set which
gets pushed out to the router once the CPU settles down. Yes, this means
that some routes take longer to converge at this particular router but
that's not a problem because your resilient network architecture has
continued to deliver 100% of packets offered in spite of this router
crash.
And if the router is crashing often then you have bigger problems to
solve.
I am not suggesting that router vendors should implement any sort of LDAP
capability because it will be stuck in the same morass of ancient slow
CPUs, not enough absurdly expensive RAM, years-long test and certification
process because it runs on the router, and botched feature set because it
has to fit in the vendors wide range of router architectures and they will
only implement the features that many customers are clamoring for. The
alternative is to use modern fast CPUs running on standard systems with
lots of cheap RAM to handle these tasks that are peripheral to the job of
packet-forwarding. Then use the standard interfaces already on the router
(i.e. telnet from a protected server or SNMP) to communicate with this NMS
device
Your details may vary but this basic architecture works and it allows the
NMS to track more closely with commercial off-the-shelf (COTS) hardware
and software. Too many people are biased against this approach because of
the days when the IBM RS-6000 based routers were replaced with
purpose-built boxes from Cisco and Wellfleet (now Nortel).
--Michael Dillon