[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Help/guidance on L2TPv3 MIB draft
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.
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.
Thanks,
Bert
> -----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
> >
>