Subject: RE: snmpconf A non-trivial policyAction example

From: "Glenn Waters" <[email-masked]>
Date: Fri, 10 Nov 2000 11:55:35 -0500

-----Original Message-----
From: Steve Waldbusser [mailto:[email-masked]]
Sent: Thursday, November 9, 2000 13:35
To: [email-masked]
Subject: Re: snmpconf A non-trivial policyAction example

Juergen Schoenwaelder wrote:

> proc create_hlMatrixControlEntry {s ifIndex} {
>
>     if {[catch {setRowStatus hlMatrixControlStatus} index]} {
>         return
>     }
>
>     lappend vbl [list hlMatrixControlDataSource.$index ifIndex.$ifIndex]
>     lappend vbl [list hlMatrixControlNlMaxDesiredEntries.$index 1000]
>     lappend vbl [list hlMatrixControlAlMaxDesiredEntries.$index 1000]
>     lappend vbl [list hlMatrixControlOwner.$index "policy manager"]
>     lappend vbl [list hlMatrixControlStatus.$index 1]
>
>     $s set $vbl
> }

This API won't work in our environment because agents don't have MIB
compilers and therefore don't know the type of a variable. For example, in
the maxDesiredEntries varbinds above, it's not clear whether to send the
integer 1000 or the 4 character string "1000".
[gww] Actually, a MIB compiler is not needed by the agent - just the output
from the MIB compiler. The output tends to be one or more files that could
easily used by an agent (at least in systems I have used and designed in the
past). Also, if the agent does have access to the compiled MIB the agent
would have access to the type (e.g.: string, integer, etc.) information of
the objects.
I'm definitely interested in continuing to work on the API/language to make
scripts shorter and easier to write.

> This example makes it very obvious to me that actions will be complex
> over time and that a mechanism is needed to write "procedures" (like
> the one above) which you can call and reuse in actions. (I can easily
> imagine cases where a policy rule action instantiates many rows and
> the hlMatrixControlEntry is just one of them.)

Interesting, I had the opposite reaction. I was struck by the fact that the
function was well within a manageable size and that no functional
decomposition seemed obvious.

> Steve> Here's the complete example. The new code is lines 4-9 and 18:
>
> [...]
>
> The fix is flawed as well since the oid in the scratchpad does not say
> which SNMP agent the action is executed on.

This is handled automatically by the execution environment which knows the
address of "this element".

> I am also
> concerned about the error handling - what happens if e.g. snmpsend(0,
> 5, OP_SET); fails with an SNMP error? Will the policy repeat in a loop
> to fire this action regularily??

Yes, and I think this is desired behavior. A policy is trying to enforce a
certain behavior. If the enforcement fails temporarily I think that it
should continue to try. In this case, the maxLatency won't be too high
(maybe run once per hour) and the (computational/operational) cost of
failing is low. In another circumstance where the cost of failing was high,
we could set something in the scratchpad to disable enforcement on this
interface.

Steve
/gww

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 10 Nov 2000 14:45:27 -0800

Glenn Waters wrote:

> [gww] Actually, a MIB compiler is not needed by the agent - just the
> output from the MIB compiler. The output tends to be one or more files
> that could easily used by an agent (at least in systems I have used
> and designed in the past). Also, if the agent does have access to the
> compiled MIB the agent would have access to the type (e.g.: string,
> integer, etc.) information of the objects.

True. My main point is that the SNMP architecture has never required
agents to be datastores of this information (in any format) and that has
been a good thing. This isn't a good time to start.

I'd like to go further before anyone says "Given that this mib is
implemented
on the agent why can't the agent determine an object's type given its
OID?"

First, there are various implementation-specific reasons why a tight
linkage
between the execution environment and the agent may not be possible. The

policy agent might be on a different system than the target system. Even
on the
same system the policy agent and the target agent might be in separate
independent processes (and not using an extensible agent). Even if part
of the same
(potentially virtual) agent, the agent might not offer a name to type
interface.

Second, even if the PM scripting engine can get access to that
information from
the local agent, what if the script is trying to request an object that
doesn't
exist on the local system? Yes, the request will eventually fail, but I
think it
is important to be able to actually create the PDU and send it and get
the
proper failure back from the agent.

Steve

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 11 Nov 2000 15:55:29 +0100

>>>>> Glenn Waters writes:

>> I am also concerned about the error handling - what happens if
>> e.g. snmpsend(0, 5, OP_SET); fails with an SNMP error? Will the
>> policy repeat in a loop to fire this action regularily??

Glenn> Yes, and I think this is desired behavior. A policy is trying
Glenn> to enforce a certain behavior. If the enforcement fails
Glenn> temporarily I think that it should continue to try. In this
Glenn> case, the maxLatency won't be too high (maybe run once per
Glenn> hour) and the (computational/operational) cost of failing is
Glenn> low. In another circumstance where the cost of failing was
Glenn> high, we could set something in the scratchpad to disable
Glenn> enforcement on this interface.

What about broken policy code? Or a broken agent which interacts with
correct policy code? All I am saying is that there needs to be a way
to detect when things go wrong and to allow other entities to find out
what went wrong. But I will shut up on this now.

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