Subject: [Netconf] Partial-lock issues

From: Balazs Lengyel <[email-masked]>
Date: Tue, 19 May 2009 12:01:53 +0200

Hello,
Some people brought it up that partial-locking without partial commit is not a good solution as
it can lead to dead-locks. For one last time I try to list the reasons why we included candidate.

Please state if you can accept the reasoning below or whether you think we should allow
partial-locking ONLY for the running configuration?

1) As Washam pointed out just by having access control and without using any locks we face a
dead-lock problems:
- A only has access to /foo, and edits it in candidate
- B only has access to /bar, and edits it in candidate
- A terminates it's session
- Now B can not issue <discard-changes> because it can not modify /foo in the candidate
- B can not issue <commit> because it can not modify /foo in the running
If A and/or B uses partial-locking that will NOT make this situation WORSE, as the lock is
automatically released at the end of the session. The real problem is caused by access control.

2) When partial-locking is used correctly, there is no danger of dead-lock, and locking does
help to protect the individual operator's activities. (In the next sequence we presume access
control will not block any of the actions.)

- Operator A locks everything it needs both in candidate and running in one operation e.g. /foo
- A edits the locked part in the candidate
- A issues commit, if this fails due to lock conflicts, it simply releases the lock, and let's
any concurrent operator (e.g. B) work on candidate; B will later commit changes done by A as
well. Lock conflicts can include operator B locking /bar in the running configuration
- Operator B works the same way on another area e.g. /bar
- The operator that finishes editing last will successfully commit all changes to running (by
this time there are no other locks)

3) Later we might introduce partial commit, in which case partial-locking would be very much
needed/useful

4) Partial-locking does no evil

5) It is nice to have the feature available on all three datastores

So we propose to keep partial-locking on candidate, but as this is only secondary use-case if
the workgroup decides it can be removed.

This question has already been raised a number of times, so we would like to establish the
workgroup
consensus and follow it. PLEASE INDICATE WHETHER PARTIAL-LOCKING ON CANDIDATE SHOULD STAY OR
SHOULD BE REMOVED !!!!

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 19 May 2009 10:47:41 -0700

Hi -

> From: "Balazs Lengyel" <[email-masked]>
> To: "netconf mailing list" <[email-masked]>
> Sent: Tuesday, May 19, 2009 3:01 AM
> Subject: [Netconf] Partial-lock issues
...
> automatically released at the end of the session. The real problem is caused by access control.
...

This reasoning makes an unwarranted assumption about how access control works.
Specifically, it assumes that the access control policy is evaluated at the time of
the <commit>, rather than simply being applied to each individual edit.   Buried
underneath this is the question of what happens when there is a change to the
access control policy between the edit and the <commit>.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 May 2009 20:47:37 +0200 (CEST)

"Randy Presuhn" <[email-masked]> wrote:
> > - Now B can not issue <discard-changes> because it can not modify /foo in the
> > - candidate
> the <commit>, rather than simply being applied to each individual
> edit.

No, I don't think the example makes that assumption.  The only
assumption it makes is that the access control policy is *at least*
evaluated as part of commit.  This is a use case that is explicitly
mentioned in RFC 4741, section 9:

   For
   example, if a user A is not allowed to configure an IP address on an
   interface but user B has configured an IP address on an interface in
   the <candidate> configuration, user A must not be allowed to commit
   the <candidate> configuration.

/martin

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 19 May 2009 20:51:31 +0200

Thanks Balazs for summarizing.

I believe I (as a technical contributer) can accept your reasoning.

Speaking as document shepherd and WG co-chair I would like to
urge all WG members to state their opinion (or comments) as well.

Bert
  ----- Original Message ----- 
  From: Balazs Lengyel 
  To: netconf mailing list 
  Sent: Tuesday, May 19, 2009 12:01 PM
  Subject: [Netconf] Partial-lock issues

  Hello,

  Balazs

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

------------------------------------------------------------------------------

  No virus found in this incoming message.
  Checked by AVG - www.avg.com 
  Version: 8.5.336 / Virus Database: 270.12.34/2122 - Release Date: 05/19/09 06:21:00

---

From: WashamFan <[email-masked]>
Date: Wed, 20 May 2009 09:54:05 +0800

Hi,

According to current relevant text, the only safe way to use
candidate is one-session-at-a-time as Andy said before. I.e.,
global lock is recommended to be used for candidate edits.
Yes, the partial lock does not make the situation worse, but
it encourages multiple-session-at-a-time on candidate, which
leads to difficult recovery. 

So, I just suggest this use case removed.

washam

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 May 2009 08:52:38 -0400

Hi,

I apparently had a different expectation about candidate configs.
I assumed that each candidate would contain only the partially locked
data, and that the candidate was basically globally locked.

I think each candidate should be globally locked to a single editor.
You should not have multiple editors simultaneously editing different
portions of the same candidate. 
I don't have an issue with having multiple candidates, each of which
can lock a different portion of the configuration (no overlapping
partial locks). When an editor commits their candidate instance, only
changes that occur within their partially locked data get committed.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of WashamFan
> Sent: Tuesday, May 19, 2009 9:54 PM
> To: Balazs Lengyel
> Cc: netconf mailing list
> Subject: Re: [Netconf] Partial-lock issues
> 
> Hi,
> 
> >  Some people brought it up that partial-locking without 
> partial commit 
> > is not a good solution as
> >  Please state if you can accept the reasoning below or whether you

> > think we should allow
> >  1) As Washam pointed out just by having access control and
without 
> > using any locks we face a
> >  dead-lock problems:
> >  - Now B can not issue <discard-changes> because it can not modify

> > /foo in the candidate
> >  If A and/or B uses partial-locking that will NOT make this 
> situation 
> > WORSE, as the lock is
> >  automatically released at the end of the session. The real 
> problem is 
> > caused by access control.
> >  
> >  help to protect the individual operator's activities. (In the
next 
> > sequence we presume access
> >  - Operator A locks everything it needs both in candidate 
> and running 
> > in one operation e.g. /foo
> >  - A issues commit, if this fails due to lock conflicts, it simply

> > releases the lock, and let's
> >  - The operator that finishes editing last will successfully
commit 
> > all changes to running (by
> >  So we propose to keep partial-locking on candidate, but as this
is 
> > only secondary use-case if
> >  This question has already been raised a number of times, 
> so we would 
> > like to establish the
> >  workgroup
> >  consensus and follow it. PLEASE INDICATE WHETHER 
> PARTIAL-LOCKING ON 
> > CANDIDATE SHOULD STAY OR
> >  SHOULD BE REMOVED !!!!
> >  
> >  Balazs
> >  
> >  
> >  --

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2009 08:18:58 -0700

> portions of the same candidate. 

There is only one global candidate config database, as defined
in RFC 4741.

> changes that occur within their partially locked data get committed.

I have an issue with multiple candidate databases:
It is not supported at all by the NETCONF standard.

I think the monitoring draft is the wrong place
to quasi-define NETCONF database architecture.
The monitoring draft is the wrong place to introduce
multi-protocol access for NETCONF databases.

Just throwing non-NETCONF sessions in with the
other sessions leads to all kinds of assumptions,
like kill-session() for non-NETCONF sessions.
The manager is likely to stuff in the session-id
returned from the lock-denied error, so this is an
important issue.  It is a slippery slope.

> dbh

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 May 2009 17:49:11 +0200

HelloDavid ,
I don't think anyone is currently proposing multiple candidates.

Please reply to my previous mail from May the 19th where I tried to summarize the partial-lock 
versus candidate configuration issue.

regards
	Balazs