Hi,
I think this is a bad idea.
1) I used to work at implementing a manager-side application for network
management.
I am concerned that dynamic enable/disable statistics gathering for this one
MIB module could affect a lot of processing on the manager side.
Managers already need to do a lot of work just to determine what MIB modules
are supported by a device, and then to determine whether the device supports
the MIB module in a compliant manner, or is missing some objects from the
implementation, and whether the data reported is reliable.
Adding a dynamic enable/disable collection at the subscriber level would
seem to introduce a great deal of additional complexity for the manager, and
more importantly, for the operator trying to diagnose a network problem.
What impact would this on-off discontinuity have on the multiple manager
scenario. What happens if one manager is monitoring a subscriber's stats for
a period of time, and another manager goes in a mucks about with the
continuity of collection?
SNMP's design of counters - read, then read again and consider the delta,
rather than zeroing counters constantly - is done to support the (very
common) multiple manager scenario. The counters are consistently available,
which is useful for historical trending, etc. The dynamic enable/disable of
collection would seem to defeat that important SNMP design choice, and make
interpretation of the discontinuous values over time more difficult and less
useful.
So I think there needs to be considerate discussion of the operational
impact of such a switch in this MIB.
3) Do we have feedback from implementers discussing the actual or estimated
implementation resources required to support subscriber stats, to justify
needing such a switch?
If device implementers think this really demands too many resources to
support, maybe the subscriber stats should be removed from this MIB module
and moved to a separate MIB module that is optional to implement, and then
support of subscriber stats can be a question to be resolved between vendors
and their customers.
I would like to know that such a switch really is justified before adding
such complexity.
4) SNMP SETs are not supported very widely, and with the approval and
promotion of NETCONF as the IETF standard for configuration, I expect fewer
operators will allow SETs even if supported by the agent implementation.
Do we really need to standardize a read-write object to make it consistent
across vendors, when many deployments may not support the SET capability?
5) All of which leads me to ask - Are the subscriber stats REALLY IMPORTANT
to have?
Here are some principles of MIB design to keep in mind (from RFC4188 and
others):
1. Start with a small set of essential objects and add only as
further objects are needed.
2. Require that objects be essential for either fault or
configuration management.
3. Consider evidence of current use and/or utility.
4. Limit the total number of objects.
5. Exclude objects that are simply derivable from others in this or
other MIB modules.
6. Avoid causing critical sections to be heavily instrumented. The
guideline that was followed is one counter per critical section
per layer.
If per-subscriber stats can be enabled/disabled, does the NATv2 MIB meet
these principles?
Are these stats **essential** for fault management?
If operators think they really are not essential enough to keep them enabled
at all times, do we really NEED subscriber stats in the MIB module?
If we do NEED them for fault management, what impact does turning them off
have on fault management?
Are non-standard per-subscriber stats currently being used for fault
management?
Do operators currently collect and utilize per-subscriber stats through the
available non-standard interfaces of NAT devices?
What do they do with these stats, so we can understand the design
requirements to support these current use cases?
Is standardizing these stats in the MIB really important to operators for
apples-to-apples comparison across devices from multiple vendors?
6) Another principle about good agent implementation is "never mislead the
operator".
It was a common problem that early SNMP agent implementations reported zero
values, when objects were actually not implemented.
This was misleading to operators, causing delays in resolving faults, and
wasting operators' time at critical moments.
This proposed text certainly fails that principle:
". If false(1)
> (default), accumulation of statistics in the counters for
> this subscriber is disabled and the values presented to the
> manager MUST be zero regardless of their actual value."
If a counter is disabled, then it would be more appropriate to not report a
value, and to return an error/exception instead.
--
I would like to see operator feedback on whether subscriber stats are
essential to have in a standard MIB, and whether enabling/disabling those
stats would be problematic for operations and management.
David Harrington
[email protected]
+1-603-828-1401
> -----Original Message-----
> From: Behave [mailto:[email protected]] On Behalf Of Tom Taylor
> Sent: Friday, February 06, 2015 4:42 PM
> To: [email protected]; [email protected]
> Cc: Tina TSOU
> Subject: [BEHAVE] NATV2-MIB: Proposed additional read-write control on
> per-subscriber statistics
>
> draft-perrault-behave-natv2-mib-01 is almost ready.
>
> I considered in the past and rejected in my own mind a per-subscriber
> control on whether statistics are enabled or not for that subscriber. I
> rejected it thinking that the impact on processor consumption would be
> minimal, after the processor looked up the subscriber data in the first
> place. I've changed my mind for two reasons: first, that I probably made
> too many assumptions about implementation, and secondly, because the
> impact on storage requirements for per-subscriber statistics would be
> potentially huge if such a control were available.
>
> I therefore propose the following:
>
> 1) In the description of the CGN application scenario (Section 3.4 of
> draft-perrault-behave-natv2-mib-00), add the following sentence:
>
> "An implementation MAY limit the number of subscribers for which
> collection of statistics is enabled at any one time."
>
> 2) Add the following object to natv2SubscriberTable:
>
> natv2SubscriberCountersEnabled OBJECT-TYPE
> SYNTAX TruthValue
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "If true(1), accumulation of statistics in the counters for
> this subscriber is enabled and the current values of the
> counters can be presented to the manager. If false(1)
> (default), accumulation of statistics in the counters for
> this subscriber is disabled and the values presented to the
> manager MUST be zero regardless of their actual value.
> Whenever the value of this object changes,
> natv2SubscriberDiscontinuityTime MUST be updated to the time
> of change."
> ::= { natv2SubscriberEntry xx }
>
> Comments?
>
> Tom Taylor
>
> _______________________________________________
> Behave mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
