Subject: Re: snmpconf Policy MIB: elements

From: "Robert Moore" <[email-masked]>
Date: Fri, 9 Mar 2001 10:50:29 -0500

Steve,

Thanks for the detailed reply.  I'll try to give you some
editorial suggestions later, but the key idea here is
that for a multi-table element, everything is done by
means of the "first" table.  I think I started off down
the path of focusing on the "second" tables because I
was unconsciously equating Element Types with Policy
Roles (in the PCIM sense).  These Policy Roles are
usually at the level of Dot3Interface or
FrameRelayInterface, rather than at the higher level of
Interface.  (It's certainly possible to imagine policies
that are supposed to apply to all interfaces -- this
just isn't the typical case.)  So I guess part of the
message needs to be that an Element Type *isn't* a
Policy Role.  It's more like just a vehicle for getting
to instance identification information to go into your
.$0's.

One question does come to mind: is there always going
to be a "first" table to serve as the point of contact
for an element type?  I tried to build a counterexample,
where there were two tables that both shared an INDEX
consisting of one object from the first table and one
object from the second table.  SMICng grumbled about
this (W: f(tester.mib), (52,15) Row "firstEntry" does
not have a consistent indexing scheme - index items from
containing row must be last in the INDEX clause), but
it didn't flag it as an error.  So I'm not sure exactly
how to express the idea that an element type is
identified by / associated with its "first" table.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

Steve Waldbusser <[email-masked]>@snmp.com on 03/08/2001
09:22:39 PM

Please respond to [email-masked]

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: snmpconf Policy MIB: elements

Hi Bob,

  You bring up some good questions. Let me try to clarify here and
figure out how to make the document more clear.

Robert Moore wrote:
>
> Clearly the concept of an element is at the very
> center of the Policy Management MIB.  But I'm having
> a hard time getting my hands around this concept
> I can break my questions down into three broad groups:
>
> 1. The Element Type Registration table
>
>    In the discussion in Section 6.1, much of which
>    is repeated back in the MIB module, I'm confused
>    about the relationship between elements, element
>    types, and entries in the table.  I think part of
>    the problem is just bad terminology; for example,
>    I think that "Note that agents may automatically
>    configure elements in this table..." is really
>    saying "...agents may automatically configure
>    *entries* in this table...,"

Exactly. And it's not bad terminology, it's wrong terminology - it was a
typo.

> where these entries
>    correspond to element *types*, not to elements.

Yes.

>    The next few sentences blur the picture, however,
>    by bringing in discover of *elements* (like the
>    asynchronous notification of new elements like
>    "card inserted" -- here this does seem to be
>    talking about an element rather than an element
>    type).

Yes again.

The talk about elements occurs for the following reason.
   The 3 paragraphs starting with "Note that agents..." are dealing
   with elementType entries that come installed "out of the box". The
   agent might want to install some entries for convenience sake
   (saving some set requests), but there are a couple of reasons that
   are much more compelling:

   1) The agent might have specialized code that scans internal data
   structures for certain element types rather than doing a getNext
   walk; or,
   2) The agent might be able to register for a card-inserted
   interrupt or signal and learn of elements without polling.

   These reasons are much more compelling because they require
   specialized code per element type - stuff that ain't gonna happen
   automatically by decoding some new OID value. In other words, while
   I can teach an agent to walk a new table by downloading a new OID,
   I can't cause it to grow new code for these specialized
   techniques. So since the code is already hardwired, and thus the
   support for the elementType, the agent can hardwire the
   elementTypeRegEntry and make everyone's life easier.

This wasn't intended to blur things by talking about elements but to
describe the pre-installed behavior of elementTypeRegEntries.

>  Elements exist in their own tables, not
>    in this table.  So it's a bit confusing for them
>    to come into the discussion at this point.
>
>    Here's what I make of this table.  The first
>    question is, am I right?  Second, can the document
>    say whatever is right here a lot more clearly than
>    it does?
>
>    a. The entries in the table correspond to element
>       types.  They can be created either via a
>       management flow or by the agent.
>    b. For each element type, the agent has a means of
>       discovering elements of that type.  These means
>       may be different for different types.
>    c. For some element types, the agent will create
>       a new element type entry in this table when it
>       discovers the first element [instance] of that
>       type.  Discovery of subsequent elements of the
>       type will have no effect on the table.  (Or do
>       these entries corresponding to "frequently used
>       element types" exist all the time, even before
>       the agent has discovered the first element of
>       the type?)

A and B are correct, but C isn't.

The agent won't do discovery of elements that aren't listed in the
elementTypeRegTable. In most cases the manager writes an entry into the
table, in effect saying "I want to have some policies that act on
elements of the following type. Please discover and manage execution for
elements of this new type". So if ifEntry is not represented in the
table, policies will not be run on interfaces. Further, even if there
are no circuits at the moment, there can be a frCircuit entry in the
table that causes the agent to continuously check for new circuits.

