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

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

First, I agree with Fred and Andrew that since the
entries in the DiffServ MIB tables encompass all the
interfaces in the box, with just simple integer
indexes, a per-MIB or per-table discontinuity
indicator just isn't going to be sufficient.

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.
Suppose, for example, that because of a change in
Classifier configuration, a point in the datapath
that used to see packets with DSCP 10 now sees
packets with DSCPs 20-30.  If the element at this
point in the datapath is a counter, it's nonsense
for a management application to take a delta between
the counter value at some time before the
configuration change and its value at some time
after the change, since this will combine counts of
two different classes of packets.  So there needs
to be a way to tell the application not to take
this delta.

I'm also not sure about Bert's statement that per-row
discontinuity indicators are unusual.  Certainly
ifCounterDiscontinuityTime is a per-row object, and
we defined several more such objects back when we
were doing the SNA MIBs.  I think we should just
think through the circumstances in which we need
for the agent to tell the management application
"Don't take a delta!", and then let the
discontinuity indicators fall wherever they fall.

Regards,
Bob

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

"Andrew Smith" <[email-masked]>@ietf.org on 09/06/2001 07:21:19 PM

Please respond to <[email-masked]>

Sent by:  [email-masked]

To:   "Fred Baker" <[email-masked]>, "Wijnen, Bert \(Bert\)"
      <[email-masked]>
cc:   <[email-masked]>
Subject:  RE: [Diffserv] DiffServ MIB rev 12 review

I thought that, when we originally discussed this, that we wanted to have

discontinuity indicators at the interface level, but I don't recall why we

decided not to do that.

I agree with Fred that per-MIB or per-table is not sufficient and I agree

with Bert that per-row seems like overkill. Another alternative might be
to

tie this to the entity MIB e.g. with an OID-pointer - I remember
discussing

that with some people at one of the early snmpconf meetings but the
feeling

seemd to be that entity MIB was not implemented widely-enough for this to
be

viable. Is this something for a new "Discontinuity Indicator MIB"?

Andrew

-----Original Message-----

From: [email-masked] [mailto:[email-masked]]On Behalf

Of Fred Baker

Sent: Thursday, September 06, 2001 3:13 PM

To: Wijnen, Bert (Bert)

Cc: [email-masked]

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

At 05:08 AM 9/2/2001, Wijnen, Bert (Bert) wrote:

>13. You seem to have discontinuity timestamps (like the

>     diffServCountActDisconTime) per row. Is this really

>     what you want? I don't think I have ever seen it

>     implemented at the row level. I don't think that that

>     is what we intended discontinuity timers for either.

>     It seems to add an extra object to each row while I

>     wonder if discontinuity indeed

>     - happens often

>     - if it does happen, does it then only apply to

>       one row, or does it apply to multiple or possibly

>       all rows in the table.

>     A discontinuity timer per table or per MIB is what

>     we have seen more often.

>     This has been done in a few more tables, so it applies

>     to them as well.

Willing enough to move it to the table (right beside ...NextFree) or to
the

MIB level. It seems, though, that this makes an assumption about the

operating system which is problematic. If the architecture of a single CPU

which controls and manages a few devices - the usual low-end router design

- fine. If you have a distributed system, in which you can pull out

interface cards or add new ones, which themselves implement the
forwarding,

the diffserv processing, and by the way the counters, a discontinuity

timestamp for the table or MIB seems to not serve.

before writing this, though, I did a bunch of research. What would you

think of copying the 802.3 MIB's approach? From RFC 2665's

dot3StatsAlignmentErrors:

       ...

       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."

_______________________________________________

diffserv mailing list

[email-masked]

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

Archive:

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

tml

_______________________________________________

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 08:46:04 -0700

>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?