Subject: [Netconf] :candidate vs :writable-running

From: Tomasz Mikolajczyk <[email-masked]>
Date: Fri, 28 Nov 2008 09:35:48 +0100

Hi,

I read at http://www.netconfcentral.com/netconf_docs about candidate
configuration that:

"When ready, the manager can use the <commit>  operation to activate the
changes embodied in the <candidate/> database, and make them part of the
<running/> configuration. This also clears out the <candidate/>
database and leaves it ready for the next use."

Could you point me to a relevant section in RFC 4741 that candidate has
to be cleared after commit?

There is also written that:
"Agent platforms which support the :candidate capability usually do not
also support the :writable-running  capability, since mixing direct
edits to <running/>  would defeat the purpose of using this scratchpad
database to collect and validate changes before applying them."

Let's imagine the following situation. There is a simple device with
configurable interfaces. The interfaces may be added/removed or their
parameters can be changed (ipaddress/port/bandwidth/description etc). At
the moment there is 10000 interfaces configured in the device with ids
0-9999 and an administrator have to delete instance first (id=0) and
last (9999). How it should be performed according to the above
quotations? I see it like this:From [email-masked]  Fri Nov 28 00:37:51 2008
Date: Fri, 28 Nov 2008 09:35:48 +0100
From: Tomasz Mikolajczyk <[email-masked]>
To: NETCONF <[email-masked]>
Subject: [Netconf] :candidate vs :writable-running
Sender: [email-masked]

Hi,

I read at http://www.netconfcentral.com/netconf_docs about candidate
configuration that:

"When ready, the manager can use the <commit>  operation to activate the
changes embodied in the <candidate/> database, and make them part of the
<running/> configuration. This also clears out the <candidate/>
database and leaves it ready for the next use."

Could you point me to a relevant section in RFC 4741 that candidate has
to be cleared after commit?

There is also written that:
"Agent platforms which support the :candidate capability usually do not
also support the :writable-running  capability, since mixing direct
edits to <running/>  would defeat the purpose of using this scratchpad
database to collect and validate changes before applying them."

Let's imagine the following situation. There is a simple device with
configurable interfaces. The interfaces may be added/removed or their
parameters can be changed (ipaddress/port/bandwidth/description etc). At
the moment there is 10000 interfaces configured in the device with ids
0-9999 and an administrator have to delete instance first (id=0) and
last (9999). How it should be performed according to the above
quotations? I see it like this:

 - l

 - lock candidate
 - lock running
 - copy running to candidate (whole 10000 instances!)
 - delete instances 0 and 9999 in the candidate
 - commit (copying the whole 9998 instances)
 - unlock running
 - unlock candidate

Is it true of am I wrong?

Another point is that RFC 4741 says that all the changes in the
candidate configuration have to be committed, otherwise running must
remain unchanged. What if during commit a connection with the device
would be broken, for example somebody cut the cable? How are we going to
tell the device that a kind of rollback have to be done?

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

ock candidate
 - lock running
 - copy running to candidate (whole 10000 instances!)
 - delete instances 0 and 9999 in the candidate
 - commit (copying the whole 9998 instances)
 - unlock running
 - unlock candidate

Is it true of am I wrong?

Another point is that RFC 4741 says that all the changes in the
candidate configuration have to be committed, otherwise running must
remain unchanged. What if during commit a connection with the device
would be broken, for example somebody cut the cable? How are we going to
tell the device that a kind of rollback have to be done?

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Nov 2008 11:03:44 -0800

> to be cleared after commit?

I will fix that text.
I really meant to say that the 'lockability' of the
candidate is reestablished.  As you know, a lock operation
must fail if the candidate has any changes in it at all.

Once a commit or discard-changes is done, the contents
of candidate are conceptually equal to the running config.
I will call this the 'lock-available' state instead of 'cleared',
which implies 'emptied'.

> Is it true of am I wrong?

This is an implementation detail.
I suggest keeping track of what actually changes in
the candidate, and when you apply the commit,
process only those 'dirty' nodes.

For YANG commit validation, with arbitrary XPath evaluation
(not the mythical hard-coded implementation described
in the draft), you are probably going to want to
re-run all the XPath tests on the full candidate config
before the commit.

Of course candidate doubles the memory required to store
the config database.  That's why it's an optional capability.
In order to properly perform an edit-config against the
running config in a YANG database, you probably need
to do a temp/partial copy of the running config
to run all the XPath and unique tests.