> 2. Elements in general
>
>    The first paragraph in Section 6.1 makes a
>    distinction between what I'll term "single-table
>    elements" and "multi-table elements".  Most of my
>    element questions pertain to multi-table elements;
>    they're below, under number 3.  I do have one
>    question even for single-table elements, though.
>
>    The question is, why is *any* columnar OID allowed
>    to identify an element type, leading to the
>    clumsy-sounding rule that to detect duplicate
>    element types, the last arcs of their OIDs must
>    be ignored?  Is there any reason the OID for a
>    (single-table) element type can't be defined to be
>    the first accessible column in the table, similar
>    to how the RowPointer TC is defined?

Maybe it could be, I was just trying to be careful. It was hard to
declare at the moment I was writing that text that: "the first
accessible column in the table will *always* be appropriate". On the
other hand, I really can't think of any reason why not.

> 3. Multi-table elements
>
>    Here's where I really get lost.  Taking the
>    example from Section 6.1, an entry in the ifTable
>    and the entry in the dot3Stats table with the
>    same value for ifIndex together make up one
>    element.

Assume this baseline "normal" code (a filter):

    if (insubtree(elementName(), "ifEntry")
        && getvar("ifOperStatus.$0") == 1)
        return 1; // Match
    else
       return 0;

What I'm trying to say is the following code is also valid:

    if (insubtree(elementName(), "ifEntry")
        && getvar("ifOperStatus.$0") == 1
        && getvar("dot3StatsDuplexStatus.$0") == 2)
        return 1; // Match
    else
       return 0;

Note that the element type is ifEntry, and we are using the address of
ifEntry elements ($0), but we are using dot3StatsDuplexStatus as one of
the "attributes" of this element. We don't need to create an elementType
for dot3Entries.

Let me add that the agent doesn't need to know that this is happening.
It doesn't need to be set up to know that $0 will also index
dot3Entries. It just blindly replaces $0 with the current value of
ifIndex for elements of type interface. Only the script writer needs to
know which tables share the same index and can thus be modeled this way.

Maybe part of the problem is that the topic sounds complicated
("abstract superclass" and so on) and yet the mechanism is so blindingly
simple ("blindly replacing $0").

> For cases like this, where there's a
>    second table that reuses ifIndex, it seems like
>    the element type should correspond to the second
>    table -- say, "dot3Interface".

I don't see why this is so.

In fact, it is very important that the ifEntry type be registered
because it is the one that is guaranteed to discover all interface
instances (registering dot3Entry would only find a subset).

>   But in other cases
>    there is no second table: all the information that
>    exists for an interface is in the ifTable.  In
>    these cases it seems like the element type will
>    have to be just "interface".

Ditto.

>    The problem here seems to be that in some cases,
>    "interface" and the ifTable function like an
>    abstract superclass, while in other cases they
>    function like a concrete class.  I'm not sure how
>    to represent this in the Element Type Registration
>    table.  If there's an entry there for "interface"
>    (needed for the interface types that don't have a
>    "second" table), and also one for "dot3Interface",
>    then what does an instantiated dot3Interface
>    correspond to?
>
>       - an element of the type "interface"?
>       - an element of the type "dot3Interface"?
>       - an element of both types?
>       - two elements, one of each type?

You really only want to register ifEntry. If you *did* register both, I
suppose the answer would be "two elements, one of each type". More
concretely speaking, an entry in the dot3StatsTable would have a policy
executed twice on it, once as an interface and once as a dot3Interface.

