Subject: RE: snmpconf well, back to work

From: "Durham, David" <[email-masked]>
Date: Mon, 11 Sep 2000 14:10:26 -0700

I also agree with Juergen that the MIB-level distinction between conditions
and actions is wrong. If the language comprises the syntax, than there
should be no distinction at all within the MIB itself. I have stated before
that representation of the rule as the atomic level of access is most
logical. I also agree that the scripting MIB can and should be leveraged for
this work. No sense in reinventing its useful concepts again.

Once the language concept was introduced for SNMPCONF, it follows that the
generality of the language syntax becomes a feature. What you consider an
atomic action today may very well become itself a conditional action
sequence tomorrow. So it is better to look at actions as independent
procedures/operations, procedure invocation being determined from a set of
one or more if-then statements. 

So as a flow:

StartProcedure{ConditionStatements->ConditionalProcedures}
ConditionalProcedures{ConditionStatements->ConditionalProcedures}

To me, an action is simply an independent (shared) procedure call that may
then have a scripted set of conditions/procedure calls as well as MIB
variable manipulations. All that is left is determining where to start, and
here a MIB definition would be valuable. A MIB can define the start
procedure, timed/periodic procedures, and asynchronous event-triggered
procedures... Concepts that have real semantic value. 

Cheers,
-Dave

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> 
> >>>>> Steve Waldbusser writes:
> 
> Steve> I've been collecting and writing examples and haven't yet come
> Steve> up with any impracticalities, much less a class of policy
> Steve> scenarios that aren't handled by this architecture.
> 
> Steve> The split between filter (aka condition) and action follows
> Steve> existing practice in other policy work (e.g. the policy WG).
> 
> I am not arguing against the conceptual distinction between a policy
> condition (or policy filter) and a policy action. This is fine as long
> as we all believe in the rule-based approach, which I take as a given
> at this point in time.
> 
> [One can question the rule based approach itself, but this really
> falls out of the scope I think. ;-]
> 
> I am questioning whether it is useful to represent this distinction in
> the MIB. This WG is using a lanuage based approach to describe policy
> filters and policy actions. It is possible to
> 
> (a) represent each atomic statement of this language as single MIB
>     objects
> 
> (b) represent filters (conditions) and actions as single MIB objects
> 
> (c) represent a rule (composed of a filter and actions) as single
>     MIB objects
> 
> (d) represent sets of rules (a policy group) as single MIB objects
> 
> I believe that sets of related policy rules (a policy group) form a
> high-level control construct and that it is useful to transfer and
> invoke them as single logical entities. In this model, the execution
> environment is required to take such a high-level control construct
> and to transform it into an internal representation that can be
> executed effectively. I also believe that policy rule changes do not
> happen in real-time. So any attempts to introduce a "peek and poke"
> capability to modify policy rule sets on the fly seem wasted to me.
> 
> Steve> Some of the benefits of splitting them include:
> 
> Steve> - Because all filter information is separate, the manager can
> Steve> inspect the filter and understand whether to download the
> Steve> policy to an agent (i.e. "this policy will never execute on
> Steve> this system so I don't need to download it") 
> 
> But the same thing can be done by letting the manager generate a
> policy rule script which is specific to the capabilities of the
> agent. I don't think there is any significant advantage here for this
> optimization from the granularity of the MIB objects.
> 
> Steve> - Because filter information is separate, the agent can
> Steve> schedule filter evaluation separately from action evaluation.
> Steve> If I have 50,000 circuits, I might not want to evaluate the
> Steve> filter as often as I want to assert the action. Conversely, if
> Steve> the action is more costly than the filter, I might want the
> Steve> filter evaluated more frequently (to more quickly discover new
> Steve> elements to which to policy should apply)
> 
> An execution environment can easily extract the filters from a policy
> script and do what you describe above. The agent has to do some
> parsing anyway and being capable to extract filters won't add much
> overhead. In fact, since the agent does not forced to export the
> internal representation as (writable) MIB objects, you will actually
> be able to reduce significantly the complexity of the agent.
> 
> Steve> - The filter expression is known to be idempotent, information
> Steve> that both manager and agent can use for optimization.  
> 
> I don't think this has any implications on the granularity with which
> you communicate policy rules between the policy manager and an agent.
> 
> Steve> - It is easier to re-use filter and action expressions when
> Steve> they are separate. Imagine a policy authoring environment that
> Steve> lets you drag an icon representing "all ethernet access ports"
> Steve> and associate it with an icon representing "mark voice with CP
> Steve> 35".
> 
> I do not see why this is so much simpler. In the current approach, the
> manager needs to search for a suitable filter. If it finds one, you
> add another action to it. If there is no suitable filter, you create
> one and add a action to it. The same will happen if your policy script
> language combines filters and actions. The difference is only that the
> current approach may do the addition by editing the MIB in place while
> the proposed approach will push a new policy group to the agent.
> 
> I believe that this is actually a plus since I do not believe that a
> decent policy tool will modify any systems while a human edits policy
> rules. In fact, I believe that all the drag & drop policy editing is
> finished before you hit the install button in your policy tool (at
> which point in time the policy tool does some conflict detection and
> optimization and pushes the policies into the devices, potentially
> adapted to the device capabilities).
> 
> Steve> The split is a fundamental part of the architecture so I expect
> Steve> we can keep coming up with other existing benefits to add to
> Steve> the list.
> 
> As I said before, I do not argue against the policy filter / policy
> action concept here. (BTW, what precisely is the difference between a
> policy filter and a policy condition? Why does this WG not use the
> commonly used term policy condition?) I am arguing that the choosen
> granularity with which you communicate policy rules between a policy
> manager and a policy-aware agent is wrong.
> 
> >> I also expect that network operators will prefer to write and
> >> handle sets of logically related policy rules in a single language
> >> and to store them in a single file which they push to the managed
> >> devices.
> 
> Steve> This is true only if they were trying to build policy by hand
> Steve> on top of a scripting system. We are building them an
> Steve> infrastructure (our standard plus the applications that will
> Steve> stem from it) that will make it more convenient than doing it
> Steve> by hand.
> 
> You may have a nice GUI policy tool. But even then, having this tool
> generate a nice readable format in a human readable policy scripting
> language will be valuable - and if it is for debugging purposes only.
> 
> Steve> Our execution environment is much different than that for the
> Steve> Script MIB. While the script MIB is for generic scripted
> Steve> applications, the PM MIB execution environment is purpose-built
> Steve> for processing policy expressions. We require facilities that
> Steve> aren't in the script mib such as:
> 
> Steve> - Our filter expressions are called once for each element.  -
> Steve> Our action expressions are called once for each element that
> Steve> passed the filter.  - Our expressions expect to be passed the
> Steve> identity of the "current element" as a parameter.  - Our
> Steve> environment periodically re-runs expressions
> 
> The script MIB does (on purpose) not define any particular execution
> environment. This WG can of course define a policy scripting language
> execution environment which takes a policy script and executes it with
> all the features you have listed above. The fact that the script MIB
> is generic makes it applicable to this (and other) problem domain.
> 
> Steve> The script MIB also allows things we need to disallow - Ad-hoc
> Steve> invocation of expressions - multiple languages - download of
> Steve> script by http - Trap sent on every error - ... (would require
> Steve> thorough analysis to complete this list)
> 
> Ad-hoc invocation of policy groups does not seem like a bad thing to
> me. Multiple languages is no issue since this WG can standardize a
> policy scripting language for interoperability. Download from URLs
> (not only HTTP) will be very convenient, especially when policies
> become larger. Getting notifications on errors is useful. And you can
> turn them off by some standard SNMPv3 configuration if you really do
> not care if your policy system goes crazy.
> 
> Steve> The Script MIB is a great generic scripting mechanism but it
> Steve> would be very awkward to use for our application because the
> Steve> differences are greater than the similarities.
> 
> Which I do not believe. 
> 
> Once again, the key difference is at which granularity you communicate
> policy rules between the policy management tool and the policy
> execution environment. I have listed four alternatives at the
> beginning of this email. I believe that only (d) makes sense for any
> system of serious size and complexity. (c) may still work for networks
> which only require a few policy rules - that is basically new networks
> that still have a consistent design.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder      Technical University Braunschweig
> <[email-masked]>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 
> Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> 
> 
>

---

From: Jeff Case <[email-masked]>
Date: Wed, 13 Sep 2000 09:29:53 -0400 (EDT)

>You are probably refering to pmTrackingPolicyToElementStatus and
>pmTrackingElementToPolicyStatus (since these are the only status
>objects I could find that are not RowStatus). In this case, you talk
>about the binding of policy conditions to the set of elements (or
>targets). I believe this can be handled appropriately in a pure
>language based approach as well. And even if this WG needs to
>introduce new tables to provide additional interfaces, I still believe
>that working from existing MIBs which have been specified and
>implemented is worth to be seriously considered.

i agree with your last statement

the incorporation of work from other mib documents has been considered,
is being considered, and will continue to be considered

the disman work that you are pushing for has specifically been considered

so far, a convincing case for the incorporation of that work has not happened

leveraging that work does not appear to have a good pain/gain tradeoff
but it is still being discussed actively

regards,
jdc

---

From: Jeff Case <[email-masked]>
Date: Wed, 13 Sep 2000 09:30:46 -0400 (EDT)

i wonder if it is time to start using different subject lines for
various threads

if not, perhaps we could pick a new subject line to use for everything for
a while

:-)

regards,
jdc