Re: Help/guidance on L2TPv3 MIB draft

[Andy Bierman <abierman@cisco.com>]

At 01:55 PM 9/30/2002 -0400, Mark Ellison wrote:
>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.

Here is one more design approach:

(4) Allow for sub-agent to sub-agent queries.  E.g., the sub-agent that
    registers for ifNumber sends a request to every other sub-agent for 
    the number of rows in ifEntry owned by that sub-agent.  

Either this or (2) below are acceptable because they don't force 
MIB design changes. 

Andy



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