Subject: [Netconf] Real Time Gap Improvements to the target configuration locking mechanism

From: Carl Sherratt <[email-masked]>
Date: Wed, 4 Mar 2009 19:49:54 +0000

Hi,

I would like to suggest some improvements in the way configuration
locks are currently handled by the netconf standard and that in draft,
If we could possibly discuss either the problems/merits of the current
target configuration locking mechanism and also potential
problems/merits of my suggestion. Hopefully the outcome will be an
improved locking mechanism which we can add to the working draft.

At present, if a NETCONF Session holder (in a multi-session
environment) wants to edit a configuration the following happens in an
ok scenario :-

1) session holder requests to obtain a lock
2) ok is sent back confirming they have the lock, but for how long?
3) get-config whilst they have the lock to ensure it hasn't been
altered by another session
4) rpc-reply containing the configuration
5) edit the configuration
6) edit-config either merges, replaces or creates or deletes the
locked uncommited  configuration.
7) ok is sent back confirming the edit
8) session holder commits to make the changes apply to the device
9) ok is send back confirming the commitment

What I have noticed is a lot of real-time gaps in a process which I
believe should contain minimal gaps in order to prevent error.

A) My first suggestion is to embed the <lock> request in a
<get-config> request. This removes a real-time gap and ensures the
session holder isn't spending valuable lock time on sending another
request.  The request would look something like this :-

<get-config>
      <!--  embedded lock >  -->
      <lock>
                 <target>
                     <running / >
                  </target>
      </lock>
      <!--- The rest of the get-config request -->
        .....
</get-config>

B) The second suggestion I have is to embed a lock-timeout in the
response, the session holder can use this to re-request the lock if it
needs more edit-time, loosing the lock during a long edit time may be
fustrating to a consoler user.

So The rpc-reply returning the locked configuration would contain the
following :-
<rpc-reply message-id="xxx">
   <lock-timeout>300</lock-timeout>
   <config>
       ......
   </config>
</rpc-reply>

I would also suggest including the <lock-timeout> element in
<rpc-error> messages returned for failed lock requests, in this way
the lock request could use the timeout as a basis for next request,
timeout could be held in the <error-info> section of the <rpc-error>

C) The last suggestion and probably the more questionable one is to
have an embedded commit for edit-configs on candidate targets .

So in this case the session holder owning a lock ( only lock holders
should be able to commit) would pass the new configuration in an
edit-config as follows :-

<edit-config>
      <!-- Embedded commit -->
        <commit>
         <confirmed/>
         <confirm-timeout>120</confirm-timeout>
       </commit>

         <target>
           <candidate/>
         </target>
         <error-option>rollback-on-error</error-option>
         <config>
...
         </config>
</edit-config>

The result is a lot less real time gaps (see numbered steps below)
and thus a much tighter real-time model can be applied if one was
required (in the case of multiple sessions). At present Merge does
take care of unlocked edits but we all know that merge conflicts can
occur when attempting to merge data so these are currently left to
race-conditions which I for one can not allow into my current system.

1) session holder requests  get-config with embedded lock request on
2) rpc-reply containing the configuration and lock-timeout
3) edit the configuration
4) edit-config either merges, replaces or creates or deletes the
locked config (embed commit if candidate)
5) ok is sent back confirming the edit (and commit if candidate)

I hope this will provoke discussion which will lead to improvement of
the standard, the outcome hopefully impacting the current draft.

I look forward to your comments,
Carl.

---

From: WashamFan <[email-masked]>
Date: Thu, 05 Mar 2009 14:51:13 +0800

Hi,

If I understand correctly, you really want to introduce a new mechanism,
which allows for nested rpcs. IMO, it seems to break the layered arch
a little.

Netconf base protocol allows for pipelining handling of a series of rpcs,
see sec 4.5, rfc4741. I don't know if it can mitigate your concern.

Besides, It seems to me that there is no so-called "lock timeout" in
rfcs and drafts. Generally, lock duration is a short period of time, you
mentioned 're-request lock' below, did you mean renew previous lock
or compete with potential other sessions to gain a new lock? The latter
may make the situation worse when losing the competition. And the
former seems to break "lock duration is a short period of time".

Any comments?

washam

>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Carl Sherratt <[email-masked]>
Date: Thu, 5 Mar 2009 09:56:23 +0000

Hi,

> which allows for nested rpcs. IMO, it seems to break the layered arch

I'm questioning how valid it is to have lock at the rpc layer. A
session would only need the lock in order to perform another rpc
operation on the configuration, therefore I see the lock as an
optional element of those rpcs which can alter the contents of a
target configuration.

