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

Kent Watsen <kwatsen@juniper.net> Wed, 08 June 2011 21:08 UTC

Return-Path: <kwatsen@juniper.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B707321F8583 for <netconf@ietfa.amsl.com>; Wed, 8 Jun 2011 14:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvNmQqyn6UE9 for <netconf@ietfa.amsl.com>; Wed, 8 Jun 2011 14:07:59 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id F0A7021F8586 for <netconf@ietf.org>; Wed, 8 Jun 2011 14:07:58 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTe/kqx/r1YSN1OgwsUvWurX3LrkLABlb@postini.com; Wed, 08 Jun 2011 14:07:59 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 8 Jun 2011 14:05:42 -0700
From: Kent Watsen <kwatsen@juniper.net>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netconf@ietf.org" <netconf@ietf.org>
Date: Wed, 08 Jun 2011 14:05:40 -0700
Thread-Topic: [Netconf] NETCONF on Constrained Devices (NETCONF Light)
Thread-Index: AcwkFgiB9mlM31LGQpyD6n7db54tDQCApmhQ
Message-ID: <84600D05C20FF943918238042D7670FD3E81BD017A@EMBX01-HQ.jnpr.net>
References: <20110606064955.GC23643@elstar.local>
In-Reply-To: <20110606064955.GC23643@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Netconf] NETCONF on Constrained Devices (NETCONF Light)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2011 21:08:00 -0000

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: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Monday, June 06, 2011 2:50 AM
To: netconf@ietf.org
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<---

-- 
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
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf