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

Re: snmpconf well, back to work





Juergen Schoenwaelder wrote:
> 
> I believe that the split between a filter script and an action script
> is not useful. In fact, this level of granularity will just turn out
> to be very impractical if you express real-world policies. I actually
> believe that the unit of concern should be a set of logically related
> policy rules. (This probably maps to the concept of a PolicyGroup in
> PCIM.)

I've been collecting and writing examples and haven't yet come up
with any impracticalities, much less a class of policy scenarios
that aren't handled by this architecture.

The split between filter (aka condition) and action follows
existing practice in other policy work (e.g. the policy WG).

Some of the benefits of splitting them include:

- Because all filter information is separate, the
  manager can inspect the filter and understand whether
  to download the policy to an agent
  (i.e. "this policy will never execute on this system so
   I don't need to download it")
- Because filter information is separate, the agent can schedule
  filter evaluation separately from action evaluation.
  If I have 50,000 circuits, I might not want to evaluate the
  filter as often as I want to assert the action. Conversely, if
  the action is more costly than the filter, I might want the
  filter evaluated more frequently (to more quickly discover new
  elements to which to policy should apply)
- The filter expression is known to be idempotent, information
  that both manager and agent can use for optimization.
- It is easier to re-use filter and action expressions when they
  are separate. Imagine a policy authoring environment that lets
  you drag an icon representing "all ethernet access ports" and
  associate it with an icon representing "mark voice with CP 35".

The split is a fundamental part of the architecture so I expect
we can keep coming up with other existing benefits to add to the
list.

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

This is true only if they were trying to build policy by hand on top of
a scripting system. We are building them an infrastructure (our
standard plus the applications that will stem from it) that will
make it more convenient than doing it by hand.

> I don't see
> much value in taking such a file on the manager side, to tokenize it a
> bit, turn it into chunks of MIB objects that are pushed to the agent
> by populating perhaps multiple tables and then ask the agent to
> reassemble the data and tokenize the rest into a format that can be
> executed.

I'm not sure if you understand the current document. There's no
tokenization or reassembly of code. Each filter or action 
expression contains everything necessary to do its job.

> Of course, once you accept the idea that policy rule sets are the
> right granularity for distribution at the policy level, you can just
> use RFC 2592 to distribute and invoke policy rule sets.  All which is
> left to do is to reach agreement on a policy language and we are done
> with it.
> 
> While reading the minutes form the Friday meeting, I got the feeling
> that RFC 2592 actually provides answers for quite a few of the issues
> discussed in Pittsburgh such as identifying language versions,
> language extensions, handling and reporting of syntactic errors,
> handling and reporting of execution errors, etc. I recommend that this
> WG leverages existing work and focuses the resources that are
> available on the new stuff that is in front of us and that the WG
> reconsiders the granularity needed to distribute policies to
> policy-enabled managed devices.

Our execution environment is much different than that for the 
Script MIB. While the script MIB is for generic scripted
applications, the PM MIB execution environment is purpose-built
for processing policy expressions. We require facilities
that aren't in the script mib such as:

- Our filter expressions are called once for each element.
- Our action expressions are called once for each element that 
  passed the filter.
- Our expressions expect to be passed the identity of the 
  "current element" as a parameter.
- Our environment periodically re-runs expressions

The script MIB also allows things we need to disallow
- Ad-hoc invocation of expressions
- multiple languages
- download of script by http
- Trap sent on every error
- ... (would require thorough analysis to complete this list)

The Script MIB is a great generic scripting mechanism but it
would be very awkward to use for our application because the
differences are greater than the similarities.


Steve