[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: [802.1] MSTP MIB - mstpMapTable
On Thu, Sep 08, 2005 at 06:23:08AM -0700, Keith McCloghrie wrote:
> > > What you say is true for atomic data, but in this particular case, the
> > > data is an array of 4096 separate pieces of information. In other
> > > words, this is not a case of "splitting the value into smaller pieces",
> > > but rather it's a case of combining many values into a small number
> > > of medium-sized aggegates instead of into a single large aggregate.
> >
> > The issue is whether you need atomic access to data and the
> > implications of a lack of atomic access build into a MIB module. I
> > don't care whether the data you need to access is stored under a
> > single OID or a collection of OIDs and this is why I am saying that
> > looking at the size of a single object likely misses the point when it
> > comes down to semantically meaningful management operations.
>
> Your issue seems to be concerned with the size of the PDU (rather
> than of the object), i.e., you seem to be saying that bigger PDUs are
> needed. In fact, if you're saying that the size of the PDU needs to be
> large enough to contain all the data the application wants to obtain
> atomically, then that's impractical: a) the "all the data" could be
> Gigabytes, and b) a device would have to disable interrupts while
> constructing the PDU in order to guarantee atomicity.
Keith,
I think you are exaggerating a bit here. I just want to avoid more
CLRs which then may be applied blindly, leading to bigger objects
split into pieces and then put together into a notification or having
semantics which require to set them together or forcing managers to
use dribble mode procedures with rather complex rollback and cleanup
procedures on the manager (which are difficult to test and likely not
work when they are needed).
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany