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

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Michael MacFaden writes:

Michael> Please decribe a "richer" FIB view.

Some boxes support multiple FIBs and they have mechanisms that extend
what currently can be expressed in the INDEX to select a specific FIB.

Michael> In my experience, a minimalist standard table for unicast
Michael> routing provides three key values one needs regardless of
Michael> gateway type/version:

[...]

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.

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

Michael> I either don't understand what you are saying or disagree.
Michael> The base management view should be a common
Michael> minimalist/operational set.  Should a particular
Michael> implementation need to display more information then it can
Michael> be made available in some other mib module. If less will
Michael> work, then we've put too much in. see section 3.1 in the
Michael> above document.

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.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>