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

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2011 08:49:56 +0200

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 8 Jun 2011 14:05:40 -0700

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?

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, June 06, 2011 2:50 AM
To: [email-masked]
Subject: [Netconf] NETCONF on Constrained Devices (NETCONF Light)

Hi,

/js

---8<---8<---

---8<---8<---

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 09 Jun 2011 10:01:30 -0700

On 06/08/2011 02:05 PM, Kent Watsen wrote:
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder Sent: Monday, June 06, 2011 2:50 AM To: [email-masked] 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<---
>
> 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<---
>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 9 Jun 2011 11:28:48 -0700

> Everybody has their own text config file format!

We defined an vendor-specific capability (http://xml.juniper.net/dmi/config-text/1.0) to enable get-config/edit-config/copy-config to act on the device's native config file format.  If the WG is interested, I could submit an I-D for it...

Do you really think the format needs to be negotiated? - isn't just letting it be the device's native ASCII format sufficient?  - do you think we could get 3rd-party devices to return application/junos-text?  ;)

---

From: Andy Bierman <[email-masked]>
Date: Thu, 09 Jun 2011 12:47:25 -0700

On 06/09/2011 11:28 AM, Kent Watsen wrote:
>
>> 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!
>
>
> We defined an vendor-specific capability (http://xml.juniper.net/dmi/config-text/1.0) to enable get-config/edit-config/copy-config to act on the device's native config file format.  If the WG is
> interested, I could submit an I-D for it...
>

I am not that interested in undocumented ad-hoc formats.
The desired format is an application developer decision.
Publishing a specification for junos-text would be for the
benefit of 3rd party application developers, not other server vendors.

I think that letting the client pick the encoding is better than
assuming the application wants native CLI text.

Andy