Subject: [Netconf] A question on NETCONF versus RESTful webservices

From: Graham Phillips <[email-masked]>
Date: Tue, 9 Jun 2009 16:05:53 -0700

Hello,

I am a proponent of NETCONF and am trying to promote it within my organization, Netscaler/Citrix.

I am running into some difficultly selling NETCONF to my colleges who have build a prototype using a RESTful web services approach.   In this approach they are using JSON over HTTP.   The retrieval of individual configuration entities is handled by mapping the request to an HTTP GET request on a particular URL (eg. GET device_ip_address/entity_X/name).  Setting of configuration entities are mapped to HTTP POST requests.

Can anyone give me some ideas how I might sell the NETCONF idea to non-believers?
I think some advantages of NETCONF are:
            1) That it is a standard that has been adopted by large network vendors (ie Juniper and Cisco)
                        Any others?
            2) I suspect that it has been adopted by network management vendors.  Do we have any vendor names?

One question that I have been asked is how easier is it to wrap client-side language-bindings around the NETCONF protocol.  For example, in the web services world, one has a WSDL file, and client side language binding can be automatically generated.    How does one achieve this stub generation with NETCONF?  Can this be achieve with the NETCONF over SOAP scheme.

Thank you.
--Graham Phillips

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jun 2009 09:19:32 -0700

Graham Phillips wrote:
> I am running into some difficultly selling NETCONF to my colleges who 
> have build a prototype using a RESTful web services approach.   In this 
> approach they are using JSON over HTTP.   The retrieval of individual 
> configuration entities is handled by mapping the request to an HTTP GET 
> request on a particular URL (eg. GET device_ip_address/entity_X/name).  
> Setting of configuration entities are mapped to HTTP POST requests.
> 
>  
> 

There are many reasons that NETCONF/YANG are better suited
for embedded networking devices.  This is probably the
wrong list for a detailed discussion.

For many reasons, managing a router as if it
was just an XML instance document that can be
peeked and poked with data just doesn't work.
On the other end, asking a router to provide
complex transaction capability found in an SQL server
is too heavy-weight.  NETCONF is somewhere in between.

Try these links for more info:
http://trac.tools.ietf.org/wg/netconf/trac/wiki
http://www.netconfcentral.org/
http://www.yang-central.org/twiki/bin/view/Main/WebHome

> One question that I have been asked is how easier is it to wrap 
> client-side language-bindings around the NETCONF protocol.  For example, 
> in the web services world, one has a WSDL file, and client side language 
> binding can be automatically generated.    How does one achieve this 
> stub generation with NETCONF?  Can this be achieve with the NETCONF over 
> SOAP scheme.
> 

People may or may not be working on YANG translation
tools which would help here.  The best part about
NETCONF is YANG, and that's not quite here yet.
Complex networking services require complex APIs to manage.
NETCONF/YANG provides the building blocks for such APIs.

> --Graham Phillips

Andy

---

From: Tomoyuki Iijima <[email-masked]>
Date: Thu, 11 Jun 2009 07:46:11 +0900

Hello Graham,

 >             2) I suspect that it has been adopted by network managemen
 > vendors.  Do we have any vendor names?

 > stub generation with NETCONF?  Can this be achieve with the NETCONF ov
 > SOAP scheme.

We (Alaxala Networks in Japan) have an experience of implementing 
NETCONF over SOAP. I used Apache Axis to generate stub class (Java API) 
from SOAP scheme (WSDL file). By utilizing the stub class (Java API) and 
other commonly available Java libraries, we could develop several 
network management systems. I wrote some parts of our experience in 
RFC5381. But as long as data model is not decided, full interoperability 
is not ensured...

p.s.
We are also taking into account using RESTful webservices.

Kind regards,

--
Tomoyuki Iijima