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

Re: snmpconf well, back to work

>>>>> Steve Waldbusser writes:

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

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

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


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