Subject: [OPS-AREA] RFC1155 Timeticks hitting maximum value

From: "Gene Matusovsky" <[email-masked]>
Date: Wed, 23 Jun 2010 17:08:52 -0400

RFC1155 defines TimeTicks as a non-negative integer, with a maximum value of 4294967296. 

In our environment, this limiting the hrSystemUptime object id 1.3.6.1.2.1.25.1.1.0 to 497 days, at which point the counter rolls and resets back 0.  
This causes our NMS system to display in-accurate information from our field SNMP agents for their hrSystemUptime values.

Is there any workarounds to this problem we're facing? Are there any plans to increase the RFC1155 definition of TimeTicks to a higher 64 bit integer value?

-Thank You,
Gene Matusovsky

-------------------------------------------------------- 
The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain information concerning Cablevision and/or its affiliates and subsidiaries that is proprietary, privileged, confidential and/or subject to copyright.   Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient(s) is prohibited and may be unlawful.  If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof.
--------------------------------------------------------

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Jun 2010 15:17:15 -0700

Hi -

> From: "Gene Matusovsky" <[email-masked]>
> To: <[email-masked]>

You'd be better off sending this to the MIB doctors list,
[email-masked]

> Sent: Wednesday, June 23, 2010 2:08 PM
> Subject: [OPS-AREA] RFC1155 Timeticks hitting maximum value
>

The snide response is to suggest getting another NMS.

But the reality is that hrSystemUptime has obvious limitations,
which the NMS developer should have understood when deciding
how to display it.

> Is there any workarounds to this problem we're facing? Are there any plans to increase the RFC1155 definition of TimeTicks to a
higher 64 bit integer value?

I am not aware of any such plans.  Making such a change would require
the creation of a whole new set of objects.  In many cases, however, the
TimeTicks approach no longer makes sense.   You might also take a look
at the material on snmpEngineBoots and snmpEngineTime in RFC 3414
to see how a closely related issue was dealt with.

Randy

---

From: Jon Saperia <[email-masked]>
Date: Wed, 23 Jun 2010 18:54:04 -0400

Why would a whole new set of objects be required to either fix, hrSystemUptime, or create a new higher capacity object?
/jon
On Jun 23, 2010, at 6:17 PM, Randy Presuhn wrote:

> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 23 Jun 2010 16:30:37 -0700

Hi -

> From: "Jon Saperia" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 23, 2010 3:54 PM
> Subject: Re: [OPS-AREA] RFC1155 Timeticks hitting maximum value
>
> Why would a whole new set of objects be required to either fix,
> hrSystemUptime, or create a new higher capacity object?

The question wasn't just about hrSystemUptime, but the fundamental
deficiency of time ticks.

Coming up with a new time ticks syntax would effectively mean
every existing time ticks object would at least need to be
considered for obsolescence, and new objects would need
to be created in appropriate cases.  Counters currently referencing those
time ticks objects as discontinuity indicators would then have to be
considered for update as well, unless we were going to say that
implementations MUST support both representations.  (This quickly
becomes a replay of the 32-bit counter / 64-bit counter / paired-counter
discussion from SMIv2.)

But that really wouldn't address the problem - an existing NMS
application that behaves badly when hrSystemUptime wraps.

Randy

---

From: Jon Saperia <[email-masked]>
Date: Wed, 23 Jun 2010 19:43:48 -0400

But is was in the context specifically of hrSystemUptime - at least that is how I read it.  I was suggesting a surgical fix to a specific problem related to uptime.  That could be fixed with a single object and leave the others that use time ticks intact.

That said, I do agree with you that a good NMS should be able to deal with this and other oddities in this and many other objects.  

/jon

---

From: Mark Ellison <[email-masked]>
Date: Wed, 23 Jun 2010 21:17:16 -0400

Hi-

I would anticipate that an intelligently designed NMS would watch for wrap
on a TimeTicks object by checking for an increment in snmpEngineBoots, or
alternatively, simply watch the value of the snmpEngineTime object, since
its granularity is seconds rather than 1/100th seconds yielding a 40k+ day
wrap interval.

In any case, the target system sure isn't running a MS OS ;-)

Regards,

Mark
--
http://EllisonSoftware.com/

On Wed, Jun 23, 2010 at 7:43 PM, Jon Saperia <[email-masked]> wrote:

> But is was in the context specifically of hrSystemUptime - at least that is
> how I read it.  I was suggesting a surgical fix to a specific problem
> related to uptime.  That could be fixed with a single object and leave the
> others that use time ticks intact.
>
> That said, I do agree with you that a good NMS should be able to deal with
> this and other oddities in this and many other objects.
>
> /jon

---

From: "Gene Matusovsky" <[email-masked]>
Date: Thu, 24 Jun 2010 11:57:42 -0400

Thanks to all on the IETF list for providing solutions and suggestions that could be used to work around the existing 32bit Timetick limit. In our case, our SNMP agent vendor does not currently support snmpEngineTime or snmpEngineBoots. I will ask the developer to look into supporting these objects.

