[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)



On Fri, Jan 31, 2003 at 11:15:10AM -0800, C. M. Heard wrote:
>-- and IN the interest of least disruption I'd
>advocate removal of inetCidrRouteDiscards and un-deprecation of
>ipRoutingDiscards [note the spelling :-( ].  

I agree with the suggestion to un-deprecate ipRoutingDiscards. It is very
disruptive. I ran into the same problem with not including  
ifOutNUcastPkts and ifInNUcastPkts as well in a new product
seven years *after* the thesee objects were deprecated.

As I stated previously on the ipv6 list, objects found in 
IP-MIB(1213/2011) are not going away any time soon and as a vendor 
I will be forced to provide both mib modules for some time in the future. 
Hence I appreciate an effort to introduce minimal changes in this area.

>However, if the WG consensus is that this constitutes a semantic 
>change from past practice (owing to combined 2011+2465 deployment) and wants
>inetCidrRouteDiscards to remain, then I request that (a) some text
>be put into 2096 update explaining why it is there and (b) that the
>DESCRIPTION of ipRoutingDiscards be clarified in 2011-update to
>specify that it counts only discarded routes with UPv4 destination
>addresses (that is not really clear from reading 2011-update).

As for pulling the route table in bulk via snmp, I would have thought 
there might be some incremental/non-disruptive changes made using a proven 
approach for accessing enormously sized tables. 

The authors of RFC 2816 thought alot about this. On page 41 it reads:

 -- The hostTimeTable has two important uses.  The first is the
 -- fast download of this potentially large table.  Because the
 -- index of this table runs from 1 to the size of the table,
 -- inclusive, its values are predictable.  This allows very
 -- efficient packing of variables into SNMP PDU's and allows
 -- a table transfer to have multiple packets outstanding.
 -- These benefits increase transfer rates tremendously.

I suspect the table counter for route table was *removed* is due my
suggestion "macfadden-08" found here: 
   http://www.icir.org/fenner/mibs/v6/issues
and to subsequent reasoning presented against this suggestion 
which occured on the ipv6 list explaining why such counters
are generally not useful or possibly difficult to implement 
if one has a subagent implementation. 

Regards,
Mike MacFaden