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

From: <[email-masked]>
Date: Tue, 3 Apr 2012 10:29:26 +0100

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

* Device with limited CPU

* Device with limited memory

* Device with limited bandwidth available

* Device with limited power available

An example of a device that could include most of these constraints
might be found on a sensor net. 

Are there other constraints that need to be considered? Should any of
these constraints preclude the use of NETCONF?

If all of these can be successfully supported using vanilla NETCONF then
guidance on how that could be achieved would be helpful.

Thanks,

Jonathan Hansford

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.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 03 Apr 2012 03:32:25 -0700

> incrementally add NETCONF functionality without the need to add

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

> guidance on how that could be achieved would be helpful.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 3 Apr 2012 13:22:13 -0700

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

> 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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 03 Apr 2012 13:59:10 -0700

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

>       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,
>       As mentioned above, I originally thought to just have<get-config>,

---

From: <[email-masked]>
Date: Wed, 4 Apr 2012 09:36:10 +0100

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

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

---

From: Phil Shafer <[email-masked]>
Date: Wed, 4 Apr 2012 08:07:05 -0400

>from multiple suppliers managed through a generic "3rd-party" NMS.

I think the key need here is to stop seeing device models as the
target, but to instead model networks at a higher level.  We could
model LAN segments and point-to-point links and assign protocol
features to them (ip prefix, OSPF area) instead of repeating the
same config values for each device in the network.

With appropriate models, error checking become automatic and simple.
Opportunities for errors disappear, as the config values are entered
in a single place (can't set the an inconsistent OSPF area number
if you set it for the LAN segment).  Difficult errors become trivial
(easy to check that every interface connected to a LAN segment fits
into the segment's IP prefix).  Whole classes of impossible-to-find
errors (like misconfiguring the encoding on an unnumbered point-to-point
link) simply vanish.

The NMS would generate generic device-centric configuration that
would be translated into specific device config based on the
make, model, and role of that device.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Apr 2012 05:23:07 -0700

> make, model, and role of that device.

While very interesting, this thread has nothing to do with NETCONF
for Constrained Devices.  But I can use this opportunity to remind Phil
that we are still waiting for his draft on network-wide configuration
since the Maastricht IETF in July 2010. ;-)  I think a network-wide
data model that could run on an EMS would be a good standard.

Back to this thread -- in order for a 3rd party NMS to do useful work,
the developers need to code to a core API.  Purely optional APIs
are avoided at all cost, because alternate coding efforts to accomplish
the same task will be needed for the devices that do not implement
the optional features.

NMS developers like NETCONF precisely because the mandatory-to-implement
subset provides enough utility to avoid additional coding efforts.
Unless NC4CD provides full CM CRUD operations in some form, I don't see how it helps.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Apr 2012 18:30:57 +0200

On Sat, Mar 31, 2012 at 01:27:04PM -0700, Andy Bierman wrote:
> ...
> >You correctly figured out that section 2 provides two motivations
> >(sections 2.1 and 2.2) but you incorrectly lump them together thereby
> >creating noise but not a sound argument.
> 
> So you admit that sec. 2.2 has nothing to do with constrained devices.

I think you are aware of the history of this document and the
discussions around it. Its all openly documented, there is nothing I
have to admit.

> Because the WG chairs asked if people wanted to work on
> NETCONF for constrained devices.  They did not ask if the
> WG wants to work on NETCONF Light.

Please remember that -00 was already called NETCONF Light.

> If the WG comes to some consensus on the problem space, then
> we can talk about your 'feature-based' solution that doesn't
> actually work because there are no corresponding if-feature
> statements in the ietf-netconf module that would make the
> new features relevant in YANG.

We can augment if-feature statements into ietf-netconf.yang if you
think this is the proper way of doing things. ;-)

/js

-- 
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: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Apr 2012 11:31:35 -0700

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 04, 2012 5:07 AM
> Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices
...
> same config values for each device in the network.

Yes!  This was one of the approaches discussed at the IAB workshop
oh-so-many years ago.  One of the concepts there was that network
operational parameters (configuration in terms of how the *network*
was supposed to work) could be systematically tranformed (via XSLT,
for example) into vendor- and device-specific stuff.

But I don't see this as being the path that netconf and netmod have
taken, so I think this is just idle woulda shoulda coulda speculation,
too far beyond the scope of what the IETF would be willing to imagine.

> errors (like misconfiguring the encoding on an unnumbered point-to-point

But because there are necessarily transformations (including, unfortunately,
possible additions of information, ex nihilo from the network's perspective)
to get the device- and vendor-specific stuff, you need *real* configuration
management, perhaps along the lines of long-expired draft-presuhn-nmwebdav.
 
> make, model, and role of that device.

This is where "proper" CM rears its ugly head.  If you want to be able
to be able to revert to the configuration in effect at a particular point
in time, even if the NMS has changed, it is necessary to have what the
NMS generated under configuration management as well, in case, for
example, someone messed with the XSLTs.
 
Randy