Subject: [Diffserv] DiffServ MIB how to maintain data?

From: Vasil Hnatyshin <[email-masked]>
Date: Mon, 16 Jul 2001 11:26:38 -0400 (EDT)

Hello,
   Sorry for bothering you but I have a question regarding the DiffServ
MIB implementation  and I was not able to find the answer in the
diffServ MIB draft. I'm facing the following problem:

  1. We started a QoS enabled router and created a DiffServ MIB for it.
  2. At some point of time QoS configuration of the router was changed:
e.g. certain classification rules were changed (added and deleted).
  3. The problem is: How should the MIB reflect these configuration
changes?

 Currently I'm considering two possible approaches:

        1. Remove  all deleted Classifier Element entries from the
diffServClfrElementTable (or whatever table that was changed) and add at
the end newly added entries starting from the position
diffServClfrElementNextFree. In this case a entries in the
diffServClfrElementTable will not be contiguous, the space may be wasted
and as the result we may run out of  diffServClfrElementNextFree values
after some time.

       2. After the configuration changes we re-initialize the DiffServ
MIB by re-scanning the current router configuration and re-setting all
the tables. In this case all the Tables will have thier elements ordered
in the contiguos fashion (except for the Data Path Table, which is
indexed by the interface index and direction). However, MIB
re-initializion may mess-up the managers, and cause configuration errors
(e.g. manager may try to set the DiffServ MIB table entries that were
deleted or even worse: entries that were replaced.). On the other hand
individual MIB table entries can not be considered alone without examining
the whole data path starting from the Data Path Table that contains
information about the interface index and direction.
(e.g. SixTupleClassifierEntry.14.2.3 -- means Row Status of the entry that
corresponds to the classifier element #3 that belongs to classfier #2)

 So the question are:
     What the MIB behavior should be in this case?
     Is there an IETF standard for treating cases like this?

  Thank you for your help,
       Sincerely,

 Vasil Hnatyshin.

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

---

From: "Andrew Smith" <[email-masked]>
Date: Mon, 16 Jul 2001 13:19:38 -0700

Vasil,

I think you are misunderstanding the use of the "NextFree" objects. The
manager and agent have a mutual knowledge of which classifier element entry
has which index. You cannot "re-initialize" the MIB and change those index
values. So your option 2 is not viable.

For option 1, why do you need the the entries to have contiguous indices?
Values are not "wasted" (at least in a reasonable implementation) - it is
the agent who chooses what the next free index is to be and it can loop
around when it gets to 2^^32. You will only run out of values when there are
(2^^32-1) classifier elements present - an unlikely scenario (I hope) - you
are more likely first to run up against the capacity of the device to
classify.

If this is not clear from the current draft then let us know (the definition
of the usage has to be clear and complete, although it does not need to be
obvious).

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Vasil Hnatyshin
Sent: Monday, July 16, 2001 8:27 AM
To: [email-masked]
Subject: [Diffserv] DiffServ MIB how to maintain data?

Hello,

 So the question are:

  Thank you for your help,
       Sincerely,

 Vasil Hnatyshin.

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