[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Transaction support in Netconf

Juergen Schoenwaelder wrote:


On Wed, Nov 16, 2005 at 10:17:42AM +0100, Balazs Lengyel wrote:
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 

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.


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.


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.


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



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