Re: Help/guidance on L2TPv3 MIB draft

[Mark Ellison <ellison@ieee.org>]

Hi Margaret,

There is a trade off, with respect to subagents, when implementing AgentX
subagents.

Most of the problematic issues revolve around tables for which there are
"companion scalar attributes".  The most referenced example is ifNumber and
ifTable.

One of the goals for AgentX is to provide a means for horizontal slices
(rows) of tables to owned by different subagents.  So the problem becomes
which subagent knows the (accurate) value of ifNumber when several
subagents each own rows presented during a walk on the ifTable.

As an implemtor, the following are solutions I can think of.

(1) don't design MIB modules with "companion scalar attributes" like
ifNumber.  ifNumber is kind of an extreme example, as you have pointed out.

(2) use an "orchestrator subagent" that registers for the companion scalar
attributes that can return a correct value.  (Note that an orchestrator
subagent that registers the OID just above the table attributes (e.g.
ifEntry or ifTable) is necessary whenever a row can be created within the
table.)

(3) implement the "companion scalar attributes" in a non-default context
(This is essentially what happened with RFC 1493, the bridge MIB, which was
designed for a bridge, when a device implemented a single bridge).  In my
opinion, a non-starter.

Since this thread concerns review of a MIB module, it makes sense to
mention solution (1) above.

For monolithic agents, those that are not designed to be runtime
extensible, accommodating AgentX during MIB design looks like an
unnecessary change.

Regards,

Mark Ellison
Ellison Software Consulting, Inc.

Margaret Wasserman wrote:

> >
> >I guess you two are not well communcating. My understanding is that
> >Bob talks about objects such as ifNumber which are problematic when
> >the counted ifEntry rows exist in different sub-agents. I do not think
> >Bob is talking about scalars in general, which is what Andy seem to
> >have in mind.
>
> I never understood the value of the "fooNumber" variables to begin
> with...
>
> They are complex to maintain for a large, dynamic table (like a
> routing table).
>
> They don't reflect the number of entries that are actually
> visible to the manager, so a manager can't expect to see that
> number of entries in the table.
>
> And, for a large, dynamic table, the number of entries is likely to
> change in the time it takes to do enough get-nexts and/or get-bulks
> to download it.
>
> But, assuming that you believe that they have any use at all...
>
> Why would it be more useful to present them as a table?  And,
> how would you index such a table?
>
> Not just idle speculation -- I'm working on a MIB right now that (for
> historical reasons) will probably continue to have one of these
> irritating little buggers...
>
> Margaret