[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf A non-trivial policyAction example
Juergen Schoenwaelder wrote:
> >> The fix is flawed as well since the oid in the scratchpad does not
> >> say which SNMP agent the action is executed on. If you want to use
> >> the action on multiple RMON2 boxes, bad things will happen.
> David> Is the implication of this statement that you are expecting the
> David> execution environment to send SNMP set requests to multiple
> David> other devices in a mid-level manager kind of way?
> David> I see the "sets" in Steve's example as internal within a
> David> device, not something that's sent to other devices.
> Well, I have not been at the interim and so I am only aware of what is
> in the documents. And <draft-ietf-snmpconf-pm-03.txt> says in section
> : - General SNMP Functions
> : The General SNMP functions allow nearly any legal SNMP Message to
> : be generated, including those with multiple varbinds, getNext
> : operations, notifications, and messages with explicit addressing
> : or security specifications.
> To me "messages with explicit addressing or security specifications"
> sounds like you are able to talk to other SNMP engines. But even if
> this WG restricts itself to a single local engine, then the question
> remains which context (perhaps you want to restrict yourself to a
> specific context in an SNMP engine?) and which set of security
> parameters you use (unless you propose to bypass VACM completely -
> which I hope you do not plan to do).
> I personally would like to use a policy configuration engine with
> existing deployed SNMP devices and MIBs. The assumption that each
> and every device implements the policy MIB is in my view not very
Let me try to shed some light on all of this. One important point that will
be made in the following paragraphs is that talking to other systems (over
the network) is, in fact, orthogonal to using explicit addressing or
The architecture specifically allows for the policy MIB to talk to other
systems. One reason this is done is to allow proxy architectures where a
local policy agent can enforce policy on a workgroup of managed systems that
don't support the policy MIB.
The policy agent gathers a set of elements of various types and executes
policies on those elements. The policy agent is free to gather those
elements from any context on the local system and also from remote systems.
It is the job of the execution environment to forward a policy's management
requests to the element. When the execution environment executes a policy on
a non-local element, it sends those requests in SNMP PDUs to the address and
context which are known by the execution environment. In other words, for
this situation, whether elements are local or non-local, the policy code is
the same (devoid of addressing information).
This situation is complete for communications with "this element" and for
other elements related to "this element". However, sometimes in a policy I
will want to read or write information that is in a different context in the
same system. I also can't rule out the need to read or write information on
another system. So for these purposes the PM draft talks about the ability
to address messages to any system/context. This functionality has not yet
been added to the API, but it will be.
Finally, regarding the example code that led up to all of this: the RMON2
"Add alMatrix" policy action code will add an alMatrix entry to any
interface element (on any context/system) managed by the PM agent and
selected by the corresponding policyFilter. It doesn't need addressing
information, even if the PM agent is "proxying" for other systems.