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

Re: Comments on version 2 of protocol draft and issue list (#rollback and <lock>)

Faure Ragani Alessandro wrote:

I have followed the work of NETCONF as an observer from an operator perspective and I would like to ask a clarification on the draft and post a couple of comments on the issue list.

First of all just a clarification: I’ve noticed that the Section dealing with Executive Commands has been removed from version 2 of protocol draft? Is there any particular reasons or it’s only due to the fact that there will be no support for executive commands in v1.0 of the protocol? What about future releases?


There could be support for executive commands in future releases. For 1.0 we're not going to define any, so the section was removed.


Here are two comments on the #rollback capability and on the <lock> operation.

--- #rollback capability

I think that from an operator perspective the implicit rollback, which is coupled with the confirmed commit in the document, is very useful. In fact it should avoid application from loosing the connectivity with devices because of an error that can’t be highlighted with syntax and semantic check on the device. For example I have in mind the situation of an application that is trying to add a new site to a VPN and uses bad IP address or NAT configuration.


Yep, based on the Seoul meeting Andy proposed some text that would put rollback back into 1.0.

--- <lock> operation

I agree that implementing partial locks is very difficult and coupled with the data-model, but nevertheless they could be very useful for better provisioning performance.

In general you have different applications configuring devices for different purposes and with different requirements.

Imagine you have:

a) an application that has to reserve/set up paths with specific QoS characteristics in order to answer frequent requests coming from a SIP Server

b) an application dealing with ACL provisioning on CPEs.

Well, it should be great to give the two applications access to the device at the same time, if they work on different subsets of the data-model: for example diffserv and TE functionalities for a) and ACL functions for b).

I know that probably this scenario is not the one the protocol is designed for, but I think it is one the protocol could be used in.


Unfortunately NETCONF won't be all things to all applications in it's first incarnation. It has to make some simplifying assumptions in order to finish up. Once we better understand the data models that folks want to use we may be able to come up with a partial locking mechanism that can be standardized.

Rob


Thanks

Alessandro Faure

Telecom Italia LAB

Networking Division

Turin, Italy

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to MailAdmin@tilab.com. Thank you
====================================================================



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