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

["Randy Presuhn" <[e-mail]>]

Hi -

> From: "Phil Shafer" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, April 04, 2012 5:07 AM
> Subject: Re: [Netconf] Netconf Light or Netconf for constrained devices
...
> 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.

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.

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

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

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