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

[<[e-mail]>]

> Kent writes:
> 
> [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].
> 

Particularly if the NMS is a 3rd-party development (as Kent indicated
below).

One of the operator requirements brought out in RFC3535 states:

4. It is necessary to enable operators to concentrate on the
   configuration of the network as a whole rather than individual
   devices.

That is most easily achieved if either all network products are from a
single supplier and managed through their NMS or network products are
from multiple suppliers managed through a generic "3rd-party" NMS.

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



This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.