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

["Dave Thaler" <dthaler@windows.microsoft.com>]

> From: Rajiv Raghunarayan [mailto:raraghun@cisco.com]
> 
> Margaret Wasserman wrote:
> >
> > >  One suggestion
> > >     I have heard is to change the MIB indices to integers and
> > >     have a mapping table that derives the integer from a more
> > >     comprehensive set of variables.  Does this mapping table
> > >     exist on the querier or the queried?
> >
> > I think that this suggestion involves two tables... One is
> > the current forwarding table, but with all of the indexes removed
> > and an integer index inserted instead.  The other is an index
> > table, with all of the current forwarding table indexes, with
> > each set of indexes mapping to an integer.
> >
> > I understand why such a table could be useful in cases where
> > many different sets of indexes would point to the same
> > information...  But, I don't think that's the case here, so
> > I don't understand why this would be better.  Can someone
> > explain?
> 
> IMHO, such a design moves the indexing complexity from the
> forwarding table to the associated mapping tables and makes
> the forwarding table simpler. One advantage I see with this
> approach is that while all implementations will need to
> implement a simple forwarding table, the complexity of their
> routing modules determines which mapping tables to implement.
> As of now, even a simple routing module would need to (partly)
> bear the brunt of a complex forwarding table indexing scheme.
> Of course, it would also mean that NMS' would need to query
> multiple tables to correlate the route information.

The intermediate solution previously discussed by the ipv6mib 
design team was to add an instance number to the INDEX,
and have separate mapping tables describe how to interpret
(or map to) the instance number.  Such mapping tables could
be part of the same MIB, or part of a proprietary MIB
(or both).  This is the solution I prefer, modulo my response
to Margaret's next suggestion below, since it entails only
a small change from 2096 (just replace TOS field with a more
generic instance number).

> > Another option would be to break the fowarding table up into a
> > forwarding table and a next-hop table.  Since there are a
> > limited number of next hops, we could have a small number
> > of entries in that table and reference them based on an
> > integer index in the forwarding table.
> >
> > However, I think that any of these sorts of changes should be
> > considered as part of an effort to develop a new, more useful
> > forwarding table MIB, not as part of the effort to ship a
> > minimal version-independent update to the current RFC 2096.

I think this idea has merit.

> While I agree with you in principle, one thing that bothers
> me is the usability of such a mib. If a mib is considered to
> be not "completely" usable, and another parallel mib enhancement
> work is in progress, what are the chances of someone wanting
> to go ahead and implement a partially complete and complex mib
> (unless there is customer pressure of course)??

Should this idea be done, I have no strong preference as to doing
it in a separate effort or as part of the same effort.

> If users aren't using the existing IPv4 mib due to reasons of
> complexity, incompleteness or performance, what we are doing
> may only add to the issues. If we can, in a decent timeframe,
> come up with the list of issues (if any) with the existing mib
> - we could perhaps see if those issues can be addressed by minor
> modifications to the existing mib (though this seems like a minor
> possibility). If so, perhaps we should go that way. Else, work
> on a fresh IP forwarding mib could perhaps be started off by the
> domain experts, while we could, if deemed useful and necessary
> by then, continue with the minimal modifications that address
> the IPv6 issue.

I think some of the reasons it's not used as much as it could be
are that the most interesting sorts of queries (such as those
supported by a CLI) are difficult.

Specifically, most of them today require reading most or all
of the routing table (which may be large and of an unknown size,
and difficult or impossible in general to get a consistent 
complete snapshot for), and then doing an appropriate filter 
on the management station.

Examples of some typical CLI queries:
1) Show me all the more specifics of X.Y/16 (this one is not too hard).
2) Show me the route(s) that would be used for X.Y.Z.W.
3) Show me the less specific routes covering X.Y/16.

-Dave