Perhaps another suggestion to the IETF board would be to define a new HC ASN1 Timeticks data type? This would provide compatibility to existing systems using the 32bit Timeticks, and give flexibility to agent developers to use a higher capacity Timeticks data type.

I believe something similar was done with IfInOctets/IfOutOctets when they were extended to "HC" High Capacity 64bit counters in RFC 2863.

On another note, does anyone know a case where a SNMP agent vendor/developer might have "broken the standard" and used 64bit counters for IfInOctets, IfOutOctets or TimeTicks 
Would this break anything in a closed island type Enterprise network? I am considering asking our SNMP agent developer to use 64bit data type for Timeticks on the agent. The NMS system doesn't care or check for standards, it just treats hrSystemUptime as an infinite increasing counter.

-Thanks,
Gene Matusovsky

>>> Mark Ellison <[email-masked]> 6/23/2010 9:17 PM >>>
Hi-

Regards,

Mark

---

From: Jon Saperia <[email-masked]>
Date: Thu, 24 Jun 2010 12:57:30 -0400

Others may, but I am not aware of an implementation of hrSystemUptime as a 64-bit value.  One other solution that would not require a MIB object change since you seem to have development resources available is to fix the NMS.  A simple solution is to watch for the counter wrap in a way that is similar to what people have done for interfaces.

Your suggestion about exploring HC timeticks data objects is interesting, but that would require a working group taking up the activity.

/jon

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 24 Jun 2010 10:01:22 -0700

From: [email-masked] [[email-masked]] On Behalf Of Gene Matusovsky [[email-masked]]
>Would this break anything in a closed island type Enterprise network? 

The common 'breakage' that I'm aware is to not to change the syntax existing counters such as ifInOctets
but to report 64 bit counters ifHCInOctets in SNMPv1.

Mike MacFaden

---

From: "Gene Matusovsky" <[email-masked]>
Date: Thu, 24 Jun 2010 15:00:47 -0400

Workarounds are possible, and can be done, but not everyone has development resources. With todays technology and higher capacity systems, the root of the issue can be addressed directly by extending RFC 1155/ 1902 Timeticks data type. This was done before with RFC 2863, when IfInOctets was updated to IfHCInOctets.

Are there any existing SNMP workgroups or ongoing projects. Perhaps this can be suggested to them, to attach to the next published RFC?

Any pointers would be appreciated.

-Thank You,
Gene Matusovsky

>>> Jon Saperia <[email-masked]> 6/24/2010 12:57 PM >>>

/jon

---

From: Mark Ellison <[email-masked]>
Date: Thu, 24 Jun 2010 16:38:11 -0400

Gene,

Agreed, not everyone has development resources.

However, consider for a moment what you are asking for-  an "HC" version of
hrSystemUptime.  "HC" counters were introduced for the IF-MIB to handle wrap
situations that could occur every few minutes.  In the original post in this
thread, it was noted that hrSystemUpTime can wrap once every 497 days-
approximately every 16 months.

Even if an "HC" version of hrSystemUptime were designed, it would still need
to be implemented within the agents that the NMS will monitor- this would
take development resources, just as would implementing snmpEngineBoots and
snmpEngineTime.  Since the agent being monitored does not support these two
objects, one can safely assume that agent does not support SNMPv3.  In order
to support 64-bit counters, at least SNMPv2c is required since SNMPv1 does
not provide support for "HC" 64-bit counters.  Note that an agent that
implements SNMPv3 can be configured to allow retrieval of the snmpEngineTime
and snmpEngineBoots values via SNMPv2c or SNMPv1 protocol messages.

So, if the agent needs to be changed anyway to support a new object, the
approach that appears obvious to me, would be to upgrade the agent to
include compliant support for SNMPv3, which would make available the
snmpEngineBoots and snmpEngineTime objects for use with the NMS.

Hope this helps!

Regards,

Mark
http://EllisonSoftware.com

On Thu, Jun 24, 2010 at 3:00 PM, Gene Matusovsky
<[email-masked]>wrote:

