#
# $XORP: xorp/rib/TODO,v 1.14 2007/03/15 23:56:44 pavlin Exp $
#

RIB To Do List
=======================

* The RIB should monitor the status of the FEA for route redistribution:
  when the FEA is UP/DOWN the RIB should register/deregister the FEA for
  route redistribution. Similar monitoring should be performed for
  all other targets interested in route redistribution: if a target
  dies, it should be removed (see RibManager::target_death()).

* Get rid of the periodic RibManager::status_updater(), and
  use event-driven status updater.

* ExtIntTable needs some re-writing to be more symetric so that
  recursive BGP nexthop lookups are possible.

* VIF configuration should be automatic, by communicating directly
  with the FEA.

* ExportTable needs a queue adding to rate control changes to the FEA
  when the FEA is not keeping up.

* ExportTable should amalgamate deletes and adds in its queue for the
  same route.

* RegisterServer should amalgamate deletes and adds in its queue for
  the same route.

* RegisterServer should be smarter about the use of flush().

* Route filters are needed for route redistribution.

* Change OriginTable to hold data rather than pointers in the Trie.

* Better, more extensive test suites.

* Rething the logic for computing whether a route is directly connected
 (e.g., when we use Vif::is_same_subnet() or Vif::is_same_p2p()):
  if vif is down, then the route is NOT directly connected?

* Make test_rib_client.cc work properly.

* Prune Export Table code.  This can be done with Redist Table using
  an export specific output, ie one that adds start and end
  transaction around route add / delete XRLs.

* Repeated adding and deleting of a table does not work.
  $ bgp/harness/test_routing2.sh -t test6.

* Use ref_trie.hh not trie.hh.

* The RIB provides a "register_interest[46]/deregister_interest[46]"
  interface for routes. The response to the register_interest call
  returns the requested answer. However, if a previous response becomes
  invalid the invalidation call comes via the rib_client interface. The
  client process can therefore information about a route via two
  different channels. This can mean that messages on one channel can
  overtake messages on the other channel.

  Therefore registering interest should not return the answer the answer
  should come later via the rib_client interface.
