Re: [Netconf] NETCONF on Constrained Devices (NETCONF Light)

[Andy Bierman <[e-mail]>]

On 06/08/2011 02:05 PM, Kent Watsen wrote:
>
> This I-D interests me, but not for resource-constrained devices...
>
> One of my roles at Juniper is to help recently acquired and OEM-ed devices implement NetConf plus our vendor-specific capabilities, in order to be managed by our NMS products.  My experience is
> that we can implement the basic<rpc>  layer, plus our vendor-specific RPCs, and maybe even support for "config-text" within the first release cycle and that full XML-based configuration (including
> schema to describe the data-model) may take another year.
>
> So, as part of a 1-2 year phased implementation, we commonly release devices that don't implement the full NetConf stack (accordingly, we don't Market them as supporting NetConf or let them listen
> on port 830).  Even though these releases have "incomplete" NetConf implementations, customers appreciate being able to manage them from our centralized NMS solution so quickly, and we appreciate
> that it's a logical stepping-stone to a complete implementation.
>
> In order to "advertize" that the device doesn't support XML-based configuration, we simply don't publish a schema to describe its configuration since, without the schema, our NMS is unable to
> manage the configuration anyway.  We view this as like publishing an empty schema, which then allows all the standard NetConf operations to be implemented as no-ops.
>
> That said, I've always wished for a more explicit mechanism for a device to advertize which (if any) of the standard NetConf operations it supports, which is very close to what your "NetConf
> Light" idea is about.  Perhaps there is an opportunity to combine these ideas together?
>

I like NETCONF Light for constrained devices where the config is so small
that it doesn't need to be managed in sections, as if it were a CLI.
Some devices will be so simple that they just know how to restart
and re-read the entire config file.

Alternate data formats for NETCONF is another matter entirely.
Maybe v2 down the road, client and server should advertise
a set of 'format capabilities', perhaps MIME types,
like application/xml, text/plain, application/json, application/junos-text,
and the session will use the first client choice the server supports.

I think several implementations support their own text .conf file format.
Everybody has their own text config file format!
(That's why linux is so great and why it also sucks ;-)

> Thanks, Kent


Andy

>
>
>
> -----Original Message----- From: [e-mail] [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder Sent: Monday, June 06, 2011 2:50 AM To: [e-mail] Subject:
> [Netconf] NETCONF on Constrained Devices (NETCONF Light)
>
> Hi,
>
> at the last IETF, we demoed some work to fit NETCONF on small embedded resource constrained devices running Contiki. We have meanwhile made some more progress and we started to write up an I-D
> that defines what we currently call 'NETCONF Light'.
>
> /js
>
> ---8<---8<---
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title           : Network Configuration Protocol for Constrained Devices (NETCONF Light) Author(s)       : Vladislav Perelman Juergen Schoenwaelder Mehmet Ersue Filename        :
> draft-schoenw-netconf-light-00.txt Pages           : 12 Date            : 2011-06-05
>
> This document describes a profile of the NETCONF protocol for resource constrained devices, called NETCONF Light.
>
>
> A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-netconf-light-00.txt
>
> ---8<---8<---
>