[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RowStatus versus RowState
> > Lauren> One big question is do we use existing PDUs and data structures
> > Lauren> to their best effect, or do we define new ones? What
> > Lauren> considerations
> > Lauren> compell us to define new ones (i.e. efficiency? elegance?). Is
> > Lauren> it worth the pain to define new ones, and what pains would we
> > Lauren> experience?
> > Lauren>
> > Lauren> For example, I surmise that the current draft does not obsolete
> > Lauren> existing
> > Lauren> utility functions, though adding a new varbind aggregate type
> > Lauren> might do that. It's unclear whether new aggregate structures or
> > Lauren> PDUs result in more efficent PDUs than the current draft.
> > What sort of "utility functions" are you concerned about in regards
> > to using an aggregate row type object? Would these utilities not also
> > be affected by the use of the createRow and deleteRow PDUs?
> The key word above was "surmise". :-) You can probably better answer
> this question regarding the aggregate struct you have proposed.
> Existing impls have libraries of util functions that are coded
> around the current varbind struct. Depending on how these libraries
> are designed, I'm just wondering if adding a new varbind type
> would expose some possible risk that SOME impls may have to recode
> these library utilities??? For example, maybe (or maybe not) something
> like the following would have to be recoded to support the new
> aggregate type:
> size = SizeOfVarbind(varbind1);
> The current draft uses existing structs, types, PDUs, etc, so it
> seems to me most of the low-level utils work as-is.
Most of the utilities could remain the same. The ones that would
need to be changed would be ones that examine VarBind structures as these
would need to be updated to "understand" aggregate row object syntax.
The benefit of this, of course, would be to allow implementations to
operate on entire conceptual rows as an atomic unit. It seems to me that
for all the work that must currently be done to try to manage conceptual
rows, that if utilities were modified to be capable of supporting
aggregate row objects that this would only simplify row-based management
implementations. The work on the front end to modify the utilities would
pay off in making implementations that use these utilities much simpler.
> > > > > 18a. New AgentX PDU-types MUST NOT be needed
> > > > > to support RowOps, though existing ones MAY
> > > > > be tweaked.
> > > > >
> > > > > 18b To take full advantage of the new simplified row operations
> > > > > made possible by this work, additional master agent/subagent
> > > > > communication PDUs MAY be required.
> > > >
> > > Mike> No tweaking. AgentX is moving for standardization, and
> > > Mike> if we can
> > > Mike> meet #3, then no tweaking is needed.
> > >
> > Lauren> Current draft would break current AgentX if an impl were required
> > Lauren> to implement CreateRow, DeleteRow or GetBulkRow (but maybe not
> > Lauren> EditRow, GetRow, GetNextRow).
> > If we want to implement the really useful features of the RowOps draft
> > like CreateRow, DeleteRow, and GetBulkRow, then AgentX is going to
> > be broken. But, how much would having just an EditRow, GetRow, or
> > GetNextRow operation really buy us if this doesn't get translated
> > down to the method routines so that we can save compatibility with AgentX?
> > The increased efficiency on the wire seems like the only real gain that
> > we would achieve from these operations. But, I didn't think that was the
> > only intention, nor even the main goal, for the RowOps draft.
> It seems that EOS-capable networks will require a major
> paradigm shift from current SNMP networks. It is not going
> to be a painless transition from old to new. All I'm saying
> is that existing devices and instrumentation can at least make use
> of a subset of the EOS operations (as per current draft) by simply
> replacing their master agents (but keeping old subagent protocols)
> and/or proxy agents. Tis just a baby step towards a full EOS network,
> but possibly a valuable one for environments trying to migrate towards
> full EOS compatibility??? Even if these existing impls choose
> not to adopt all EOS rowOps, using GetRow, GetNextRow and EditRow
> would make things a bit more efficient on-the-wire, and why would
> anyone disregard such a benefit if all they had to do was install a
> new master agent provided by their SNMP vendor?
I'm not sure that using a new GetRow, GetNextRow, or EditRow
operation would provide much more efficiency than simply using
OID compression, as this is really the main gain that is provided
by these operations if the changes are not going to be carried
down to the subagents. I'm not sure that it would necessarily
make sense to define new PDUs if all that these PDUs provided
you with was a different way to compress or minimize the OIDs.
It seems to me that if we're going to define new row-based operations
that make operating on rows simpler and more efficient, then we should do
exactly that. If we are only concerned about efficiency, then I think
OID compression already provides this.
> Ideally we'd like to be able to translate ALL EOS operations within
> a proxy agent or a master agent so that old instrumentation never has
> to change even while new instrumentation can take full benefit of
> EOS features. However, I don't think that's easily done (if we define
> create/delete/GetBulkRow proto-ops).
I agree. If we really want to make row-based operations simpler then
I don't see how we can take advantage of the really useful row-based
operations without requiring changes to the Master Agent to subagent
protocols. As you said above, implementing the EOS features won't
be painless. But, IMHO if it's going to be really worthwhile, then
it's going to need to provide more than just on-the-wire efficiency.