[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cross-protocol locks
Hi,
Has anybody proposed an SNMP lock-mib that would provide an SNMP
interface to the global locks that NETCONF expects to use?
It seems that if NETCONF locks the complete system, including SNMP, to
prevent other management interfaces from overwriting NETCONF operations,
that the state of the lock should be retrievable via SNMP, and SNMP
should have the capability of setting the lock to prevent other
management interfaces from overwriting SNMP operations. I assume an SNMP
lock-mib could also work as the interface to monitor/manipulate COPS/PR
global locking as well, for those who chose to use it, since COPS/PR
supports SMIv2 and mibs. A similar functionality is needed to coordinate
with other interfaces like the CLI and web server interfaces for mgmt.
I think it is important to define these cross-protocol expectations and
define standard mechanisms and their behaviors for monitoring and
manipulating the underlying objects from the various coordinating
protocols. It would be difficult to define these for protocols that are
still mainly proprietary, such as the CLI and web server interfaces, but
SNMP and NETCONF are both IETF specifications, so the interface between
them should be able to be standardized. Since this WG is defining the
rules about the global locks, then shouldn't this group be writing the
associated mib?
The need for a lock-mib raises a larger question. Other
protocol-developing WGs are expected to provide a MIB for
monitoring/managing the new protocol. Will this WG provide a mib for
monitoring/managing NETCONF?
dbh
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Tuesday, April 27, 2004 2:16 PM
> To: j.schoenwaelder@iu-bremen.de
> Cc: netconf@ops.ietf.org
> Subject: Re: unified transaction model proposal
>
> At 07:45 AM 4/27/2004, Juergen Schoenwaelder wrote:
> >On Fri, Apr 23, 2004 at 01:00:53AM -0700, Andy Bierman wrote:
> >> Here's something new to throw darts at... a proposal for
> >> a unified transaction model (for target == <candidate> or
> <running>)
> >> -------------------------------------------------------------------
> >>
> >> <lock>
> >> <edit-config> + // 1 or more
> >> <commit> OR <discard-changes>
> >> <unlock>
> >>
> >> where:
> >>
> >> commit =
> >> - if #candidate then
> >> attempt commit of <candidate> to <running>
> >> - release any 'rollback' resources the agent was using
> >> for this transaction.
> >> - if #distinct-startup then
> >> copy(running, startup)
> >>
> >> discard-changes =
> >> - if #candidate then
> >> target is <candidate>
> >> else
> >> target is <running>
> >> - remove all changes made to the target by this transaction
> >> since the lock operation completed
> >>
> >>
> --------------------------------------------------------------
> ------------
> >>
> >> IMO, this would greatly simplify the transaction model
> >> and make application development easier. It also makes
> >> network-wide config updates easier on the application.
> >>
> >> The changes to the protocol operations are:
> >>
> >> 1) <commit> is part of base protocol
> >> - confirmed-commit still a #candidate extension
> >> and available if #confirmed-commit present
> >> 2) <discard-changes> is part of the base protocol
> >> - this is essentially a rollback of multiple
> >> edit-config operations, which is needed in
> >> addition to rollback-on-error
> >
> >Perhaps this should then be named "rollback" (or "commit" be changed
> >to "apply-changes" ;-).
>
> I kind of like <commit> and <discard-changes>
>
>
> >> 3) for implementations that have target==<running>,
> >> a rollback capability is mandatory. This is a
> >> big requirement and raises the bar for NETCONF,
> >> but this will make the protocol easier to use
> >> for all application developers.
> >
> >Just for clarification: I assume correctly that commit/rollback
> >only applies to changes created via <edit-config> and not to any
> >other changes (e.g. <copy-config> or <delete-config) that may be
> >made since the lock was established.
>
> Good question. I don't think this is the case though.
> We have global targets (<candidate> and <running>).
> If locking is not used, then the agent cannot
> prevent additional sources from making changes.
> Also, a <discard-changes> applies to the whole database,
> not just the changes from the <edit-config> operations
> from the current session.
>
> We have explicit <lock> and <unlock>. It's up to the
> application to use it correctly. Since this can't
> be guaranteed, my proposal above won't work. What
> if the application didn't use <lock> or did this:
>
> <lock>
>
> <edit-config> + // 1 or more
> <commit> OR <discard-changes>
>
> <edit-config> + // 1 or more
> <commit> OR <discard-changes>
>
> <unlock>
>
> The <lock> can't be used as the start point.
> So instead we have:
>
> <lock>
>
> <start-edit> // no parameters
> <edit-config> + // 1 or more
> <commit> OR <discard-changes>
>
> <start-edit> // error if previous trans. still open
> <edit-config> + // 1 or more
> <commit> OR <discard-changes>
>
> <unlock>
>
>
> >/js
>
> Andy
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>
>
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>