Re: Fwd: [ipv6mib] So, where were we?

[Michael MacFaden <mrm@riverstonenet.com>]

On Wed, Oct 09, 2002 at 01:42:20PM +0200, Juergen Schoenwaelder wrote:
>
>>>>>> Michael MacFaden writes:
>Michael> If there are needs for other views of the FIB, then I would
>Michael> suggest defining additional tables in other rfc documents and
>Michael> get a base view to full standard asap as appears to be done
>Michael> for rfc2863/2864.
>
>Fine with me as long as it is very very clearly stated that
>implementing this MIB on boxes that have more than such a minimalist
>FIB mechanism is strongly discouraged because it fools management
>applications.

I disagree. We have been using capability bits convention 
for some time now to convey to mgmt apps the current capability
of a given implementation.  I believe there can be multiple table
views instead of one uber-index structure.  Take the new BGP mib
design for example.

What has been fooling mgmt applications and users for years now is using out
of date full standard mib modules such as ipRouteTable.

>>> 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.)

I have yet to see a "use case" that states exactly what operators need
beyond the tuple I listed before (prefix, who installed/age, nexthop).

>I will try again: On devices that support multiple FIBs that are not
>simply distinguished by Tos (or DSCP these days) values, you can not
>report all the information that is used by the device to make a
>forwarding decision. Hence, management applications that try to
>interpret the ipCidrRouteTable are drawing wrong conclusions.

Please read draft-ietf-snmpconf-bcp-10.tt section 3.13.2 "Supporting
Multiple instances of a MIB module".

This issue has an existing viable solution that has worked for
RFC1850 and others where the mib module defines a single instance
but the device can support multiple instances. I would prefer
the solution to having everyone pay the price of some complex
index structure when 99% of the time a device supports a FIB. 

Regards,
Mike MacFaden