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

Re: snmpconf well, back to work



Juergen Schoenwaelder wrote:
> 
> >>>>> Steve Waldbusser writes:
> 

I agree with Juergen's concerns about the SNMPCONF execution environment
and MIB design.  But I'm not sure I understand the execution flow,
so I'll review how I think it works:

1)  The agent and NMS populate the pmElementTypeRegTable, which specifies
    the static MIB sub-tree (pmElementTypeRegOIDPrefix object) that the
    agent will iterate through, for each element type.
   
2a) If the pmPolicyCalender object is not used, then a pmPolicyFilter
    is invoked in an implementation-specific manner. There is no obvious
    linkage between an individual pmPolicyEntry and the pmElementTypeRegTable,
    but it appears that:
       - a given pmPolicyFilter may only pertain to a single element type
       - the agent must maintain a dynamic mapping between all elements
         and all policies, which may be non-trivial. 
       - both the pmPolicyFilter and pmPolicyAction scripts must assume
         that the appropriate pmElementTypeRegOIDPrefix will be used for
         iteration, because they have no verification. Only the instance
         portion of the complete OID is passed in the 'dollar vars'.

2b) I have no idea how the iteration model works for calendar based policies,
    i.e., which value of pmElementTypeRegOIDPrefix the agent will use when
    the Scheduling MIB invokes the associated (pmPolicyFilter or pmPolicyAction?)
    script.

3) After determining that some elements have 'changed', or perhaps just running
   continuously, within a polling interval specified by the lower bound
   of all pmPolicyFilterMaxLatency objects, the agent selects a pmPolicyFilter
   script and a pmElementTypeRegOIDPrefix. 

4) For each instance in the specified sub-tree (in the same context as the PM MIB 
   I presume) the pmPolicyFilter is executed. The filter logic examines the instance
   info (in the dollar vars), calls accessor functions, makes arithmetic and logical
   calculations, and determines if the implied MIB object is 'selected' by this
   policy. There is no stateful data at all - just the implied MIB root and the
   dollar vars that comprise the 'current' MIB object.

   It's not clear (maybe implementation-specific) if the agent should internally 
   save the selected instances until the end of 'policy invocation', or if it should
   call the associated pmPolicyAction as each selected instance is identified.
   I'll assume the former, although there are will be some policy scripts which
   cannot be written without this unspecified choice impacting the outcome.

5) For each value in the selected instance list (in no assigned order?), 
   the agent invokes the pmPolicyAction script. Again, there is no state
   and no info passed from the policy filter to the policy action.

Given this understanding of the execution environment, I agree with Juergen
that the separation of conditions and actions is less than useful. 

I'll use his example:

     on (condition) do
        action1;
        action2;
     with priority n;

The MIB does not provide any possibility of script sharing, so the (condition)
and (action1;action2) logic is statically and tightly coupled. Separating this logic
into 2 scripts will cause high coupling and low cohesion, which is the
opposite of proper programming practices. This is also confusing.
Most of the execution order and policy selection details are unspecified,
and yet, policy filters must run separately from policy actions. 

It would be better to explicitly define the iteration behavior such
that a selected instance is acted upon at once (inline), rather than deferred
for later processing. This is the 'natural' behavior implied by the
well understood logic example above. A single script is much more readable
and manageable.

Andy


