Subject: [BEHAVE] NAT MIB: Life cycle of objects and counter persistence

From: Tom Taylor <[email-masked]>
Date: Mon, 17 Nov 2014 10:24:23 -0500

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Nov 2014 17:11:31 +0100

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:
> _______________________________________________
> Behave mailing list
> [email-masked]
> 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/>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 17 Nov 2014 11:33:23 -0500

OK

> come and go dynamically, you want to specify other discontinuity
...