Re: [Netconf] Netconf Light or Netconf for constrained devices

Andy Bierman <andy@netconfcentral.org> Tue, 03 April 2012 20:59 UTC

Return-Path: <andy@netconfcentral.org>
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 9398711E810F for <netconf@ietfa.amsl.com>; Tue, 3 Apr 2012 13:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id papL4YjqS0ms for <netconf@ietfa.amsl.com>; Tue, 3 Apr 2012 13:59:15 -0700 (PDT)
Received: from p3plsmtpa08-07.prod.phx3.secureserver.net (p3plsmtpa08-07.prod.phx3.secureserver.net [173.201.193.108]) by ietfa.amsl.com (Postfix) with SMTP id D413411E809D for <netconf@ietf.org>; Tue, 3 Apr 2012 13:59:15 -0700 (PDT)
Received: (qmail 9837 invoked from network); 3 Apr 2012 20:59:10 -0000
Received: from unknown (75.84.164.152) by p3plsmtpa08-07.prod.phx3.secureserver.net (173.201.193.108) with ESMTP; 03 Apr 2012 20:59:10 -0000
Message-ID: <4F7B649E.6090806@netconfcentral.org>
Date: Tue, 03 Apr 2012 13:59:10 -0700
From: Andy Bierman <andy@netconfcentral.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Kent Watsen <kwatsen@juniper.net>
References: <B9468E58D6A0A84AAD66FE4E694BEABB49CA8C16@ucolhp4j.easf.csd.disa.mil><4F765A4F.3040805@netconfcentral.org><20120331051538.GB70150@elstar.local><4F76AA02.4030401@netconfcentral.org><20120331093809.GB70620@elstar.local><4F7701F9.7020802@netconfcentral.org><20120331142936.GA71199@elstar.local> <4F776898.9060904@netconfcentral.org> <83C941F7F59F3F42AC017AD1E650546206952E1E@GDUKADH850.uk1.r-org.net> <4F7AD1B9.3050009@netconfcentral.org> <84600D05C20FF943918238042D7670FD48C0724606@EMBX01-HQ.jnpr.net>
In-Reply-To: <84600D05C20FF943918238042D7670FD48C0724606@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices
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: Tue, 03 Apr 2012 20:59:16 -0000

On 04/03/2012 01:22 PM, Kent Watsen wrote:
> [back from vacation, which is why I've been MIA for the last week]
>

Nobody but the co-authors have said they want to work on the problems in sec 2.2.
I think it's up to the co-chairs to decide how to proceed.


Andy

>
>
> Andy writes:
>>
>> On 04/03/2012 02:29 AM, Jonathan.Hansford@generaldynamics.uk.com wrote:
>>> For someone recently coming to NETCONF, I would have thought constrained
>>> devices would include some or all of the following characteristics:
>>>
>>> * During development, prior to release, it would be good to
>>> incrementally add NETCONF functionality without the need to add
>>> deviation statements
>>
>> This is the only use case I find puzzling.
>> In my experience, internal server releases to the NMS developers
>> never use deviations.  Partial functionality is often delivered,
>> but its scope and limitations are communicated out of band. (e.g., email).
>
>
> We have learned the hard way that communicating limitations "out of band" doesn't work.  It's too easy for stuff to fall through cracks, and the cruft that builds up over time becomes unbearable to maintain, but the worst for us is that the hacks cannot be supported without a corresponding release of the NMS software, which is unacceptable in some customer environments [this is the same reason "deviations" are a non-starter for us].
>
>
> Pushing forwards, there appear that there are two distinct concerns:
>
>    1) a definition of "constrained"
>    2) if "netconf-zero" plus features is viable
>
>
> Looking at these in turn:
>
>    1) what is "constrained"? - Juergen's impetus for the draft was
>       to support physically constrained devices.  Realizing that the
>       solution to Juergen's concern overlapped with the solution
>       needed to support my "non-technical" issues, I raised
>       it at IETF'79.  Mehmet and Juergen agreed and we added it.
>
>       My feelings are that the draft is still too focused on "physical
>       constraints", when maybe the focus should be turned around to
>       look at the limitations of the NETCONF protocol itself.  I
>       wouldn't say NETCONF is "constrained", it's "constraining".  IMO,
>       looking for a definition of a "constrained device" is barking
>       up the wrong tree.
>
>
>    2. is "netconf-zero + features" a viable strategy?  You know, my
>       original thought was to just allow "<get-config>  without subtree
>       filtering".  Jeurgen's idea was to have<get>,<close-session>,
>       and<kill-session>.  Then, on Jan 21, you wrote (in a PM) that
>       "<copy-config>,<get-config>  w/o filters, and<close-session>"
>       plus correct<hello>  message would suffice, but now I see you've
>       added<edit-config>,<lock>, and<unlock>.  A lot of variance,
>       perhaps illustrating a zero-based makes sense afterall...?
>
>       As mentioned above, I originally thought to just have<get-config>,
>       since it seemed all other NETCONF operations depended on it, but I
>       now believe it's better this way, per -01, section 2.2, BP #1;
>       which I contend *is* "relevant to IETF", since NETCONF defined
>       the extensibility mechanism in the first place.  Think of it as
>       a sign of success, as we wouldn't have picked NETCONF otherwise ;)
>
>       But the question to ask might be, what difference does it make if
>       "light" starts with netconf-zero?  Surely it's better for the devices,
>       and it's not like the NMSs are going to implement any less NETCONF,
>       as they're going to need it all to interoperate with other devices.
>       So, again, what difference does it really make?
>
>
> FWIW, as mentioned before, my company has been developing a *data-driven* NMS app for almost 7 years now.  The app is designed to manage our entire product line while never closing the door towards going "multi-vendor" someday - while my company is a "vendor", our NMS is developed in the same way that you'd expect from a 3rd-party developer.  Our NMS implements device-adapters so that it can communicate NETCONF to devices that don't support it natively.  We've worked with a number of OEM partners who already had "NETCONF" implemented, only to discover that it didn't implement half the operations or some incorrectly, and yet our NMS still has to manage the OEM-ed device.  Trust me, this isn't just the "device team is lazy" - there is much more in the way.  This draft has the potential to resolve many real-world issues for us.
>
>
> PS: And I thought we'd reached the end of this discussion when you wrote:
>
>    "I don't think there is enough standards value in this draft
>     to be worth implementing, but I'll shut up now since others
>     appear to want to implement it."
>
>     http://www.ietf.org/mail-archive/web/netconf/current/msg07356.html
>
>
>
>
>
> Thanks,
> Kent
>
>
>
>
>
>