Re: snmpconf PM MIB Issue #9 (fwd)

[Jon Saperia <saperia@jdscons.com>]

Matt,

I am responding to this list since this is the more appropriate place to
have the discussion. I have described my suggestions in a couple of
places but I will collect them here as 'jon's requirements list'. I
agree with your concern about large transactions, but that is different
than being able to 'scope' the range of commit actions. Clearly a large
transaction is more likely (thought it is not a perfect correlation) to
take longer.  Here are the things we need. Semantics and MIB objects to:

     1. Specify when the transaction is to take place:
                A. Immediately
                B. On Reboot
                C. Some other specified time or event.

     2. Collect uncommitted transactions over PDU's and long periods of
        time. This implies a clean up mechanism.

     3. A commit everything button.

     4. Facilities for 'scoping' the range of commits. How I have done
        this in private MIB Modules is with special objects. For example
        commit all transactions of this type.

     5. A set of conventions for sending INFORMs when the transaction is
        complete. (This is one of your concerns)

     6. Other 'state' objects to let the user know if the transaction is
        really complete. We need to expose two things: first, did the
        'order ' get placed (successful set), second has the order been
        filled. This could take time (a very long time - even by human
        standards) to complete.

I would recommend that people look at the SNMPCONF BCP which has quite a
lot written on this subject.

/jon

------- Forwarded Message

Date:    Fri, 22 Jun 2001 11:38:07 -0400
From:    Matt White <mwhite@torrentnet.com>
To:      snmpconf@snmp.com
Subject: Re: snmpconf PM MIB Issue #9

One thing to keep in mind here is that configuration for next generation 
devices can become quite large.  It is quite likely that configuration 
cannot be written prior to SNMP timeout.  If I take the UCD tools as my 
model, the SET request will be sent again, thus causing more work.

I'm not saying that you can't have a "write this now" button, just that you 
need to do something a little bit smarter than a single MIB object.


- -Matt


- --On Wednesday, June 20, 2001 10:51 AM +0200 Juergen Schoenwaelder 
<schoenw@ibr.cs.tu-bs.de> wrote:

>
>>>>>> Wes Hardaker writes:
>
> Wes> I'm not convinced that forcing this upon the implementer is a
> Wes> "good thing".  It's entirely possible that some implementations
> Wes> will only be able to write immediately, and others will not be
> Wes> able to write until some time X later.
>
> Which means that management applications can never know whether a
> configuration change has been committed to stable storage. From a
> management application perspective, this is unworkable. (And all the
> CLIs I have seen sofar have a "write config now" button. So why is
> that too hard to put into an SNMP agent?)
>
> Wes> I fail to see what the problem is with the existing storage type
> Wes> mechanisms.  If one box must write everything nonVolatile at once
> Wes> and another one may not, then it is sort of implementation
> Wes> specific as to what saving methodology is used.
>
> The problem is that management applications have no clue when a
> configuration change is reflected in stable storage and hence they
> can't seriously make any assumptions that a row which is "nonVolatile"
> is still there after a device reboot/crash. I know one implementation
> which writes to stable storage when the agent exits (which won't work
> if the agent or the system crashes). I know other implementations
> which delay writes to speed up the processing of SNMP set
> operations. Again, there is a time window where changes to
> "nonVolatile" rows might get lost.
>
> The proposal adds explicit write buttons so when a management
> application touches the button, it will be sure that the configuration
> in stable storage is updated. This does not reduce your freedom to not
> implement such a write button and to continue with the old behaviour
> where things are written to stable storage whenever the implementor
> things it is a good time to do so.
>
> In fact, the write buttons would be an _additional_ explicit mechanism
> to help management applications that want to know when configuration
> changes are saved in stable storage.
>
> /js
>
> --
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
>






------- End of Forwarded Message