Hmmm... It does sound like there is a generic NETCONF and then vendor specific agents that use it for there specific configurations. It does seem more general purpose than I had expected. Can someone explain how it differs from RPC? We should consider if the current NETCONF message formats are adequate, or whether we need a better set of semantics to serve the emerging concepts of virtualization. The existing NETCONF formats seem to provide a transparent message format, but the protocol does not capture any notion of "state" of the element or "state" of the network as a whole as particular elements are being initialized or configured... My idea would be to define a protocol that sees the network and each component as having a set of "states" (e.g. idle, configure, active/in-service, monitor, terminating, etc...), a transition diagram between states, and a set of parameters that are generic network state information and another set that may be element specific. The point being that the overall network state may be managed thru this new protocol... Perhaps this network management protocol could be autonomous - i.e. each element could discover neighbors that speak the same protocol and either locate a Master, or discover/initialize/recover themselves from such information flooding thru the neighbor elements. IMO, a generic notion of a network topology is required, and then a state of each element, netwok agent(s) that can act autonomously to configure themselves (perhaps with the help of a neighbor...) etc. As it stands, it looks like the NETCONF protocol is really a just a means to carry messages between a master and a slave, without respect to what those messages are ultimately attempting to do... Maybe this is all we need now, but we should discuss how this "network configuration process" may need to evolve in emerging (and more generalized) virtualized networks... Thoughts? jerry Bartek Belter wrote:

Hi Guy, all,

In one of the sub-projects of GN2-AMPS we were trying to address that issue. We defined a very simple structure, Abstract Vendor Independent XML (AVI-XML), which is an abstraction to provide generic specification for the configuration service. Our AMPS Configuration Service was supposed to work with an implementation of AVI-XML designed for Premium IP only. The assumption behind this work was to make it as flexible as possible, to allow future extensions to support other specific configurations (e.g. Firewall AVI-XML, etc.).

I am trying to find the latest version of this specification, but in general the idea was to identify the common attributes/parameters usually put in the request and define an abstract part, where the user can put all service-oriented data. An example (not sure about the naming, most probably original tags have slightly different names):

<AVI-XML> <global-information> ... </global-information>

<request-information> ... </request-information>

<device> ... </device>

<service> ... </service> </AVI-XML>

The "service" tag is a placeholder for further extensions.

AVI-XML forms an interface to our software. In further steps, the configuration service translates the Premium IP request into the XML file, which is applied finally to the Juniper routers.

In summary, I must say this wasn't an attempt to standardize an interface or protocol for the communication with the network equipment. What we were trying to achieve was to design and develop a piece of software which potentially could be re-used in different projects/activities to configure "any kind" of equipment for "any kind" of services. Pragmatic approach, but maybe too idealistic, don't you think? :-)

Best regards, Bartek