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

[Kent Watsen <[e-mail]>]

[back from vacation, which is why I've been MIA for the last week]



Andy writes:
>
>On 04/03/2012 02:29 AM, [e-mail] 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