Re: PerfHist-TC-MIB

jeff@redbacknetworks.com Fri, 05 June 1998 18:23 UTC

Delivery-Date: Fri, 05 Jun 1998 14:23:39 -0400
Return-Path: jeff@redbacknetworks.com
Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA16382 for <ietf-archive@ietf.org>; Fri, 5 Jun 1998 14:23:38 -0400 (EDT)
From: jeff@redbacknetworks.com
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA24833 for <ietf-archive@cnri.reston.va.us>; Fri, 5 Jun 1998 14:26:00 -0400 (EDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id LAA12549 for <trunk-mib@external.cisco.com>; Fri, 5 Jun 1998 11:16:36 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id LAA01247 for <trunk-mib@external.cisco.com>; Fri, 5 Jun 1998 11:16:34 -0700 (PDT)
Received: from mail3.redbacknetworks.com(155.53.200.100) by proxy1.cisco.com via smap (V2.0) id xma001241; Fri, 5 Jun 98 18:16:33 GMT
X-SMAP-Received-From: outside
Received: from starbug.redbacknetworks.com (starbug.redbacknetworks.com [155.53.144.22]) by ns3.redbacknetworks.com (8.8.8/8.8.8) with ESMTP id LAA24560; Fri, 5 Jun 1998 11:12:11 -0700 (PDT)
Received: (from jeff@localhost) by starbug.redbacknetworks.com (8.8.5/8.8.5) id LAA00645; Fri, 5 Jun 1998 11:11:41 -0700 (PDT)
Message-Id: <199806051811.LAA00645@starbug.redbacknetworks.com>
Subject: Re: PerfHist-TC-MIB
To: abbira@aur.alcatel.com
Date: Fri, 05 Jun 1998 11:11:40 -0700
Cc: cteng@nortel.ca, trunk-mib@external.cisco.com, atommib@thumper.bellcore.com
In-Reply-To: <35780133.2F@aur.alcatel.com> from "Rajesh Abbi" at Jun 5, 98 10:31:15 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

> > I remember somewhere in the draft it is indicated that some values might
> > decrease, i.e., not 'monotonically increasing'. For example, some seconds
> > may be counted as "Errored Seconds" but later it is found that they should
> > not be counted in (this decision can not be made any earlier), so you will
> > have to subtract number of them (seconds) from the total count.
> > 
> 
> Are you serious ?
> 
> This is 'flaky behavior' in any equipment ! After a second has expired,
> it was
> either 'errored' or 'non-errored'.  If the equipment cannot make a
> determination,
> it cannot just increment the counter and change its mind later.
> 
> I sure hope there is no such product out there.  Do you have one like
> that ? ;)

anybody who has sonet equipment compliant with ANSI T1.231 has
equipment like that.  an errored second is an errored second unless
it's an unavailable second.  unfortunately you don't know if it's an
unavailable second until up to 10 seconds in the future.  so if you're
doing real-time couting in sonet equipment, you may have to "correct"
counts up to ten seconds in the past as the interface moves in and out
of unavailable time.

the latest sonet mib draft (draft-ietf-atommib-sonetng-02.txt) covers
this in detail, as well as covers a mechanism that utilizes a
10-second shift register to avoid having to make the corrections.

/jeff