Subject: Transaction support in Netconf

From: Balazs Lengyel <[email-masked]>
Date: Wed, 16 Nov 2005 09:16:03 +0100

Hello All,
I am investigating transaction support in Netconf. One way to handle this is to use an 
edit-config operation with the test=test-then-set and  error=rollback options. This 
however raises  some questions as this functionality covers only a single RPC request:
1) How big can an RPC request be ? Any limit ?
2) If I have a big configuration tree is it allowed to modify to independent parts of the 
configuration tree in one RPC request (e.g. add a new interface and switch on and 
configure OSPF in on request) ?

Balazs
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager & AXD Operational Suite (AOS) OPM
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Nov 2005 09:35:58 +0100

On Wed, Nov 16, 2005 at 09:16:03AM +0100, Balazs Lengyel wrote:
> Hello All,
> I am investigating transaction support in Netconf. One way to handle this 
> is to use an edit-config operation with the test=test-then-set and  
> error=rollback options. This however raises  some questions as this 
> functionality covers only a single RPC request:

> 1) How big can an RPC request be ? Any limit ?

I think the protocol does not specify a limit. However, concrete
implementations may have specific limits (after all, memory is usually
not unlimited).

> 2) If I have a big configuration tree is it allowed to modify to
> independent parts of the configuration tree in one RPC request
> (e.g. add a new interface and switch on and configure OSPF in on
> request) ?

I think the answer here is that this is specifically allowed.

The other option to address your requirement is to use the candidate
capability. This allows to make multiple changes on a scratchpad
configuration and once you are done with your changes, you commit the
candidate configuration in a single commit operation. I believe this
is actually better than trying to create a large atomic edit-config
transaction. (So make sure the netconf implementations you are looking
at support the candidate capability.)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 16 Nov 2005 10:17:42 +0100

Hello Juergen,
Why do you think using a candidate configuration is better then edit-config ?
pro for using candidate:
- It is difficult to assemple big edit config commands
con:
- the managed node needs to keep a complete candidate configuration or calculate a delta 
between the running and the candidate, which might be quite an effort

Any other arguments ?

Balazs

PS. If I have other questions shall I keep posting them to the newsgroup or only to you ?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Nov 2005 10:35:57 +0100

On Wed, Nov 16, 2005 at 10:17:42AM +0100, Balazs Lengyel wrote:

> - the managed node needs to keep a complete candidate configuration or 
> calculate a delta between the running and the candidate, which might be 
> quite an effort

If you modify the candidate configuration in multiple netconf
operations, you can get early feedback if you try to do something
that won't work. I believe this is useful.

Smart implementations may want to try to find a least disruptive
transition from the current running configuration to the desired new
configuration. So calculating the delta on the device might actually
be a feature as this decouples the transition logic from the manager's
instruction how to change the configuration. In other words, even if
you ship a large edit config, it might internally make sense to create
a temporary candidate configuration which is then committed (and you
then calculate a least disruptive transition plan).

But note that I am talking "theory" here since I have not written my
own netconf implementation. But if I were to do it, I would try to do
things as outlined above. Perhaps others who have been working on
implementations can say how they actually deal with this.

> PS. If I have other questions shall I keep posting them to the
> newsgroup or only to you?

Personally, I think this mailing list is a good place as long as you
have generic questions related to netconf that are potentially of
interest to others as well. This list does not suffer from too much
traffic as far as I can tell. But at the end, the chairs must decide
which traffic is appropriate here on the list and I know that IETF 
WGs have different policies when it comes to the discussion of
implementation details.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Nov 2005 13:50:52 +0100 (CET)

> implementations can say how they actually deal with this.

We handle this in the way you describe, both for edit-config and
copy-config.  But I guess it's better to discuss details off-line.

/martin

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 16 Nov 2005 08:41:41 -0500

Hi,

I think it would be helpful to other implementors, and to protocol
designers, to discuss lessons learned during implementation on the
list.

David Harrington
[email-masked] 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Bjorklund
> Sent: Wednesday, November 16, 2005 7:51 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Transaction support in Netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Nov 2005 08:26:15 -0800

>implementations can say how they actually deal with this.

The correct implementation of the <candidate> model is a fundamental design
choice in the managed system.  By definition, <candidate> means the 
capability
to edit potentially the entire device configuration 'offline' (in the 
candidate config)
is built into the system.

The implementation of the config update (apply whole document, 
edit-list, etc.)
inside the agent is outside the scope of the protocol.  It's either 
totally up
to the agent instrumentation or handled in the engine, or some 
combination of both.
The automatic <edit-config> processing of arbitrary data structures is 
non-trivial,
to say the least.  Traditional XML document processing tools may not fare so
well in large embedded devices.

>WGs have different policies when it comes to the discussion of

Really, policies? Not surprising these days.  I should look into it. ;-)

I think it's totally up to you if you want to post or reply regarding 
implementation details.
So far, all of the emails have been appropriate, some questions obvious 
from reading
the drafts, but some that have really made us think about specific 
details in the drafts.
The entire point of these RFCs is to convey information to people about 
how to
implement and use NETCONF.  There are people implementing it, and their
immediate feedback helps us debug the drafts that much faster.

However, questions about code (like how to get cyrus-sasl working on 
Fedora-4)
should NOT be sent to this list.  Just questions related to the NETCONF 
protocol.

I talked to Simon and various IESG members about setting up another 
mailing list
on ietf.org for implementation discussion.  This was done for diffserv I 
believe.
Maybe now we should try to set that up.

>/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2005 11:24:36 +0100

On Wed, Nov 16, 2005 at 08:26:15AM -0800, Andy Bierman wrote:

> mailing list on ietf.org for implementation discussion.  This was
> done for diffserv I believe.  Maybe now we should try to set that
> up.

Since you mention it, diffserv was the specific case I had in mind
where implementation discussions were pretty much discouraged on the
diffserv mailing list.  Personally, I did not like this approach very
much since I believe implementation and even early deployment
experience is extremely useful (and this list can sustain some more
traffic I would say). So I would prefer to _not_ follow the diffserv
model.

/js