[Nsi-wg] ietf NETCONF group

[Jerry Sobieski]

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