At present, the current protocol defines a competitive lock mechanism.
There is no "lock timeout" at present and this means the "short period
of time" is undefined. In some cases, where the lock is only needed
for that "short period of time" this works, however, for other cases,
where e.g session A requires the lock for a  longer period of  time,
the lock is lost and the configuration may be  changed by e.g session
B, leaving session A with significant changes on out-of-date
configuration.  This can be resolved with the use of candidate merge,
however, it seems like a lot of processing for a simple operation, if
the lock is renewed then this prevents any need to tidy up conflicts.

> former seems to break "lock duration is a short period of time".

In answer to your question, I am referring to both lock renewal and
lock-request. I agree that providing time-out to all lock requesters
can lead to higher competition although in reality this would just
mean less failed lock-requests (less traffic) because lock-requesters
would only re-request at strategic points in time. A restriction which
I haven't suggested until now is to have a limit on renewals, a limit
may resolve your concerns on a session holding a lock for too long a
period, this should be configurable and shout be a 'longer period of
time' in comparison to the lock-timeout which should be a 'short
period of time', although examples of real time values should be given
otherwise the term short becomes meaningless.

I quote the RFC here in order to focus on the purpose of lock :-

"   The lock operation allows the client to lock the configuration
     system of a device.  Such locks are intended to be short-lived and
     allow a client to make a change without fear of interaction with
     other NETCONF clients, non-NETCONF clients (e.g., SNMP and command
     line interface (CLI) scripts), and human users"

Why short-lived? The short-lived lock ensures that hanging sessions
timeout and thus the lock gets dropped. I don't believe there is any
statement that the period of time-out should not be defined, I see
time-out definition as a useful element of data by both Netconf
Session Server and Client and lock-renewal as something that would
forfill the above quote from the RFC.

Carl

--
Syphan Technologies
True 10G IDS
D +441756631203
M +447932773346
E [email-masked]

-- 
Syphan Technologies
True 10G IDS
D +441756631203
M +447932773346
E [email-masked]

---

From: WashamFan <[email-masked]>
Date: Thu, 05 Mar 2009 20:30:31 +0800

Hi,

Lock is in rpc layer, I am not sure if it will be or not in future. 
But at present, I think
it is a little difficult to convince the members to change it, since I think it
is a major change, and maybe has some compatibility problems with existing
implementation.

Well, I admit we're not told how to measure 'short-lived'. But the reality is, 
lock would not be released unless the owner unlock or session abort, so I 
could lock for a long time as long as I like.

I must admit I am not sure how your problem can impact the protocol.
I expect someone else commenting on this.

washam

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Fri, 6 Mar 2009 22:19:23 +0100

I am OK to have this discussion on the mailing list.
However, as document shepherd for the partial-lock draft I object to the
idea that this discussion and/or its outcome would have an impact on
this draft. We have finished WG Last Call, We have addressed all
comments in a new revision and the doc is ready to go to AD and IESG.

Besides, in order to make sense, the below discussion would apply to
both the base protocol which includes the global lock and to the
partial lock draft. So if we come to consensus that something along the
lines of the proposals below needs to be done, then we need to think
of it in generic terms, and it will impact the base protocol. We need
to figure out how to deal with that ... that is IF we do come to consensus
that something needs to be done/changed.

Bert

  ----- Original Message ----- 
  From: Carl Sherratt 
  To: [email-masked] 
  Sent: Wednesday, March 04, 2009 8:49 PM
  Subject: [Netconf] Real Time Gap Improvements to the target configurationlocking mechanism

  Hi,

  <get-config>
  <!-- embedded lock > -->
  <lock>
  <target>
  <running / >
  </target>
  </lock>

  <edit-config>
  <!-- Embedded commit -->
        <commit>
           <confirmed/>

           <target>
             <candidate/>
           </target>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 06 Mar 2009 14:12:05 -0800

> that something needs to be done/changed.

The 2 step process from the Good Old Days applies here:

   1) Do we think there is a problem to be solved?
   2) If yes on (1), then what solution options to we have?

I will not comment on (2), except that the NETCONF layer violation
is a non-starter.

IMO, there is no real problem to be solved here.
A manager can send <rpc> back-to-back or use partial-lock.

> Bert

Andy

>     *From:* Carl Sherratt <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Sent:* Wednesday, March 04, 2009 8:49 PM
>     *Subject:* [Netconf] Real Time Gap Improvements to the target
>     configurationlocking mechanism
> 
>     Hi,
> 
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>