locks

["Harrington, David" <dbh@enterasys.com>]

Hi Bobby,

I guess part of the answer depends on how long a lock lasts. If somebody
can hold the lock for minutes at a time, or even more than say 10
seconds, that could be enough to trigger flashing red device icons on
SNMP-based topology maps. If an SNMP application can determine that a
lock is set, and that's why a SET operation failed, then the logic can
take that into consideration, and flag the device as "busy doing
<netconf> stuff" rather than "unable to perform this task", and it can
plan to try again later.

When a global lock is set, what level of non-netconf access is allowed,
if any? Obviously I cannot SET values to a locked config, but can I read
the values, even though they may be in the middle of being changed? 

Is a locked netconf operation atomic, with as-if-simultaneous
application of functionality at commit or at copy-config?

If I'm executing a large script, say on bootup, and it is important that
all aspects of the device be configured before starting operation, can a
lock span the whole script, or must you turn the lock on and off for
each individual operation? The netconf protocol only says locks are
intended to be short-lived; it does not specify what short-lived is, and
it doesn't say MUST. If a script is running, and locks are truly
short-lived within a script, can I do an SNMP SET to the same
configuration target that the script is in the middle of configuring? So
doesn't this argue that locks need to live as long as is required to
complete the script, whether that is short- or long-lived? 

If the locks will impact other protocols, then netconf needs to be more
specific about the scope/length of a lock, including expectations about
the behavior of other protocols that share the lock. This is also true
since other protocols can presumably set the locks, possibly remotely
via a mib or other mechanism, and netconf needs to protoect itself from
poorly applied locks. Doesn't this then call for the ability to
monitor/examine the lock-state by any of the impacted protocols to
improve cross-protocol coordination? 

If a netconf script gets into an infinite loop (and we all know that
sooner or later this might happen), how will an operator <kill-session>?
Shouldn't they have access to the global lock via, say, the CLI?

Therefore I assume this is not just an internal instrumentation issue,
but should be externally visible/accessible to all impacted protocols.

dbh

> -----Original Message-----
> From: Bobby Krupczak [mailto:rdk@krupczak.org] 
> Sent: Tuesday, May 04, 2004 12:42 AM
> To: Harrington, David
> Cc: Andy Bierman; j.schoenwaelder@iu-bremen.de; netconf@ops.ietf.org
> Subject: Re: unified transaction model proposal
> 
> Hi1
> 
> > global. 
> > 
> > I think it will be imperative to be able to manipulate different
> > portions of the configuration simultaneously, so globally 
> locking global
> > configurations, like running, are a problem. We discussed 
> this at the
> > interim and it has been raised multiple times on the mailing list. I
> > believe we will need partial configuration support, with locks to
> > support that.
> 
> I thought David's questions on cross-management-platform locks to be
> right on the money.
> 
> However, in my own dealing with this issue, I always assumed this was
> an internal matter and that SNMP agents, operating systems (e.g. IOS),
> and netconf agents, would do this behind the scenes rather than making
> this locking mechanism externally visible.  Is this not the case?
> 
> Bobby
> 

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