>>>>> Michael MacFaden writes:
Michael> Given the history of the IP-FORWARD-MIB: ipRouteTable, Michael> ipForwardTable, and the ipCidrRouteTable a minimalist Michael> approach might mean we have a higher probability that can get Michael> this new work to full standard. The problem with the IP-FORWARD-MIB is that many systems use forwarding bases which are much richer than what the indexing allows to report. On such systems, implementing the ipCidrRouteTable (and the ipRouteTable) means to report only a subset of the real forwarding information. Hence, management applications which try to interpret these MIB tables are kind of fooled. This is of course even worse on systems that only have ipRouteTable support. If we really care about interoperable management applications, then we need to spell out very clearly that an IP version independent variant of the ipCidrRouteTable is only applicable on devices where the complete forwarding information can be represented in the ipCidrRouteTable. (And it is my understanding that for example a recent Linux box would not fit into this category.) We can try to improve this by adding more stuff into the index. However, we will end up with something that is getting even harder to implement correctly. And we all know that retrieving routing tables of non-trivial size via SNMP is already one of the slowest operations you can do on some boxes. So while I in general like incremental approaches, I am not sure this really works out in the particular case of the IP-FORWARD-MIB. /js -- Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
