Subject: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt

From: Kent Watsen <[email-masked]>
Date: Mon, 9 Mar 2009 11:29:35 -0700

All,

I rarely have a chance to look at my NetConf list subscription email,
but today's message from Bert to the IESG Secretary to publish the
partial-lock ID caught my eye

I just read the partial-lock-07 and have a concern with its design -
notably pointed out by section 2.1.1.3 (Multiple managers handling the
candidate datastore in a semi-coordinated work mode) where it says:

   Operators coordinate with each other.  When all of them finish their
   tasks one of them orders commit.  If any of the operators are still
   working, and holds a lock, the commit will fail, and will need to be
   repeated after all managers finish.

To me, this makes the partial-lock on candidate datastores useless - as
no mgt-app will use it over global-lock without a guarantee that its
changes will get committed.  For instance, our apps do this today:

	<lock>
	<edit-config>
	<commit>
	<unlock>

And, to use partial-lock, we'd want to do this:

	<partial-lock>
	<edit-config>
	<partial-commit>  <!-- only commits nodes protected by lock-id
-->
	<partial-unlock>

Did anyone discuss adding a <partial-commit> to compliment this ID?

Thanks,
Kent

--
Kent Watsen
Software Architect
Network Management
Juniper Networks

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 9 Mar 2009 21:43:22 +0100

Ken, I don;t recall that this was ever discussed or brought up.

Bringing up this type of thing seems a bit late in the process.

But nevertheless, I am open to hear other WG participants opinion.

Meanwhile, I think it is best to let the process continue, which means that
- AD will do review
- Document goes to IETF Last Call
- document goes to IESG (if IETF LC does not reveal any fatal flaws).

If we see support of your concerns in the WG, we may consider your comments
as one of the IETF Last Call comments and deal with it that way.

Bert
  ----- Original Message ----- 
  From: Kent Watsen 
  To: [email-masked] 
  Sent: Monday, March 09, 2009 7:29 PM
  Subject: [Netconf] issue with draft-ietf-netconf-partial-lock-07.txt

  All,

  <lock>
  <edit-config>
  <commit>
  <unlock>

  <partial-lock>
  <edit-config>

  Thanks,
  Kent

  --
  Kent Watsen
  Software Architect
  Network Management
  Juniper Networks

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

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 11 Mar 2009 12:05:46 +0100

Hello Bert, Kent,
Yes your concern was voiced in discussions e.g. by Phil Shafer and some others.
As I see the basic problem is that one node needs to be handled by multiple operators. This 
means that each operator should only touch part of the configuration.

For the running configuration this is easy as we have partial lock and (partial) edit-config.

For the candidate this is more difficult as commit is global.

However the working group decided that we do not want to provide partial versions of other 
operations (commit, copy-config, delete-config, validate?). The workgroup decided that partial 
locking as an optional feature is useful without other (new/updated) partial operations, so the 
WG does not want other partial operations as that would be a too big impact.

I agree, partial-locking will be most useful for operators using the writable-running 
capability, but it can be used even for the candidate datastore.

Balazs

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

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Mar 2009 09:36:38 -0700

> As I see the basic problem is that one node needs to be handled by
> multiple operators. 

Yes

> This

Not necessarily - for two reasons: 1) the device's configuration data
model may not be hierarchically structured along "operator" boundaries
and 2) customers may deploy more than one applications/scripts that
having overlapping interest in the config

> For the candidate this is more difficult as commit is global.

Doesn't have to be - and, even if the device serializes the updates
internally, that doesn't have exposed via the NetConf model

> However the working group decided that we do not want to provide
partial
> versions of other
> operations (commit, copy-config, delete-config, validate?). The
workgroup
> decided that partial

Yes, we would need to have "partial-" variants of these other commands
as well

> capability, but it can be used even for the candidate datastore.

Yes, partial-lock can be used on a candidate datastore, but it never
would.  Think about it - apps need to be 100% sure that they don't
commit unattended changes which, without a <partial-commit>, means that
they would have to lock the entire config, which they would do using
NetConf's existing global-lock (not a bunch of partial-locks).  So I
conclude that if partial-lock is ever be used on a candidate datastore,
it must be possible to do a partial-commit

Thanks,
Kent

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 17 Mar 2009 11:19:30 +0100

> having overlapping interest in the config

BALAZS: Yes, the data models/ applications might follow your comments, but exactly these 
situations are the ones that lead to problems like overlapping writes that mess up each others 
stuff. So that is what we try to limit with locking.

> internally, that doesn't have exposed via the NetConf model

BALAZS: Yes and no. You are right it could be done, however the WG decided not to do a partial 
commit.

> it must be possible to do a partial-commit

BALAZS: Not exactly. If all applications lock the objects they are working on both in the 
candidate AND in RUNNING, then an application can not commit unfinished changes, as the other 
application doing those changes is still holding the lock on the running datastore.

Still I fully agree that the partial-lock will be used mostly for the running datastore.

Balazs

---

From: Phil Shafer <[email-masked]>
Date: Tue, 17 Mar 2009 10:51:17 -0400

>Still I fully agree that the partial-lock will be used mostly for the running datastore.

Does/should the draft say this?  Or talk about the dangers of using
partial locks with :candidate?

Thanks,
 Phil

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Mar 2009 11:27:28 -0700

> > commit unintended changes which, without a <partial-commit>, means that

I do not understand - how does your suggestion help an application be sure it's not committing unintended changes?

Also, is it even possible?  I mean, can devices advertize both :candidate and :writable-running?  - aren't those capabilities mutually exclusive?

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Mar 2009 21:40:13 +0100 (CET)

Hi,

Kent Watsen <[email-masked]> wrote:
> Also, is it even possible?  I mean, can devices advertize both :candidate and
> :writable-running?  - aren't those capabilities mutually exclusive?

There's nothing in 4741 that says that they are mutually exclusive.
And I don't think they should be.  Some devices already support this
combination.

A related issue (on our list for 4741bis) is if the combination of
:startup and :candidate is allowed.  And even more interesting, if
:startup, :candidate, and :confirmed-commit is allowed.  More on this
later - we should discuss it in some other thread.

/martin