> Workarounds are possible, and can be done, but not everyone has development
> resources. With todays technology and higher capacity systems, the root of
> the issue can be addressed directly by extending RFC 1155/ 1902 Timeticks
> data type. This was done before with RFC 2863, when IfInOctets was updated
> to IfHCInOctets.
>
> Are there any existing SNMP workgroups or ongoing projects. Perhaps this
> can be suggested to them, to attach to the next published RFC?
>
> Others may, but I am not aware of an implementation of hrSystemUptime as a
> 64-bit value.  One other solution that would not require a MIB object change
> since you seem to have development resources available is to fix the NMS.  A
> simple solution is to watch for the counter wrap in a way that is similar to
> what people have done for interfaces.
>
> Your suggestion about exploring HC timeticks data objects is interesting,
> but that would require a working group taking up the activity.
>
> /jon
> > Thanks to all on the IETF list for providing solutions and suggestions
> that could be used to work around the existing 32bit Timetick limit. In our
> case, our SNMP agent vendor does not currently support snmpEngineTime or
> snmpEngineBoots. I will ask the developer to look into supporting these
> objects.
> >
> > Perhaps another suggestion to the IETF board would be to define a new HC
> ASN1 Timeticks data type? This would provide compatibility to existing
> systems using the 32bit Timeticks, and give flexibility to agent developers
> to use a higher capacity Timeticks data type.
> >
> > I believe something similar was done with IfInOctets/IfOutOctets when
> they were extended to "HC" High Capacity 64bit counters in RFC 2863.
> >
> > On another note, does anyone know a case where a SNMP agent
> vendor/developer might have "broken the standard" and used 64bit counters
> for IfInOctets, IfOutOctets or TimeTicks
> > Would this break anything in a closed island type Enterprise network? I
> am considering asking our SNMP agent developer to use 64bit data type for
> Timeticks on the agent. The NMS system doesn't care or check for standards,
> it just treats hrSystemUptime as an infinite increasing counter.
> >
> > -Thanks,
> > Gene Matusovsky
> >
> >
> > The information transmitted in this email and any of its attachments is
> intended only for the person or entity to which it is addressed and may
> contain information concerning Cablevision and/or its affiliates and
> subsidiaries that is proprietary, privileged, confidential and/or subject to
> copyright.   Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient(s) is prohibited and may be
> unlawful.  If you received this in error, please contact the sender
> immediately and delete and destroy the communication and all of the
> attachments you have received and all copies thereof.
> The information transmitted in this email and any of its attachments is
> intended only for the person or entity to which it is addressed and may
> contain information concerning Cablevision and/or its affiliates and
> subsidiaries that is proprietary, privileged, confidential and/or subject to
> copyright.   Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient(s) is prohibited and may be
> unlawful.  If you received this in error, please contact the sender
> immediately and delete and destroy the communication and all of the
> attachments you have received and all copies thereof.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 24 Jun 2010 20:17:14 -0700

Hi -

> To: "Jon Saperia" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" <[email-masked]>
> Sent: Thursday, June 24, 2010 12:00 PM
> resources. With todays technology and higher capacity systems, the root of the
> issue can be addressed directly by extending RFC 1155/ 1902 Timeticks data type.

Not an option.  SMI rules do not allow this, for good reason - it would change the
on-the-wire representation.   See the ASN.1 in RFC 3416 for an explanation:
the Unsigned32 is tagged [APPLICATION 2], while Counter64 is tagged
[APPLICATION 6].

> This was done before with RFC 2863, when IfInOctets was updated to IfHCInOctets.

No, in that case a *new* object type was defined, because changing the syntax
of IfInOctets was not an option.  IfHCInOctets is a *different* object, not an "update"
to IfInOctets, even though their semantics are remarkably similar.

> Are there any existing SNMP workgroups or ongoing projects.
....

I'm not aware of any where this sort of change would be within scope.

Randy

---

From: "Gene Matusovsky" <[email-masked]>
Date: Fri, 25 Jun 2010 11:15:13 -0400

Mark, thanks for the suggestion. I will look into upgrading our agent to a SNMPv3 compliant.

Going back to general question, given today's technological advances in memory and flash memory capacities, since when RFC 1155 was written, and being that there is a need by the community to increase the Timeticks maximum limit, can a suggestion be made to the IETF to create a new a "High Capacitity" Timeticks ASN.1 data type? 

-Thanks,
Gene

>>> Mark Ellison <[email-masked]> 6/24/2010 4:38 PM >>>
Gene,

Hope this helps!

Regards,

Mark

---

From: Mark Ellison <[email-masked]>
Date: Fri, 25 Jun 2010 19:05:30 -0400

Gene,

I am not aware of the existence of "a need by the community to increase the
Timeticks maximum limit".  You are of course welcome to write and submit an
internet-draft that describes this need and a solution.

Regards,

Mark

On Fri, Jun 25, 2010 at 11:15 AM, Gene Matusovsky
<[email-masked]>wrote:

> Going back to general question, given today's technological advances in
> memory and flash memory capacities, since when RFC 1155 was written, and
> being that there is a need by the community to increase the Timeticks
> maximum limit, can a suggestion be made to the IETF to create a new a "High
> Capacitity" Timeticks ASN.1 data type?
>
> -Thanks,
> Gene
>
> > >> But is was in the context specifically of hrSystemUptime - at least
> that
> > is

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 27 Jun 2010 12:34:05 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Randy Presuhn
> Sent: Friday, June 25, 2010 6:17 AM
> To: Gene Matusovsky
> Cc: [email-masked]

...

Gene,

The OPSAWG can be used to host at least a first proposal, to test if
there is enough interest from the community. The way to go is to submit
an individual Internet-Draft to the OPSAWG for discussion. 

Dan