Re: locks

[Andy Bierman <abierman@cisco.com>]

At 09:03 AM 5/4/2004, Harrington, David wrote:
>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.

It could be the CLI holding the lock, not netconf.
I don't think the duration of the lock is the important
point.  This just increases the probability of a race
condition occurring.


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

The lock is for operations that write the database
(edit, copy, delete).  Read access is not affected.

If netconf is implemented correctly, then SNMP writes will
fail while the lock is held by a different entity.
Other writes will fail while the SNMP engine is processing
a Set transaction.


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

nope -- netconf operations are serialized.  There are no
atomic operations at all.


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

The client decided how long the transaction will take.
Short vs. not-so-short lock duration does not remove
the race condition.  SNMP (and CLI, etc.) agent code
needs to be modified to utilize the configuration lock.
A conformant implementation cannot ignore the locks
because they're supposed to be short.


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

No, netconf doesn't have to specify the duration of the lock.
Repeat again: The transaction is started and finished by the
application, not the agent.


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

Start another netconf session, read the netconf-state objects,
figure out which session holds the lock, invoke kill-session
on that session number.

There are no CLI commands specified by the netconf standard. 


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

Any changes to SNMP which may be desirable to
improve SNMP error codes (or whatever) should be
done by a different WG. 


>dbh

Andy



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