>    It's also not clear what happens when there are
>    multiple "second" tables, as there are in a number
>    of standard MIBs (and even more so when you bring
>    in vendor extensions to standard MIBs).  Does an
>    element correspond to the union of all the table
>    entries in the agent that share the same index
>    values?  If so, what is its element type?  Without
>    a clear answer to this question, the algorithm for
>    detecting duplicate element types (strip off the
>    last arc of the OIDs, and compare what's left)
>    won't work.

I hope my answers above make this more clear. Just register ifEntry and
all will be fine. There will be no duplicates. You will be able to use
$0 as the index to attributes that are in the ifTable, the
dot3StatsTable, the Dsx1ConfigTable, or a private locIfTable.

If you were to register the "second" table (there's no law against it),
there would be no duplicate detection (the agent doesn't really know
enough to do such duplicate detection anyway).

>    A third question relates to the various RowPointer
>    objects in the MIB that point to multi-table
>    elements.  As RowPointers, these objects must
>    point to the first accessible object in a
>    conceptual row.  But conceptual row in which table?
>    The rows that together make up a multi-table
>    element will share index values, but they don't
>    share their tabular/columnar OIDs.  So these
>    RowPointers will be different, depending on which
>    of an element's tables they point to.

Again, don't register the "secondary" tables. But if you did, the roles
registered to the base element type will not be registered to the
secondary element type. So if you wanted to make this work (no reason
you would) you would have to register the same roleStrings to
dot3StatsIndex.7 as you did to ifIndex.7, and so on.

> By the way, I apologize a little if any of this has
> been discussed on the list over the past couple of
> months, while I've been buried in PCIM Extensions.
> But I don't apologize very much:  by the time we're
> done, the information must be in a form where it's
> communicated by the document alone, without reference
> to any outside knowledge.  So think of me as an early
> test case of a reader coming into this material cold.

You're off the hook on both counts. It hasn't been discussed and even if
it had, you're right: it needs to be readable by people who will never
participate in our discussions.

Unfortunately in this message I haven't proposed any wording changes to
help out. Can I propose that once I get you on the right track, that you
might be able to help by pointing out what text set you on the wrong
path or with suggestions on a more clear way to describe this?

Thanks,
Steve

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 09 Mar 2001 18:02:36 -0800

Yes.

BTW, not at all related to your statement, but I was thinking of another
way to describe all of this:

  If you have the following entries in the ifTable:
    ifIndex.1
    ifIndex.2
    ifIndex.7
    ifIndex.13

  and you have registered "ifIndex" in the elementTypeRegTable, then
  your policy will be called 4 times. The arguments of each call will
  be:
     call #1:  elementName=ifIndex.1, $0 = 1
     call #2:  elementName=ifIndex.2, $0 = 2
     call #3:  elementName=ifIndex.7, $0 = 7
     call #4:  elementName=ifIndex.13, $0 = 13

  Similarly, if you have the following entries in the frCircuitTable:
    frCircuit.7.27
    frCircuit.7.345

  and you have registered "frCircuitIfIndex" in the
  elementTypeRegTable, then your policy will be called 2 times. The
  arguments of each call will be:
     call #1:  elementName=frCircuitIfIndex.7.27, $0 = 7, $1 = 27
     call #2:  elementName=frCircuitIfIndex.7.345, $0 = 7, $1 = 345

> identified by / associated with its "first" table.

Yes, you can have a table like you describe. You'd need it if you wanted
to associate repeater ports (RFC 1516) with interfaces, for example.
This "ifPortAssocTable" would have INDEX { ifIndex, rptrPortIndex }.

Chances are you have a reason to run policies on all interfaces and also
on all repeater ports. You'd register ifEntry and rptrPortEntry in the
elementTypeRegTable. This gives you an execution context for each
interface and for each repeater port. Let's say you decide you also need
an execution context for each ifPortAssocEntry. There are three options:

1) Have an interface policy that iterates (walks) through each
ifPortAssocEntry:
  //  snmpwalk ifPortAssocStatus.$0, executing your code on each
returned row
  var oid = "";
  while(searchcolumn("ifPortAssocStatus.$0", oid, "*", 5)){ // match
every row
    // insert your code here
    // oid contains a row in the ifPortAssoctable for interface $0
  }

2) Have a port policy that iterates (walks) through each
ifPortAssocEntry:
  Like above, but this is harder because you can't just walk the $0 
  subtree of ifPortAssocEntry

3) Register the ifPortAssocTable in the elementTypeRegTable
  Now I can have an ifPortAssoc policy that is automatically executed
for 
  each entry in the table. $0 will be the ifIndex and $1 will be the 
  rptrPortIndex.

How does the policy author choose? It's not like I have a lot of
experience choosing (yet), but here are a few considerations:
A) Is the ifPortAssocEntry "real"?
   In this case it isn't a real entity but just an association. I'd be 
   less inclined to model it as an element and therefore more inclined 
   to choose 1 or 2.
B) How many instances of ifPortAssocEntry are there?
   If there are *many* instances in the ifPortAssocTable, I'd probably
   want the execution environment to do the iteration instead of the
   while loop in my script. Scripts are slower and single-threaded while
   the execution environment can be multi-threaded (i.e. execute
multiple
   ifPortAssocEntries at once). Many instances would push me towards #3.
C) How many policies would use this element type?
   Is this the only policy that will iterate the ifPortAssocTable? If 
   it's the only one, I may be swayed towards #1 or #2. I say this even 
   though I am mindful that the cost of an entry in the
   elementTypeRegTable is pretty low. It may just be superstition on my
   part. I guess my preference would be to see the elementTypeReg table
   be pretty clean and not have many one-offs in there so that it looks
   less complex

Steve

P.S. More on the topic of "fun with element addresses" AKA "exploring
the object-orientedness of this model":

It's often easy for a policy to address related parent elements.

Say you've registered "frCircuitIfIndex" in the elementTypeRegTable.
$0 is the ifIndex and $1 is the DLCI of "this element".
You get the commited burst rate with frCircuitCommittedBurst.$0.$1

Say I need to find out the port speed of the port this circuit is on.
Very simple: ifSpeed.$0