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

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Mon, 1 Dec 2008 14:06:48 -0000 (GMT)

Martin Bjorklund wrote:
> Tomasz Mikolajczyk <[email-masked]> wrote:
>> Hi,
>>
>> I read at http://www.netconfcentral.com/netconf_docs about candidate
>> configuration that:
>
> [...]
>
>> 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."
>
> 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.

I absolutely agree.

>
>> 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?
>
> 4741 specifies what the server MUST do.  *How* it is done is up to the
> implementation.

Yes, but generally management layer cannot support transactions on its
own. In other words it cannot be said that a management layer supports
transaction unless managed device does it also, or is able to deal with
kind of situations described above. So we have to understand clearly what
support for :candidate or :rollback-on-error capabilities means in
reality, before we announce it.

> /martin

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: Mon, 1 Dec 2008 14:06:48 -0000 (GMT)

I absolutely agree.

Tomasz

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Mon, 1 Dec 2008 14:33:30 -0000 (GMT)

Andy Bierman wrote:
> Tomasz Mikolajczyk wrote:
>> Andy Bierman wrote:
>>> Tomasz Mikolajczyk wrote:
>>>> Hi,
>>>> "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?
>>> 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.
>>
>> 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."
>>
>>> 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'.
>>
>> What does it mean "conceptually equal" to the running config? Could you
>> explain more?
>>
>
> has the same config=true nodes

You cannot be sure about that. What if one device's parameters depends on
another. In this case running may not be equal to candidate.

>> 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:
>>>>  - 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?
>>>
>>> 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.
>>
>> 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.
>>
>
> 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.
>
>
>>> 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 ;-)
>>>
>>>
>>> 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.
>>
>> 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.
>>
>
> According to the protocol, the NETCONF server is the managed device.

Where is that written?

> 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.

Yes, of course. But it must the device must be reverted to the state
before commit on its own. So supporting :candidate or :rollback-on-error
in any types of such management layers forces that device must be
transactional on its own.

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

Tomasz

---

From: "Tomasz Mikolajczyk" <[email-masked]>
Date: Mon, 1 Dec 2008 14:33:30 -0000 (GMT)

Where is that written?

Tomasz

---

From: Washam Fan <[email-masked]>
Date: Tue, 02 Dec 2008 12:19:53 +0800

Hi,
> >> candidate configuration have to be committed, otherwise running 
> must>> remain unchanged. What if during commit a connection with 
> the device
> transaction unless managed device does it also, or is able to deal 
> withkind of situations described above. So we have to understand 
> clearly what
I think there exists a way that NETCONF session know underlying connection is invalid. So synchronizing candidate with running datastore can be triggered in this case.
Am I missing something?

washam

---

From: Washam Fan <[email-masked]>
Date: Tue, 02 Dec 2008 12:19:53 +0800

Hi,

washam

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 08:58:37 +0100 (CET)

Hi,

Washam Fan <[email-masked]> wrote:
> I think there exists a way that NETCONF session know underlying connection is
> invalid. So synchronizing candidate with running datastore can be triggered in
> this case.
> Am I missing something?

I think Tomasz (correct me if I'm wrong) refers to a case where the
NETCONF server function is implemented as two separate entities - a
NETCONF stack which uses some internal mechanism to communicate with
the configuration data store, and if the configuration data store does
not support any transaction protocol, it will be difficult to
implement :rollback-on-error for example.

I think this is by design - :rollback-on-error is an optional
capability which means that devices that cannot support it does not
advertise it.  This design allows you to add basic NETCONF support to
simple or legacy devices.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 08:58:37 +0100 (CET)

Hi,

/martin

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Tue, 02 Dec 2008 14:15:11 +0100

> simple or legacy devices.

No. The same problem occurs if the device is a NETCONF server. Consider the classical situation with setting two variables:

Let's assume that we have an application that we want to manage usFrom [email-masked]  Tue Dec  2 05:17:34 2008
Date: Tue, 02 Dec 2008 14:15:11 +0100
From: Tomasz Mikolajczyk <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] :candidate vs :writable-running
Sender: [email-masked]

> simple or legacy devices.

