Subject: RE: [Diffserv] DiffServ MIB rev 12 review

From: "Robert Moore" <[email-masked]>
Date: Fri, 7 Sep 2001 13:08:20 -0400

You're right - it's going to be very difficult for
an agent to determine which row-level indicators to
reset for a given configuration change.  But what
do we expect a management application to do?  We've
set up an architecture that says "It's OK to compute
deltas for a counter, and treat them as valid
management data, unless a designated discontinuity
indicator tells you otherwise."  So maybe we do have
to fall back to a MIB-level indicator that's updated
every time anything in the entire DiffServ
configuration changes.  Each time there's a config
change this will result in a lot of false positives,
where valid deltas for counters unrelated to the
change are treated as invalid.  But this is
preferable to a false negative, where we allow the
management application to treat as valid a delta
that is in fact invalid.

So, whether or not you intended to, I think you've
talked me into a single MIB-level discontinuity
indicator for all the DiffServ counters in the device.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

Fred Baker <[email-masked]>@ietf.org on 09/07/2001 11:46:04 AM

Sent by:  [email-masked]

To:   Robert Moore/Raleigh/IBM@IBMUS
cc:   <[email-masked]>, "Wijnen, Bert \(Bert\)" <[email-masked]>,
      <[email-masked]>
Subject:  RE: [Diffserv] DiffServ MIB rev 12 review

At 05:33 AM 9/7/2001, Robert Moore wrote:

>At one point I think at least some of the counters

>were tied to ifCounterDiscontinuityTime, and that's

>when I raised the question of whether it's possible

>to change an interface's DiffServ datapath

>configuration without taking the interface down to

>make the change.  If this is possible, then I don't

>think that ifCounterDiscontinuityTime is sufficient.

I think this is a very difficult case, and I'm not sure what discontinuity

timer to apply at all, except perhaps one for the entire MIB that says

"something changed", as in a configuration event occurred which may or may

not be relevant to any given counter. Putting a timestamp on each row

doesn't handle it, because you're postulating that the change was that
some

other row was created and pointed at the row in question, which the row
may

not know anything about.

How would you suggest we handle it?

_______________________________________________

diffserv mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/diffserv

Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Fred Baker <[email-masked]>
Date: Fri, 07 Sep 2001 11:11:15 -0700

>indicator for all the DiffServ counters in the device.

any other opinions? I don't know that I see a lot of other MIBs whose 
discontinuity timestamps try to keep track of not-directly-related 
configuration changes. It seems to me that it is perhaps too hard of a 
problem to solve, and that it is actually not a discontinuity in the sense 
that the term is generally used. Other usages of discontinuity timers 
relate to adding and removing interfaces, restarting processes, and so on, 
not reconfigurations.

I could argue that the counters in the count action may start counting more 
stuff if they are fed more traffic, but they will invariably have counted 
the stuff that went by them, both before and after. This is not a 
discontinuity of the counter, but a change in what it is fed. It is 
analogous to an interface going up or down, or the traffic crossing it 
being changed by a change in routing. The counter ifInOctets has not seen a 
discontinuity, but its rate of change is certainly different because it is 
being fed more traffic.

In fact, the more I think about it, I *do* argue that. I think the proper 
use of a discontinuity timestamp is to know when the counter may have 
missed something it was legitimately fed, not when the feed to it changed. 
I think I have argued myself into believing that the Interface's 
discontinuity timestamp is exactly the right discontinuity indicator.

Comparison documents (every current MIB I see that has a discontinuity 
timestamp, plus the SMI comments on discontinuity timestamps):

http://www.ietf.org/rfc/rfc2021.txt
2021 Remote Network Monitoring Management Information Base Version 2
     using SMIv2. S. Waldbusser. January 1997. (Format: TXT=262223 bytes)
     (Status: US:) (Status: PROPOSED STANDARD)

LastCreateTime ::= TEXTUAL-CONVENTION
     STATUS current
     DESCRIPTION
         "This TC describes an object that stores the last time its
         entry was created.

         This can be used for polling applications to determine that an
         entry has been deleted and re-created between polls, causing
         an otherwise undetectable discontinuity in the data."
     SYNTAX TimeStamp

http://www.ietf.org/rfc/rfc2562.txt
2562 Definitions of Protocol and Managed Objects for TN3270E Response
     Time Collection Using SMIv2 (TN3270E-RT-MIB). K. White, R. Moore.
     April 1999. (Format: TXT=110633 bytes) (Status: US:) (Status:
     PROPOSED STANDARD)

   The sliding transaction counter AvgCountTrans is not used for
   updating the MIB object tn3270eRtDataCountTrans: this object is an
   ordinary SMI Counter32, which maintains a total count of transactions
   since its last discontinuity event. The sliding counters are used
   only for calculating averages.

   A discontinuity object, tn3270eRtDataDiscontinuityTime, can be used
   by a management application to detect when the values of the counter
   objects in this table may have been reset, or otherwise experienced a
   discontinuity. A possible cause for such a discontinuity is the
   TN3270E server's being stopped or restarted. This object returns a
   meaningful value regardless of which collection control options were
   selected.

   tn3270eRtDataDiscontinuityTime OBJECT-TYPE
      SYNTAX     TimeStamp
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
          "The value of sysUpTime on the most recent occasion at
          which one or more of this entry's counter objects
          suffered a discontinuity. This may happen if a TN3270E
          server is stopped and then restarted, and local methods
          are used to set up collection policy
          (tn3270eRtCollCtlTable entries)."
      ::= { tn3270eRtDataEntry 20 }

