[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: [ipv6mib] So, where were we?
- To: mrm@riverstonenet.com
- Subject: Re: Fwd: [ipv6mib] So, where were we?
- From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
- Date: Tue, 8 Oct 2002 23:48:01 +0200
- Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com, mibs@ops.ietf.org, bwijnen@lucent.com, ipv6mib@ibr.cs.tu-bs.de, sob@harvard.edu, mankin@isi.edu, mathis@psc.edu, narten@us.ibm.com, deering@cisco.com, hinden@iprg.nokia.com
- In-reply-to: <20021004190814.GD2627@riverstonenet.com> (message from MichaelMacFaden on Fri, 4 Oct 2002 12:08:15 -0700)
- References: <3D92EE70.6658017A@cisco.com> <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> <20021004190814.GD2627@riverstonenet.com>
>>>>> 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/>