> Steve> The rest is simply Modeling 101:
> 
> Steve> We define different concepts as different objects. Then we
> Steve> structure them to show the appropriate relationships between
> Steve> the concepts/objects.  We shouldn't encode filter and action
> Steve> into the same object for the same reason that we shouldn't
> Steve> encode policyStatus as a decimal number at the end of the
> Steve> policyAction string. We outlawed OPAQUE syntax years ago
> Steve> because of similar bad modeling practices it was abused for.
> 
> This is where we obviously have some disagreement. I think we are
> talking in the policy management context about high-level control
> programs that we want to distribute, invoke and execute. We are not
> talking about fine grained little objects for network element
> monitoring. The modeling practices for network element monitoring
> simply do not fit the requirements for high-level network control
> programming.
> 
> Whenever I write a piece of (control) software, I leave it to the
> execution environment to tokenize the input into an internal format
> that is efficient to execute. I do not expect to be able to tweak this
> internal format. In fact, I am happy with any optimizations the
> executing engine is able to make. Policy control rules are for me just
> another high-level control language and I think that this WG needs to
> discuss which level of granularity makes sense for distributing
> scripts written in this language to policy-aware network elements. I
> am seriously concerned that very fine-grained granularity adds
> considerable complexity without any clear benefits.
> 
> Steve> The point is that stuffing them into one MIB object doesn't
> Steve> meet the requirements (it doesn't encode priority) and was bad
> Steve> modelling practice because it didn't anticipate the full
> Steve> requirements for policy groups.
> 
> I do not agree. I can easily associate a priority to the policy rule
> in the language itself, e.g.
> 
>     on (condition) do
>       action1;
>       action2;
>     with priority n;
> 
> It all boils down to get the policy scripting language definition
> right. We want it to be flexible and efficient and it should run in
> relatively resource constraint environments. I believe that this WG
> should spend all its resources to get the language right rather than
> reinventing wheels that do already exist (both as specifications and
> actual implementations).
> 
> Steve> We agree that filters and actions are separate. We're simply
> Steve> debating what's the best delimiter between filter and
> Steve> action. I'd rather use the existing facilities of the SNMP
> Steve> protocol engine to delimit objects instead of writing code that
> Steve> parses an octet string looking for internal delimiters. Using
> Steve> existing facilities results in 2 MIB objects rather than 1, but
> Steve> results in less code overall because each MIB object is
> Steve> simpler.
> 
> Which I believe is not true if you talk about high-level control
> programs. I still prefer to write my code in C, C++, Java, <fill in
> your favourite language here> and to let the execution environment
> turn it into something that executes efficiently. The parsing is a
> one-time activity when you install a policy script and won't make a
> big difference compared to the overhead of actually evaluating the
> filter conditions regularly. Even the MIB objects currently proposed
> require some amount of parsing on the agent side. (To be consequent in
> your reasoning, you would have to turn an expression into a tree
> representation and download this as a set of MIB objects. ;-)
> 
> Steve> Maybe the script MIB isn't as generic as I maintained. In the
> Steve> script MIB, scripts are started (only) by writing a value to
> Steve> smLaunchStart. In the policy management MIB we need scripts to
> Steve> re-execute automatically based on timer events.
> 
> You can use the scheduling MIB to start scripts automatically based on
> timer events. But even then, I would argue that fine-grained
> evaluation of timed conditions is subject of the language runtime
> system to be really efficient. The scheduling MIB should be used to
> schedule the activation and deactivation of complete policy scripts
> (aka policy groups in PCIM).
> 
> Steve> Further, the Script MIB dictates that scripts are passed the
> Steve> contents of the smLaunchArgument object. In the PM MIB, we need
> Steve> scripts to be passed the index of "this element". I can't
> Steve> imagine a reading of the script MIB that would allow such a
> Steve> change of semantics. I also can't imagine that such a position
> Steve> would be healthy to the future of the script MIB.
> 
> I believe that this is not a problem since I propose to use the script
> MIB only to distribute and activate/deactivate policy scripts that
> contain several policy rules. I believe the timed evaluation of
> conditions and the passing of condition context information to the
> actions is the task of the language and its runtime system.
> 
> Steve> You say that the script MIB doesn't define an execution
> Steve> environment - that may be true for language and libraries, but
> Steve> it definitely not true for scheduling and parameter passing and
> Steve> other areas where it is very explicit and DIFFERENT than the
> Steve> Policy Management MIB requirements.
> 
> In the granularity I propose, the script MIB scheduling and parameter
> passing mechanisms should work just fine.
> 
> Steve> Meta issue: In order to make this work we would have to say
> Steve> that the semantics of a registered MIB object are not forever
> Steve> defined by the description clause, but can change in
> Steve> unanticipated ways based on what other MIB object is "pointing"
> Steve> to them. This seems to shake the foundation of our SMI
> Steve> framework.
> 
> I do not understand. Which registered MIB object are you talking
> about?
> 
> Steve> We agree that policy groups will be required for complex
> Steve> policies on complex networks. However, you're confusing the
> Steve> encoding of policies with the modeling of policy
> Steve> relationships. Encoding two things into one object has never
> Steve> been the desirable way of modeling a relationship between them.
> 
> I believe that any programming language with conditional statements is
> a viable counter argument to this statement. And I am not even
> considering real rule based languages which I used back in those days
> when expert systems were changing the world as policy systems do
> today. ;-)
> 
> /js
> 
> --
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  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/>