[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RowStatus versus RowState



Sandra McLeod wrote:
> > > 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.

In the current draft, Get/GetNext/EditRow also provide
three-phase SETs and extended errors.  These features
allow for fewer protocol exchanges.  So I think these are
far superior to conventional proto-ops.  Unfortunately,
existing impls won't make use of these features, only
the efficiency aspect.  If it's not worthwhile to point-out
that existing impls could make use of these proto-ops,
perhaps as a first step in a full EOS transition, then I wouldn't
mind dropping that from the draft.

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

I fully agree!

Lauren

>                 Sincerely,
> 
>                   Sandra