http://www.ietf.org/rfc/rfc2564.txt
2564 Application Management MIB. C. Kalbfleisch, C. Krupczak, R.
     Presuhn, J. Saperia. May 1999. (Format: TXT=183314 bytes) (Status:
     US:) (Status: PROPOSED STANDARD)

   Since rows in most of these tables will come and go with the running
   application elements whose information is contained in them,
   sysUpTime.0 is not appropriate as a discontinuity indicator for
   counters in these tables. By defining separate discontinuity
   indicators for the rows in these tables, entries can come and go as
   needed without causing other objects to appear to have
   discontinuities. As required by [15], the discontinuity indicators
   for the various information objects in these tables are identified in
   the relevant DESCRIPTION clauses. Note that a discontinuity in one
   of these counters does not imply a sysUpTime.0 discontinuity, nor
   does a sysUpTime.0 discontinuity imply a discontinuity in any of
   these counters.

   applOpenChannelOpenTime OBJECT-TYPE
           SYNTAX         TimeStamp
           MAX-ACCESS     read-only
           STATUS         current
           DESCRIPTION
              "This attribute records the value of sysUpTime.0
               when this channel was opened and this entry was added to
               this table. This attribute serves as a discontinuity
               indicator for the counter attributes in this entry
               and for any corresponding entries in the
               applOpenConnectionTable, applOpenFileTable, and the
               applTransactionStreamTable."
           ::= { applOpenChannelEntry 4 }

               the corresponding (same value for applElmtOrSvc,
               applElmtOrSvcId, and applOpenChannelIndex)
               applOpenChannelOpenTime object serves as a discontinuity
               indicator. "
           INDEX          { applElmtOrSvc,
                             applElmtOrSvcId,
                             applOpenChannelIndex,
                             applTransactFlowDirection,
                             applTransactFlowReqRsp }
           ::= { applTransactFlowTable 1 }

http://www.ietf.org/rfc/rfc2578.txt
2578 Structure of Management Information Version 2 (SMIv2). K.
     McCloghrie, D. Perkins, J. Schoenwaelder. April 1999. (Format:
     TXT=89712 bytes) (Obsoletes RFC1902) (Also STD0058) (Status: US:)
     (Status: STANDARD)

   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.

    (paragraph occurs twice, almost verbatim)

http://www.ietf.org/rfc/rfc2863.txt
2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June
     2000. (Format: TXT=155014 bytes) (Obsoletes RFC2233) (Status: US:)
     (Status: DRAFT STANDARD)

   When the new interface is the same as an old interface, but a
   discontinuity in the value of the interface's counters cannot be
   avoided, the ifTable has (until now) required that a new ifIndex
   value be assigned to the returning interface. That is, either all
   counter values have had to be retained during the absence of an
   interface in order to use the same ifIndex value on that interface's
   return, or else a new ifIndex value has had to be assigned to the
   returning interface. Both alternatives have proved to be burdensome
   to some implementations:

   To address this, a new object, ifCounterDiscontinuityTime, has been
   defined to record the time of the last discontinuity in an
   interface's counters. By monitoring the value of this new object, a
   management application can now detect counter discontinuities without
   the ifIndex value of the interface being changed. Thus, an agent
   which implements this new object should, when a new interface is the
   same as an old interface, retain that interface's ifIndex value and
   update if necessary the interface's value of
   ifCounterDiscontinuityTime. With this new object, a management
   application must, when calculating differences between counter values
   retrieved on successive polls, discard any calculated difference for
   which the value of ifCounterDiscontinuityTime is different for the
   two polls. (Note that this test must be performed in addition to the
   normal checking of sysUpTime to detect an agent re-initialization.)
   Since such discards are a waste of network management processing and
   bandwidth, an agent should not update the value of
   ifCounterDiscontinuityTime unless absolutely necessary.

   Note, however, that the addition of ifCounterDiscontinuityTime does
   not change the fact that:

the following paragraph shows up in each counter's DESCRIPTION in the 
Interface MIB:

            Discontinuities in the value of this counter can occur at
            re-initialization of the management system, and at other
            times as indicated by the value of
            ifCounterDiscontinuityTime."

http://www.ietf.org/rfc/rfc2981.txt
2981 Event MIB. R. Kavasseri (Editor of this version). October 2000.
     (Format: TXT=98248 bytes) (Status: US:) (Status: PROPOSED STANDARD)

