[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf well, back to work
>>>>> 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
(b) represent filters (conditions) and actions as single MIB objects
(c) represent a rule (composed of a filter and actions) as single
(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
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
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.
Juergen Schoenwaelder Technical University Braunschweig
<email@example.com> 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/>