It may be hard to implement, but the agent is not
allowed to permit changes to the running configuration
which leave it in an invalid state.  Period.
That is a fundamental principle of the running config.
YANG referential integrity tests raise the bar quite a bit,
but that's by design ;-)

> tell the device that a kind of rollback have to be done?

You mean the session is hung?
If the TCP connection doesn't break, then
the operator is going to need to start a new session
and kill-session the old one, caused the discard-changes
operation to be executed in the old session before it terminates.

> Tomasz

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Nov 2008 11:03:44 -0800

I will fix that text.

Andy

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Sat, 29 Nov 2008 10:57:19 -0000 (GMT)

> must fail if the candidate has any changes in it at all.

Yes, I know. Section 7.5 says that the lock must fail if "The target
configuration is <candidate>, it has already been modified, and these
changes have not been committed or rolled back."

> I will call this the 'lock-available' state instead of 'cleared', which
implies 'emptied'.

What does it mean "conceptually equal" to the running config? Could you
explain more?

also support the :writable-running  capability, since mixing direct
edits to <running/>  would defeat the purpose of using this scratchpad
database to collect and validate changes before applying them." Let's
imagine the following situation. There is a simple device with
configurable interfaces. The interfaces may be added/removed or their
parameters can be changed (ipaddress/port/bandwidth/description etc).
At
> process only those 'dirty' nodes.

Consider the following scenario on a newly started device
(:writable-running capability is not supported):
1) Session A: works on candidate configuration and creates 10 interfaces
(0-9)
2) Session A: executes commit operation
3) Session A: after commit both configuration are "conceptually equal". At
least it means that running configuration has 10 interfaces configured
4) Session A: executes close-session
5) Session B: Starts. Its purpose is to remove interface 0 from the running
6) Session B: executes <lock> on running and candidate
7) Session B: executes <get-config> on a candidate and as a result the
instances 0-9 appear
8) in the meantime someone came to the managed device and took off one of
the interface card, let's assume this one corresponding to the interface 9
of the running configuration
9) Session B: removes an instance 0 from the candidate
10) Session B: just to check one more time executes <get-config> on
candidate and as a result sees interfaces 1-9
11) Session B: executes <commit> operation
12) Session B: executes <unlock> running and candidate

If commit operation process only 'dirty' nodes that means that after the
<commit>, running configuration does not have interface 0 and 9, although
candidate configuration before commit operation showed the instance 9.

candidate configuration have to be committed, otherwise running must
remain unchanged. What if during commit a connection with the device
would be broken, for example somebody cut the cable? How are we going
to
> operation to be executed in the old session before it terminates.

I mean a connection between a NETCONF server and a managed device has been
broken. Broken connection between the server and managed device does not
mean broken session between your NETCONF client and server. How
discard-changes would be invoked if there is no connection anymore with
the device? It means that device probably is in the invalid state because
not all changes were committed before the connection has been broken.
NETCONF cannot fake transactions on its own if the device does not support
them.

Tomasz

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: [email-masked].
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Sat, 29 Nov 2008 10:57:19 -0000 (GMT)

implies 'emptied'.

Tomasz

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2008 08:03:15 -0800

> What does it mean "conceptually equal" to the running config? Could you

has the same config=true nodes

> candidate configuration before commit operation showed the instance 9.

There is a difference between the config data for an
interface and the hardware card containing the interface.
This problem is not NETCONF-specific at all.  Whether
the config data for the missing interface disappears
is an implementation issue at this time.

> NETCONF cannot fake transactions on its own if the device does not support

According to the protocol, the NETCONF server is the managed device.
Any back-end protocol you have is just an implementation detail
to NETCONF.  But if you can no longer execute any RPC operations
except <close-session>, you could drop the session or just
return operation-failed for every request.

NETCONF has no proxy and no sub-agent protocol.  By design.
It's complicated enough to do CM without it.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Nov 2008 08:03:15 -0800

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 08:36:17 +0100 (CET)

> I read at http://www.netconfcentral.com/netconf_docs about candidate

[...]

> database to collect and validate changes before applying them."

I don't know about others, but I do know that many (most?) of our
customers have both :candidate and :writable-running.  By having both,
you give the choice to the client application - either make sure
you're alone and work with the candidate or edit running directly.
Some changes might be easier to just edit to running.

> tell the device that a kind of rollback have to be done?

4741 specifies what the server MUST do.  *How* it is done is up to the
implementation.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 01 Dec 2008 08:36:17 +0100 (CET)

[...]

/martin