[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Help/guidance on L2TPv3 MIB draft
At 11:33 AM 10/1/2002 +0200, Wijnen, Bert (Bert) wrote:
>W.r.t. a MIB that should be able to be instantiated multiple
>times at one agent, I thought that we have a contextName for
>that. That is each instance lives within it's own contextName.
agreed
>For some MIBs, pieces are instantiated in one subagent,
>while other pieces are instantiated in another subagent.
>That is where the agentX discussion might come in.
>The ifTable with ifNumber is a specific example of that
>I think.
It sounds like a deficiency in AgentX. The problem is not
limited to scalars. Consider the ifStackTable. How does
an AgentX implementation populate this table if the 'lower'
interface is in 1 sub-agent and the 'upper' interface is in
another?
>Thanks,
>Bert
Andy
>> -----Original Message-----
>> From: Natale, Robert C (Bob) [mailto:bnatale@lucent.com]
>> Sent: dinsdag 1 oktober 2002 3:23
>> To: mibs@ops.ietf.org
>> Subject: RE: Help/guidance on L2TPv3 MIB draft
>>
>>
>> Ha! That's what I love/hate about getting into discussions of
>> fundamental concepts on SNMP lists: Before you know it, you're
>> into "criminal hacks". Amazing.
>>
>> Let me drop back to "thinking about MIBs 101": The cases
>> in which a MIB *should* be designed from the perspective of
>> being instantiated by only a single agent entity on a managed
>> system (host:port) are a few special cases. In the general
>> case, a MIB should *always* be designed from the perspective
>> of multiple instances being supported concurrently, by multiple
>> independent agent entities, on a managed system. When you think
>> this through, you will come to the realization that it is
>> nearly axiomatic wrt design principles. Extrapolating from
>> that axiom leads you to the realization that scalar objects
>> are as out-of-place in MIBs as non-normalized constructs are in
>> a relational database schema. Avoiding the problem is trivial,
>> both in terms of identifying a logical approach and in terms
>> of implementation effort and runtime overhead.
>>
>> The one thing Dave said below that I can agree with is that
>> this is not an AgentX issue (and hence I suggest that any
>> further follow up should go only to the mibs@ops.ietf.org list
>> ...I've bcc'd the AgentX list to give everyone a chance to join
>> the mibs list). AgentX provides the standardized extensible SNMP
>> agent framework that makes best use of multiply instantiable MIBs,
>> but readily supports the (degenerate) case of a MIB designed for
>> single instance use only (RFC2741, Sec. 4.2.1), as well as a range
>> of applications that span both models.
>>
>> To sum it up, my basic assertion is: MIBs designed to be
>> multiply instantiable are better designed MIBs in the general
>> case than MIBs that are designed to be singly instantiable.
>> That they also enable maximum benefit from AgentX is a freebie
>> by-product of their design. However, there may be some special
>> cases where singly instantiable MIBs are not inappropriate.
>> Nonetheless, it is also axiomatic that a multiply instantiable
>> MIB can inherently support single instance configurations, while
>> the converse, in the general case, does not hold.
>>
>> I can't wait to see what the level after "criminal hack" is! :-)
>>
>> Cheers (sincerely...this is not a matter of life and death
>> for me),
>>
>> BobN
>> - - - - -
>> > -----Original Message-----
>> > From: David T. Perkins [mailto:dperkins@dsperkins.com]
>> > Sent: Monday, September 30, 2002 6:05 PM
>> > To: Mark Ellison; Andy Bierman
>> > Cc: Margaret Wasserman; Juergen Schoenwaelder; bnatale@lucent.com;
>> > mibs@ops.ietf.org; agentx@dorothy.bmc.com
>> > Subject: Re: Help/guidance on L2TPv3 MIB draft
>> >
>> >
>> > HI,
>> >
>> > I suggest that this is really a system problem, and not an agentX
>> > or SNMP problem. Its a system problem because a well
>> designed system
>> > that supports management should not require an agentX hack to add
>> > support for another interface. So if I was the first developer to
>> > add support for a new interface and there was not an system
>> interface
>> > to add in the support for management, I would add one to an open
>> > source OS, and for closed source OSs, then I would work with the
>> > vendor. Only after ALL other available options were exhausted would
>> > I add an agentX hack.
>> >
>> > Why do I call it a hack? It is because ideally all management
>> > information
>> > should be available via all management interfaces to a
>> > system. That is,
>> > there should be system calls to present info on a CLI, present via
>> > a WEB server, and SNMP agent. As soon as you do a "quick and dirty"
>> > job to circumvent the OS, then you find you need to provide it for
>> > other management interfaces. The result being extra cost and lower
>> > integrity than if the wholistic approach is taken. Note that there
>> > are some vendors (such as MicroSoft) that make things difficult. But
>> > for all others it is criminal to go the hack approach.
>> >
>> >
>> > At 04:24 PM 9/30/2002 -0400, Mark Ellison wrote:
>> > >Hi Andy,
>> > >
>> > >Allowing for subagent to subagent queries would be
>> > predicated upon having
>> > >sufficient security in place. Support for the SNMPv3
>> > security has been proposed
>> > >as work items (see the "security credentials" and
>> > "isAccessAllowed()" threads
>> > >on the agentx-email list).
>> > >
>> > >Until there is an update to the AgentX protocol, this sort
>> > of orchestration must
>> > >occur "out of scope" or "out of band" to a standards
>> > compliant snmp agent.
>> > >
>> > >I would suspect the subagent knowing about certain scalars
>> > would likely be part
>> > >of the same daemon or process as that responsible for
>> > spawning instance daemons,
>> > >so would probably already contain the instrumentation, or
>> > access to it the local
>> > >instrumentation's of the scalar without additional demands
>> > on the snmp agent. I
>> > >think this true for both monolithic and run time extensible agents.
>> > >
>> > >If the eos and sming working groups create changes to the
>> > operations and the
>> > >underlying PDU structure, then there is a definite need to
>> > make changes to
>> > >AgentX to support these new features (One option would be
>> > to convert everything
>> > >per `on the wire' for compatibility with the current set of
>> > AgentX PDUs, but
>> > >this would be extremely inefficient). So I think there'll
>> > be ample time to
>> > >discuss subagent to subagent requests as well.
>> > >
>> > >In the meantime, pointing out issues to MIB designers is
>> > still a very good tool.
>> > >
>> > >Regards,
>> > >
>> > >Mark
>> > >
>> > >
>> > >Andy Bierman wrote:
>> > >
>> > >> [deletions]
>> > >>
>> > >> 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
>> > >>
>> > >
>> > >[deletions]
>> > Regards,
>> > /david t. perkins
>> >
>>