[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: [ipv6mib] So, where were we?
- To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
- Subject: Re: Fwd: [ipv6mib] So, where were we?
- From: Brian Haberman <bkhabs@nc.rr.com>
- Date: Tue, 08 Oct 2002 18:57:46 -0400
- Cc: mrm@riverstonenet.com, 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
- References: <3D92EE70.6658017A@cisco.com> <5.1.0.14.2.20021004121241.02bbd5a0@mail.windriver.com> <20021004190814.GD2627@riverstonenet.com> <200210082148.g98Lm1wG029967@hansa.ibr.cs.tu-bs.de>
Juergen,
So, should we look at trying to simplify the indices for the
tables? That would seem like the logical thing to me.
Brian
Juergen Schoenwaelder wrote:
>
> >>>>> 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/>
> --
> !! This message is brought to you via the `ipv6mib' mailing list.
> !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust
> !! your settings, send a mail message to <ipv6mib-request@ibr.cs.tu-bs.de>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/ipv6mib.