Subject: Re: [Diffserv] We think this is the MIB edits that we are supposed to do

From: [email-masked]
Date: Mon, 7 Aug 2000 15:34:02 -0400

It's possible that the new indexing scheme coming from
Harrie and Kwok will make the point moot, but for now I would
like to see an item to represent the discussion we had in the
WG meeting related to open issue 31.  That discussion ended
with a consensus to remove the OBJECT IDENTIFIER pointers to
the daughter tables, and replace them with Row Pointer objects.
Prior to any indexing changes, this will be easy for
DiffServMeterSpecific and DiffServAlgDropSpecific -- "just do
it."

The situation with DiffServActionSpecific is a little more
complicated.  This object sometimes points to a table (which
could equally well be a row in a table), but at other times it
contains the object identity diffServAbsoluteDropAction.  Thus
it's not eligible in its present form to be converted to a
RowPointer.  This still strikes me as clumsy, but I don't know
how to fix it.  I suppose we could create an artificial,
one-row table to represent absolute dropping, to allow
DiffServActionSpecific to be a RowPointer.  But this is also
clumsy.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 07 Aug 2000 13:48:11 -0700

[email-masked] wrote:
> Harrie and Kwok will make the point moot, 

The indexing schemes are neccessary. IMHO, the following
example proves it.
In the 'dffServClassifierTable' an entry can reside with the following
index:

ifIndex(X).
        diffServClassifierIfDirection(inbound).
                diffServClassifierTcb(Y).
                        diffServClassifierId(Z)

The  'diffServClassifierNext' will point to the next element in the
datapath. What happens if this is for instance a meter defined in
the 'diffServMeterTable' with the index:

ifIndex(X).
        diffServMeterIfDirection(outbound).
                diffServMeterId(Y)

So the index of elements of datapath elements can be
randomly inbound/outbound. Guess what, it is even
applicable to the ifIndex. The ifIndex can also be random.

> but for now I would

I am sorry, but I was not in the diffserv meeting myself.
But is my understanding that the specific tables will
have a pointer to the generic tables??
With other words, a diffServMeterTable entry can be pointed
to by as well a diffServTBMeterEntry and
diffServWindowBasedMeterEntry.
(Assuming the diffServWindowBasedMeterTable will be added.)

This sounds broken to me as a MIB design, but I could be wrong
in the interpretation what you ment as open issue 31..

In addition to this if you would make the SYNTAX-type of
diffServActionSpecific a 'RowPointer', it cannot point to
the diffServAbsoluteDropAction (which is not a row in a table).

Harrie 
0- Harrie Hazewinkel ---------------------------------------0
 mailto:[email-masked]            phone:+1-415-536-5221
0-----------------------------------------------------------0

---

From: Fred Baker <[email-masked]>
Date: Mon, 07 Aug 2000 20:56:52 -0400

>have a pointer to the generic tables??

I don't see how they can. The idea behind the specific tables is that they 
have a set of parameters which might be used in a number of places, and as 
such cannot contain pointers to all of those places.

---

From: Fred Baker <[email-masked]>
Date: Mon, 07 Aug 2000 20:55:33 -0400

At 03:34 PM 8/7/00 -0400, [email-masked] wrote:
>I suppose we could create an artificial,
>DiffServActionSpecific to be a RowPointer.

I personally consider "always" to be an algorithm, just like "sometimes, 
randomly" or "sometimes, when a threshold is reached, from the tail". The 
only substantive difference is that the "next" pointer after "drop 
everything" is probably {0 0}