[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf DiffPolicy MIB comments



Steve Waldbusser wrote:
> 
> Here are some comments I had sent privately to David and Harrie
> regarding the diffPolicy MIB.
> 
> Corrections to the code example:
> 
>    Change the code to look like:
> 
>    IF
>       return roleMatch("Administrator");
>    THEN
>       setvar("diffServDataPathStart.$0.2",
>               "diffServActionNext.1", Oid);
> 
>   Regarding the addition of "return" in the filter, this is something
>   that I've been lax on in my own script examples but needs to be
>   there because C/C++ won't return the expression value. I'm going to
>   start being more rigorous in my examples as well.
> 
>   My other change corrects the setvar call. The correct syntax is
>   simpler than what you had.

Hmm, I have to learn the language better.

> 
> Terminology:
> 
>   I suggest that the MIB be called the Diffserv Provisioning MIB
>   because it has little to do with Policy and a lot to do with
>   Provisioning.

I agree on this.

> 
> How to find proper template:
> 
>   An important usability issue is how do I find the proper row in the
>   DiffPolicyDPCTable to clone? These tables are indexed by a random
>   integer assigned by the RowStatus algorithm, so they will be
>   different on each host. NMS code or policyScript code will want to
>   find the proper entry to clone but won't want to have to walk down
>   the whole path checking that the parameters are equal to it's
>   understanding of "gold" (in fact, they'd have to do this N times, as
>   they searched through the templates in the table until they found
>   the one with the proper parameters). If they actually had to scan to
>   find the proper row, they would quickly find that it was easier to
>   just create a new entry than to find an existing entry that matched
>   all the parameters and then clone that one (you'd need to know all
>   the detailed parameters anyway). (When Hongal wrote his example he
>   hid a *lot* of complexity in the getCloneOfDataPath() function
>   call).
> 
>   At first I thought this was a fatal flaw in the whole Provisioning
>   MIB concept but I have a solution.
> 
>   Since integers aren't constant from box to box and aren't long-lived
>   on a box, something else is needed. I'd suggest that an
>   SnmpAdminString be created called diffPolicyDPCName (or ID or
>   something similar). This would be an administratively assigned
>   identifier for a template that would be unique within an
>   adminstrative domain. It is up to the management stations to agree
>   how these are assigned within the administrative domain. But once
>   you assign "gold", that has a certain set of parameters that achieve
>   "gold" from box to box, so NMS code or policyScript code can easily
>   scan the table to find the proper template and then easily assign
>   it.
> 
>   I think this concept will be needed for any xxxProvisioning MIB.

I agree on this. By having a name in the index it could be used
on all systems. This will make writing the policy scripts easier.
I believe that the IPSEC-MIb also has some policy-configuration
capabilities. David P, you know more about this, right??
How have they fixed this??
> 
> StorageType
> 
>   You should probably add a storageType object or give blanket
>   guidance as to what happens on a reboot.

I originally had some storageType and should be added again.
However, there is still a problem related to the approach the
hardware was made. Most DiffServ people told me the use
flash memory and having on each entry a storageType is
problematic. VIa the CLI the use a 'commit' like command.
Should we follow that approach??

What do others think of this??

> 
> Better linkage with Diffserv MIB
> 
>   Personally, I'm a little uncomfortable with the fact that when you
>   write to diffServDataPathStart the behavior is dependent on whether
>   the specified path has something pointing to it. And I'm very
>   uncomfortable that this semantic is not described at all in the
>   diffServDataPathStart object (i.e. you're changing the semantics of
>   diffserv mib objects in a way that isn't documented in those objects).
> 
>   A suggestion would be to have a column in the diffPolicyDPCTable
>   called cloneDest or something like that. If write the value of a
>   diffServDataPathStart instance to this object, it will clone the
>   path at diffPolicyDPCConfiguration and then write into the supplied
>   dataPathStart variable the RowPointer to the cloned path.
> 
>   In other words, setting the Y'th instance of this object to X
>   (object.Y = X) says: "Clone the path associated with Y and then
>   modify X so that it points to the clone".
> 
>   i.e.:
> 
>   Say that a template for gold service is stored at diffServActionNext.5
>   Say that diffPolicyDPCConfiguration.7 == diffServActionNext.5
> 
>   If I snmpset:
>   diffPolicyDPCCloneDest.7 = diffServDataPathStart.10.1
> 
This single 'cloneDest' object prohibits the use of multiple
sets of the same policy on multiple destinations.

Also a problem is how the DiffServ MIB allows datapaths to be shared
over multiple interfaces. The complete cloning or applying of a
configuration can now be done in various ways:

1) Use the template directly.
2) Clone the template for each individual interface.
3) Clone the template but allow them to be used for certain
       groups of interfaces.
4) Clone a template partial, that could mena for instance that
       the beginning of a datapath is cloned to have counters
       for the individual interfaces, but the last part
       of the datapath is shared, for instance a QUEUE.
5) ..........
       probaly more options are available, but the DIFFSERV-MIB
       is a very flexible component and can be used in various
       ways. Depending on the results with the DiffServ MIB
       SNMPCONF has maybe to define objects for this.
       I have somethings in my mind, but not written down.
       (I also wait a bit for the results of the DIFFSERV-MIB,
       but I will soon come with some rough proposals for this)

NOTE: If one would share a datapath over multiple interfaces the
counters
are of course aggregations and not relate to 1 interface.

>    The agent will:
>    1. clone the path at diffServActionNext.5, calling it
>       diffServActionNext.55.
>    2. Set diffServDataPathStart.10.1 = diffServActionNext.55
> 
>   Now diffServDataPathStart.10.1 points to diffServActionNext.55 which
>   describes gold behavior. The DPCConfiguration.7 row was not modified
>   by this operation.
> 
>   If I then want to add gold behavior to ifIndex 11, I set
>      diffPolicyDPCCloneDest.7 = diffServDataPathStart.11.1
>   and now my table looks like:
>       diffServDataPathStart.10.1 = diffServActionNext.55 (Gold)
>       diffServDataPathStart.11.1 = diffServActionNext.56 (Gold)
> 
> Regards,
> Steve

-- 
phone: +39-3474932300
http://www.lisanza.net/