No. The same problem occurs if the device is a NETCONF server. Consider the classical situation with setting two variables:

Let's assume that we have an application that we want to maning the NETCONF protocol.
The application and the NETCONF server work IN THE SAME process. The application defines two variables "x" and "y" that may be managed and the
following API functions to manage:

int getX()
int getY()
bool setX(int)
bool setY(int)

Let's imagine that we have prepared candidate configuration with the data for x and y and we would like to invoke "commit". During commit both
functions are called in the following order:
1) setX()
2) setY()

Let's assume that calling setX() function was successful but setY() function for any reasons returned an error. According to the NETCONF
standard if commit is not successfull the state of the device must be reverted to the state before commit, citing section 8.3.4.1 from RFC 4741:

"If the device is unable to commit all of the changes in the
candidate configuration datastore, then the running
configuration MUST remain unchanged."

It means that either a server must try to set the x variable to the old state or the device must have an appropriate logic to do it on its own.
Going further another problems may appear:
1) what if the setX() function reverting old x value also fails?
2) Transaction is not only connected with atomicity. What about isolation? I mean during commit, after setX() and before setY() function, the
rest of the device can see the new value of the x variable what may mean inconsistent state of the device.

Usually we cannot afford to assume that all operations will be successful.

What do you think about it? Maybe RFC 4741 instead of the word "MUST" in the cited part above should use "SHOULD TRY TO".

Tomasz

age using the NETCONF protocol.
The application and the NETCONF server work IN THE SAME process. The application defines two variables "x" and "y" that may be managed and the
following API functions to manage:

int getX()
int getY()
bool setX(int)
bool setY(int)

Let's imagine that we have prepared candidate configuration with the data for x and y and we would like to invoke "commit". During commit both
functions are called in the following order:
1) setX()
2) setY()

Let's assume that calling setX() function was successful but setY() function for any reasons returned an error. According to the NETCONF
standard if commit is not successfull the state of the device must be reverted to the state before commit, citing section 8.3.4.1 from RFC 4741:

"If the device is unable to commit all of the changes in the
candidate configuration datastore, then the running
configuration MUST remain unchanged."

It means that either a server must try to set the x variable to the old state or the device must have an appropriate logic to do it on its own.
Going further another problems may appear:
1) what if the setX() function reverting old x value also fails?
2) Transaction is not only connected with atomicity. What about isolation? I mean during commit, after setX() and before setY() function, the
rest of the device can see the new value of the x variable what may mean inconsistent state of the device.

Usually we cannot afford to assume that all operations will be successful.

What do you think about it? Maybe RFC 4741 instead of the word "MUST" in the cited part above should use "SHOULD TRY TO".

Tomasz

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 14:46:35 +0100 (CET)

Tomasz Mikolajczyk <[email-masked]> wrote:
> No. The same problem occurs if the device is a NETCONF server.

Yes of course.

[...]

> What do you think about it? Maybe RFC 4741 instead of the word "MUST" in the
> cited part above should use "SHOULD TRY TO".

No!  Devices that cannot support :rollback-on-error should not
advertise it. 

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 14:46:35 +0100 (CET)

Yes of course.

[...]

/martin

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Tue, 02 Dec 2008 15:28:17 +0100

> No!  Devices that cannot support :rollback-on-error should not

NETCONF server cannot support commit operation unless devices guarantee that ALL operations NEVER fail. However, as you know it is very
unlikely. So going further if successful commit operation cannot be guaranteed, the :candidate capability cannot be advertised. Without
:candidate capability the server may address only running configuration (and perhaps startup) and then most of the NETCONF features immediately
disappear. Remaining functionality of the protocol is not more powerful than existing well known standards.

It must be clearly said and understood what it means in reality and what a management layer expects from the devices creators, if they want the
NETCONF support. It also means that probably most of the existing devices are not prepared on its own to be managed via NETCONF.

Another question: does it make sense to define abilities for rollback and commit operations in the separate capabilities?

Tomasz

---

From: Tomasz Mikolajczyk <[email-masked]>
Date: Tue, 02 Dec 2008 15:28:17 +0100

Tomasz