Tom, please do not talk about a counter 'reset' or resetting a counter to zero. This is not how SNMP counters work. Instead, make it clear for every Counter what the discontinuity indicator is. See Section 7.1.6 of RFC 2578:
Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content. Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. If such other times can occur, for example, the creation of an object instance at times other than re-initialization, then a corresponding object should be defined, with an appropriate SYNTAX clause, to indicate the last discontinuity. Examples of appropriate SYNTAX clause include: TimeStamp (a textual convention defined in [3]), DateAndTime (another textual convention from [3]) or TimeTicks. The default discontinuity indicator is sysUpTime. If NAT instances can come and go dynamically, you want to specify other discontinuity indicators. /js On Mon, Nov 17, 2014 at 10:24:23AM -0500, Tom Taylor wrote: > Natv2-MIB has few writable objects, only for control of notifications > and setting of quotas. Thus the module assumes that other means are used > to provision NAT instances and address pools and configure subscriber > data. It seems likely that a mechanism such as the one used to maintain > the integrity of references to ifIndex will be needed to protect > references to NAT instance index, address pool index, and subscriber > index, but that is another topic. > > The basic question is how persistent the counter values supported by the > Natv2-MIB should be. Apparently past practice has been to say: "until > the agent restarts", but that isn't really helpful when you are trying > to debug a problem. I distinguish between a counter, which is > cumulative, and a state object, which gives a snapshot at the moment of > reporting. > > Would implementors support the following general statement? > > "Ideally, counter values are never reset while the parent object (NAT > instance, address pool, subscriber) continues to exist, even across > reboots. Individual implementations may not be able to guarantee this > level of persistence, and SHOULD document the circumstances under which > resets could occur. In any event, all implementations MUST report the > time of last reset in the relevant object in the NAT instance, address > pool, and subscriber tables." > > By "reset" I mean setting the counter back to zero. I think that is the > proper action, because it makes discontinuities more obvious than > resetting to a random value. > > No comments mean that I will go ahead with this proposal. > > Tom Taylor > > > > BACKGROUND > > In my present thinking, the conceptual tables in the MIB module come in > two groups, device level, and NAT instance level: > > 1. Device level: indexed by subscriber index, not by instance index (to > make it easier to reassign subscribers from one NAT instance on the > device to another): > > natv2SubscriberTable > -- contains per-subscriber counters > natv2SubscriberIngressInterfaceClassifierTable > -- configuration data only > > 2. Group indexed by NAT instance, meaningful only while the instance exists: > > natv2InstanceTable > -- now incorporates the per-instance counters, thresholds, and > limits that were in separate tables before > natv2NextProtocolTable > -- counters per protocol supported by the NAT instance > natv2PoolTable > -- counters per address pool > natv2PoolRangeTable > -- configuration data only > natv2AddressMapTable > -- state data only > natv2PortMapTable > -- state data only > > _______________________________________________ > Behave mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/behave -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
