Subject: [Netconf] The <running> configuration datastore and :writable-running

From: Jonathan Hansford <[email-masked]>
Date: Thu, 08 Aug 2013 15:28:47 +0100

Hi, 

Please can someone clarify for me the situation with regards
the base model, the <running> configuration datastore and the
:writable-running capability? 

RFC 6241 states: "Only the <running>
configuration datastore is present in the base model". Does that imply
the <running> configuration datastore is always present, or that it will
persist once it has been created (since "the <running> configuration
datastore cannot be deleted")? 

With respect to :writable-running:

Section 7.2 identifies <running> as a suitable target for the
edit-config base protocol operation. 

Section 7.3 states: "Even if it
advertises the :writable-running capability, a device MAY choose not to
support the <running> configuration datastore as the <target> parameter
of a <copy-config> operation". 

Section 8.2.1 states: "The
:writable-running capability indicates that the device supports direct
writes to the <running> configuration datastore. In other words, the
device supports <edit-config> and <copy-config> operations where the
<running> configuration is the target". 

Section 8.2.5.1 states: "The
:writable-running capability modifies the <edit-config> operation to
accept the <running> element as a <target>". 

Section 8.2.5.2 states:
"The :writable-running capability modifies the <copy-config> operation
to accept the <running> element as a <target>". 

How does
:writable-running change in any way the edit-config and copy-config
operations for the base model? 

Can a device only supporting the base
model and not supporting :writable-running choose not to support
edit-config on the <running> configuration datastore and return an
error? 

If so, does :writable-running mandate the support of
edit-config on the <running> configuration datastore? 

If not, what
does :writable-running add? 

What does :writable-running add to the
copy-config operation, if a device can choose not to support the
<running> configuration datastore as the <target> when supporting the
:writable-running capability? 

Presumably if a device only supports the
base model and does not support :writable-running, the <running>
configuration datastore is read-only as far as NETCONF is concerned.
Correct? 

Thanks, 

jh

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Aug 2013 07:48:20 -0700

On Thu, Aug 8, 2013 at 7:28 AM, Jonathan Hansford
<[email-masked]> wrote:
> Hi,
>
> Please can someone clarify for me the situation with regards the base model,
> the <running> configuration datastore and the :writable-running capability?
>

All NETCONF devices have a running datastore.
By default, it is read-only.

Writable-running capability means the server allows the running datastore
to be edited directly with <edit-config> or <copy-config>.

Candidate capability means the server allows the candidate datastore
to be edited directly with <edit-config> or <copy-config>.
The candidate is applied to the running datastore (all-or-nothing)
with the <commit> operation.

Capabilities (other than base:1.1) are optional-to-implement.
That is why they are included in the <hello>.  If they were mandatory
to implement they would be covered by the "base:1.1" capability.

Andy

> RFC 6241 states: "Only the <running> configuration datastore is present in
> the base model". Does that imply the <running> configuration datastore is
> always present, or that it will persist once it has been created (since "the
> <running> configuration datastore cannot be deleted")?
>
> Section 7.2 identifies <running> as a suitable target for the edit-config
> base protocol operation.
>
> Section 7.3 states: "Even if it advertises the :writable-running capability,
> a device MAY choose not to support the <running> configuration datastore as
> the <target> parameter of a <copy-config> operation".
>
> Section 8.2.1 states: "The :writable-running capability indicates that the
> device supports direct writes to the <running> configuration datastore. In
> other words, the device supports <edit-config> and <copy-config> operations
> where the <running> configuration is the target".
>
> Section 8.2.5.1 states: "The :writable-running capability modifies the
> <edit-config> operation to accept the <running> element as a <target>".
>
> Section 8.2.5.2 states: "The :writable-running capability modifies the
> <copy-config> operation to accept the <running> element as a <target>".
>
> How does :writable-running change in any way the edit-config and copy-config
> Can a device only supporting the base model and not supporting
> :writable-running choose not to support edit-config on the <running>
> configuration datastore and return an error?
>
> If so, does :writable-running mandate the support of edit-config on the
> <running> configuration datastore?
>
> If not, what does :writable-running add?
>
> What does :writable-running add to the copy-config operation, if a device
> can choose not to support the <running> configuration datastore as the
> <target> when supporting the :writable-running capability?
>
> Presumably if a device only supports the base model and does not support
> :writable-running, the <running> configuration datastore is read-only as far
> as NETCONF is concerned. Correct?
>
> Thanks,
>
> jh
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Jonathan Hansford <[email-masked]>
Date: Thu, 08 Aug 2013 16:06:55 +0100

I don't recall seeing it stated anywhere in RFC 6241 that the
running datastore defaults to read-only. Would it be worth raising an
erratum to clarify that point? 

On 2013-08-08 15:48, Andy Bierman

<[email-masked]> wrote:
> 
>> Hi, Please can someone clarify for
me the situation with regards the base model, the <running>
configuration datastore and the :writable-running capability?
> All
NETCONF devices have a running datastore.
> Capabilities (other
than base:1.1) are optional-to-implement.
> That is why they are
included in the <hello>. If they were mandatory
> to implement they
would be covered by the "base:1.1" capability.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Aug 2013 17:17:40 +0200

> erratum to clarify that point? 

Implementing NETCONF read-only has obviously little value for real
configuration management. 

The reason why we have :writable-running and :candidate is that some
major vendors use very different models when it comes to making
configuration changes and as such you will see implementations that
either announce :writable-running or :candidate or :writable-running
and :candidate together.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Aug 2013 08:37:37 -0700

> configuration management.

Yes, but base:1.1 does not actually require any editing capabilities.
What if a company wanted to use NETCONF for monitoring and/or
notifications?  Then the base:1.1 operation set is simple to implement,
and they do not advertise any optional capabilities, so the client
should figure out what operations are allowed.

> either announce :writable-running or :candidate or :writable-running

:candidate and :writable-running together should be considered deprecated.
This is a degenerate use-case for concurrent transactions.  The WG should
standardize this properly at some point in the future, so clients can use
a predictable standard transaction model.

Andy

---

From: Jonathan Hansford <[email-masked]>
Date: Mon, 12 Aug 2013 11:48:28 +0100

Andy, 

You propose that ":candidate and :writable-running together
should be considered deprecated", yet RFC 6241 (pp.70-71) states: 

...
it is important to recognize that some operations are clearly more
sensitive by nature than others. For instance, <copy-config> to the
startup or running configurations is clearly not a normal provisioning
operation, whereas <edit-config> is. Such global operations MUST
disallow the changing of information that an individual does not have
authorization to perform. For example, if 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.

Presumably, if
:candidate is supported, the approach would be to: 

 	* <lock>
<candidate> and <running>
 	* <copy-config> <running> to <candidate>
 	*
<edit-config> <candidate> within the limits of the user's privileges
 	*
<validate> <candidate> (or use <test-option> set to <test-then-set> in
the previous set, if the change is trivial)
 	* <copy-config>
<candidate> to <running>
 	* <unlock> <candidate> and <running>

But if
the change were a simple change, wouldn't it be better to <edit-config>
<running> with the <test-option> set to <test-then-set>, even if
:candidate is supported? Or are you just proposing that concurrent use
of the :candidate and :writable-running capabilities on <running> should
be deprecated? And if that is the case, wouldn't the use of <lock> be
sufficient? 

Jonathan 

On 2013-08-08 16:37, Andy Bierman wrote: 

> On
Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
<[email-masked]> wrote:
>> On Thu, Aug 08, 2013
at 04:06:55PM +0100, Jonathan Hansford wrote: 
>>> I don't recall
seeing it stated anywhere in RFC 6241 that the running datastore
defaults to read-only. Would it be worth raising an erratum to clarify
that point?
>> Implementing NETCONF read-only has obviously little value
for real configuration management.
> 
> Yes, but base:1.1 does not
actually require any editing capabilities.
>> The reason why we have :writable-running and
:candidate is that some major vendors use very different models when it
comes to making configuration changes and as such you will see
implementations that either announce :writable-running or :candidate or
:writable-running and :candidate together.
> :candidate and
:writable-running together should be considered deprecated.
> This is a
degenerate use-case for concurrent transactions. The WG should
standardize this properly at some point in the future, so clients can
use

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Aug 2013 07:54:17 -0700

Hi,

The operations below are wrong.
<copy-config> (candidate, running) is <commit> instead
<copy-config> (running, candidate) is <discard-changes> instead

The problems occur when running is edited separately from candidate.
I'm not going to spell it out.  Those who have implemented concurrent
transactions understand the issues.

Andy

On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
<[email-masked]> wrote:
> Andy,
>
> You propose that ":candidate and :writable-running together should be
> considered deprecated", yet RFC 6241 (pp.70-71) states:
>
> ... it is important to recognize that some operations are clearly more
> sensitive by nature than others.  For instance, <copy-config> to the startup
> or running configurations is clearly not a normal provisioning operation,
> whereas <edit-config> is.  Such global operations MUST disallow the changing
> of information that an individual does not have authorization to perform.
> For example, if 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.
>
> Presumably, if :candidate is supported, the approach would be to:
>
> <lock> <candidate> and <running>
> <copy-config> <running> to <candidate>
> <validate> <candidate> (or use <test-option> set to <test-then-set> in the
> previous set, if the change is trivial)
> <copy-config> <candidate> to <running>
> <unlock> <candidate> and <running>
>
> But if the change were a simple change, wouldn't it be better to
> <edit-config> <running> with the <test-option> set to <test-then-set>, even
> if :candidate is supported? Or are you just proposing that concurrent use of
> the :candidate and :writable-running capabilities on <running> should be
> deprecated? And if that is the case, wouldn't the use of <lock> be
> sufficient?
>
> Jonathan
>
> I don't recall seeing it stated anywhere in RFC 6241 that the running
> datastore defaults to read-only. Would it be worth raising an erratum to
> clarify that point?
>
> The reason why we have :writable-running and :candidate is that some major
> vendors use very different models when it comes to making configuration
> changes and as such you will see implementations that either announce
> :writable-running or :candidate or :writable-running and :candidate
> together.
>

---

From: Jonathan Hansford <[email-masked]>
Date: Mon, 12 Aug 2013 15:59:20 +0100

Hi,

Thanks for the corrections. So you're saying that if you use :candidate 
on a device you should not also use :writable-running.

Jonathan

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Aug 2013 08:13:09 -0700

Hi,

You can lock everything and still NETCONF does not handle it correctly:

start with /a = 5 in both candidate and running
lock(candidate)
lock(running)
edit-config(candidate, /a = 10)
edit-config(running, /b = 3)
commit
unlock(running)
unlock(candidate)

The commit deletes /b and sets /a back to its original value (5).
Editing running and also candidate does not work well in NETCONF.
NETCONF only works well if one target datastore is used.

Andy

On Mon, Aug 12, 2013 at 7:59 AM, Jonathan Hansford
<[email-masked]> wrote:
> Hi,
>
> Thanks for the corrections. So you're saying that if you use :candidate on a
> device you should not also use :writable-running.
>
> Jonathan
>
>>> startup
>>> major

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Aug 2013 08:14:43 -0700

> edit-config(candidate, /a = 10)
                   ^^^^^^^^^ should be running

---

From: Jonathan Hansford <[email-masked]>
Date: Mon, 12 Aug 2013 16:18:59 +0100

Thanks for that clarification. One other question: RFC 6241 implies the 
startup configuration is generated from running using copy-config. Is 
there any reason why the source couldn't be candidate?

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Aug 2013 08:41:07 -0700

On Mon, Aug 12, 2013 at 8:18 AM, Jonathan Hansford
<[email-masked]> wrote:
> startup configuration is generated from running using copy-config. Is there
> any reason why the source couldn't be candidate?
>

We actually support most of the optional variants of copy-config,
so candidate <--> startup is allowed.

  copy-config(startup, candidate)
  commit

This is the only way to rollback to the startup config if :candidate
and :startup are both used.

Andy

>>> on a
>>>>> if :candidate is supported? Or are you just proposing that concurrent
>>>>> use
>>>>> of

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Aug 2013 17:53:09 +0200

On Mon, Aug 12, 2013 at 08:13:09AM -0700, Andy Bierman wrote:
> edit-config(running, /a = 10)

[fixed the example]

I think it is well defined what happens. What is your definition of
'correct' in this case?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Aug 2013 09:05:40 -0700

> I think it is well defined what happens. What is your definition of

Concurrent transactions need to work like source code control systems.
The server must perform a conceptual "update" on the candidate
to discover edit collisions.  In this example, the server knows
the candidate is not changing anything during the commit.

    [discard-changes; running == candidate at start]
    edit-config(running, /a = 10)
    edit-config(running, /b = 3)
    edit-config(candidate, /a = 42)
    commit

In this example, the conceptual update fails because /a
was changed in both running and the candidate.
The commit fails because /a cannot be set to 42.
The candidate started with /a = 5 but /a = 10
at the time of the commit.

To get out of this state, the operator or application
needs to fix the collision, just like with source code control.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Aug 2013 18:17:00 +0200

> the candidate is not changing anything during the commit.

Well, this is clearly not what NETCONF does today.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Aug 2013 10:29:18 -0700

> Well, this is clearly not what NETCONF does today.

Clearly not.  I didn't say this is how NETCONF works.
One would need to start throwing out operations
to make concurrent transactions work properly.
Global locks and explicit partial locks on data nodes
in the running datastore are not needed if concurrent
transactions are implemented correctly.

Andy

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 20 Aug 2013 17:17:23 +0100

Having read RFC 6241 again (specifically, "a lock MUST NOT be granted if 
... the target configuration is <candidate>, it has already been 
modified, and these changes have not been committed or rolled back"), am 
I correct in assuming the first two lines should be reversed which, when 
combined with Andy's correction below, would give:

<discard-changes>

---

From: Jonathan Hansford <[email-masked]>
Date: Tue, 20 Aug 2013 17:28:26 +0100

In fact, thinking about it, it would make more sense to:

<lock> <running>
<discard-changes>
<lock><candidate>

to ensure no changes were made to <running> after discarding changes.

On 20/08/2013 17:17, Jonathan Hansford wrote:
> Having read RFC 6241 again (specifically, "a lock MUST NOT be granted 
> if ... the target configuration is <candidate>, it has already been 
> modified, and these changes have not been committed or rolled back"), 
> am I correct in assuming the first two lines should be reversed which, 
> when combined with Andy's correction below, would give:
>
> <discard-changes>