Subject: Re: question about the sonet mib

From: Kaj Tesink <[email-masked]>
Date: Thu, 31 Aug 2000 16:27:58 -0400

Bryan,

At 08:10 AM 8/30/00 -0700, you wrote:
>hi,
>
>I am wondering if it would make sense to add timestamps to the
>intervals (those 15minute error buckets) so that you know when each
>sample was taken.
>
>for very high density routers (like with thousands of interfaces) its
>not practical (in software) to snapshot all of them at 15minute
>intervals.  however, it IS possible to stagger them over the 15min
>period.  meaning: you do a few interfaces at 00:15:00, then a few more
>at 00:15:05, then some more at 00:15:10, etc.  as long as the -width-
>of each bucket is 15minutes in duration, that's really the key here,
>isn't it?

well, historically there have always been questions about using
an approach based on sysUptime or keeping time buckets (as in 2558)
or keeping absolute time using a "wall clock".
the 2558 method has its roots in traditional telecom equipment.
all methods can be related but as you point out things may have
operational drawbacks.

there have been some proposals before about a "wall clock" timestamp
in the context of a supplemental sonet mib but we havent made progress
yet.
i'll copy this to the atommib wg discussion list for any further comments.
in case you're not subscribed see
http://www.ietf.org/html.charters/atommib-charter.html
for subscription instructions.

kaj

>now if we go with my staggered approach, we really need to know when
>each instance of the table was measured.  sort of like:
>
>table[i].data
>table[i].timestamp
>
>for each i in the instancelist.
>
>I do know that you have sonetSectionIntervalValidData and such; but
>this isn't enough.  its good to know that a slot had invalid
>measurements but how about knowing WHEN those measurements were taken?
>and also perhaps the ACTUAL duration of the width (considering jitter,
>maybe 15.1 minutes one interval and 14.8 the next, etc).
>
>so this might be:
>
>table[i].data
>table[i].timestamp
>table[i].duration
>
>knowing all 3 of these per data point would give the NMS so much more to go
>on.  don't you think?
>
>
>thanks,
>
>--
>Bryan Levin, network management specialist

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
        Red Bank, NJ 07701
        USA

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/