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

[Andy Bierman <[e-mail]>]

On 04/04/2012 05:07 AM, Phil Shafer wrote:
> [e-mail] writes:
>> 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.
>
> 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.
>

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.

> Thanks,
>   Phil
>
>

Andy