mteTriggerDeltaDiscontinuityID OBJECT-TYPE
    SYNTAX     OBJECT IDENTIFIER
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
        "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or
        DateAndTime object that indicates a discontinuity in the value
        at mteTriggerValueID.

        This object supports normal checking for a discontinuity in a
        counter. Note that if this object does not point to sysUpTime
        discontinuity checking MUST still check sysUpTime for an overall
        discontinuity.

        Bad object identifiers or a mismatch between truncating the
        identifier and the value of mteDeltaDiscontinuityIDWildcard
        result in operation as one would expect when providing the
        wrong identifier to a Get operation. The Get will fail or get
        the wrong object. If the value syntax of those objects is not
        usable, that results in an error that terminates the sample
        with a 'badType' error code."
    DEFVAL { sysUpTimeInstance }
    ::= { mteTriggerDeltaEntry 1 }

mteTriggerDeltaDiscontinuityIDWildcard OBJECT-TYPE
     SYNTAX     TruthValue
     MAX-ACCESS read-write
     STATUS     current
     DESCRIPTION
        "Control for whether mteTriggerDeltaDiscontinuityID is to be
        treated as fully-specified or wildcarded, with 'true'
        indicating wildcard. Note that the value of this object will
        be the same as that of the corresponding instance of
        mteTriggerValueIDWildcard when the corresponding

mteTriggerDeltaDiscontinuityIDType OBJECT-TYPE
    SYNTAX     INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) }
    MAX-ACCESS read-write
    STATUS     current
    DESCRIPTION
        "The value 'timeTicks' indicates the
        mteTriggerDeltaDiscontinuityID of this row is of syntax
        TimeTicks. The value 'timeStamp' indicates syntax TimeStamp.
        The value 'dateAndTime' indicates syntax DateAndTime."
    DEFVAL { timeTicks }
    ::= { mteTriggerDeltaEntry 3 }

        Bad object identifiers or a mismatch between truncating the
        identifier and the value of mteDeltaDiscontinuityIDWildcard
        result in operation as one would expect when providing the
        wrong identifier to a Get operation. The Get will fail or get
        the wrong object. If the object is not available it is omitted
        from the notification."
    ::= { mteObjectsEntry 2 }

http://www.ietf.org/rfc/rfc2982.txt
2982 Distributed Management Expression MIB. R. Kavasseri (Editor of
     this version). October 2000. (Format: TXT=81371 bytes) (Status: US:)
     (Status: PROPOSED STANDARD)

   The interface-specific discontinuity indicator is supplied only for
   ifInOctets since invalidating that sample will invalidate an attempt
   at evaluation, effectively invalidating ifOutOctets as well
   (correctly, because it has the same indicator).

http://www.ietf.org/rfc/rfc3014.txt
3014 Notification Log MIB. R. Kavasseri. November 2000. (Format:
     TXT=48287 bytes) (Status: US:) (Status: PROPOSED STANDARD)

   The log contains the Notifications and the objects that came in their
   variable binding list, indexed by an integer that reflects when the
   entry was made. An application that wants to collect all logged
   Notifications or to know if it may have missed any can keep track of
   the highest index it has retrieved and start from there on its next
   poll, checking sysUpTime for a discontinuity that would have reset
   the index and perhaps have lost entries.

---

From: Harrie Hazewinkel <[email-masked]>
Date: Sat, 08 Sep 2001 12:32:40 -0700

On 9/7/01 11:11, "Fred Baker" <[email-masked]> wrote:

> any other opinions?

No, I agree here with Fred's view. I believe it is more a decision on
what is a counter discontinuity and what is a configuration change??
Below I have some examples for this. For some I already have 2 answers.

1)
A counter element has a problem.
- Yes, this is a discontinuity.

2)
An agent has a problem and causes a discontinuity for the counters.
Most likely it will be more then 1 counter.
- Yes, this is discontinuity.

3)
A classifier which this counter element feeds has a different range of DSCP
values. Is this a discontinuity of the counter??
- No, the counter is not discontinued, but the configuration changed what is
    counted and the management application needs to learn this.
- Yes, the traffic through the counter has changed and thus it is a
    discontinuity.

4)
An extra element has the counter as the 'next element' causing the counter
to have more traffic. Is this a discontinuity of the counter??
- No, the counter is not discontinued, but the configuration changed what is
    counted and the management application needs to learn this.
- Yes, the traffic through the counter has changed and thus it is a
    discontinuity.

5)
An interface has errors and therefore all traffic passing it influences the
counters later in the data path. Is this a discontinuity of the counter??
- Yes, the data path as seen as 1 object (including counters) is
    discontinued.

6) (partial equal to 5)
An error has happened in a data path element that feeds the counter. Is this
a discontinuity??
- Yes, if the data path is seen as a complete object.

IMHO, it is more a matter of what will we recognize as discontinuity and
what is a configuration change??

As a possible solution I would suggest to get consensus on "what is a
counter discontinuity??" and "what is a configuration change??". Then both
need to be added to the draft.

I also believe we cannot specify all possible cases and thus implementations
will do this differently. The best we can do is provide guidance for
implementors. 

Harrie

> I don't know that I see a lot of other MIBs whose