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

Re: snmpconf Policy MIB: elements





Robert Moore wrote:
> 
> 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.

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
 

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

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



> Steve Waldbusser <waldbusser@nextbeacon.com>@snmp.com on 03/08/2001
> 09:22:39 PM
> 
> Please respond to snmpconf@snmp.com
> 
> Sent by:  owner-snmpconf@snmp.com
> 
> To:   snmpconf@snmp.com
> 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