Subject: snmpconf DiffPolicy MIB comments

From: Steve Waldbusser <[email-masked]>
Date: Thu, 03 May 2001 00:25:18 -0700

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.

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.

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.

StorageType

  You should probably add a storageType object or give blanket
  guidance as to what happens on a reboot.

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

   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

---

From: Harrie Hazewinkel <[email-masked]>
Date: Thu, 03 May 2001 13:13:57 +0200

>   simpler than what you had.

Hmm, I have to learn the language better.

>   because it has little to do with Policy and a lot to do with

I agree on this.

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

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

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

---

From: Jon Saperia <[email-masked]>
Date: Thu, 03 May 2001 08:05:30 -0400

I have included only the 1 section on which I have a comment.

> How have they fixed this??

I agree on this point also. There are several places in our technology
where uniqueness is helpful.  This is one - I will look for others as we
do our review. I will also put a note in the BCP.

With regard to the IPSEC Module, I have some writing to do on that with
the other co-authors and will check into it.
> What do others think of this??

This is a general problem. Different implementations will have different
needs, for flash only based systems we certainly do not want to write
with each operation. There are two issues here that are not new and are
related.

        1. Permanence of the change
        2. When activated

Permanence choices:   in memory only
                      in memory and permanent storage
                      to permanent memory (am I wrong that most systems
                      do not give a choice of to disk versus flash - if
                      so and people really felt it were needed you could
                      expand this for flash, disk, etc. etc.)

Activation choices:   Activate now (now can be defined in an object -
                      like a commit, or make active object). Put in the
                      level of granularity needed such as per row, or
                      per table. Up to each table/module designer.

                      Activate on reboot

These give the control to the operations people. If we make the level
very granualar that might be a problem for flash only based systems so
we need to allow the control via mib objects for granularity and let the
operations people be the best judge.

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/