[Nsi-wg] ietf NETCONF group
Jerry Sobieski
jerry at nordu.net
Sat Jun 27 07:14:05 CDT 2009
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
>
>
More information about the nsi-wg
mailing list