Re: [netmod] operational knobs

[Andy Bierman <andy at netconfcentral.com>]

Romascanu, Dan (Dan) wrote:
>  
> 
>> -----Original Message-----
>> From: netmod-bounces at ietf.org 
>> [mailto:netmod-bounces at ietf.org] On Behalf Of Randy Presuhn
>> Sent: Tuesday, November 03, 2009 6:38 PM
>> To: NETMOD Working Group
>> Subject: Re: [netmod] operational knobs
>>
>> Hi -
>>
>>> From: "Andy Bierman" <andy at netconfcentral.com>
>>> To: "Phil Shafer" <phil at juniper.net>
>>> Cc: "NETMOD Working Group" <netmod at ietf.org>
>>> Sent: Tuesday, November 03, 2009 10:26 AM
>>> Subject: Re: [netmod] operational knobs
>> ...
>>> IMO, new verbs and nested data structures in notifications are the 
>>> best parts of YANG.
>> Initially, we thought the same thing about these capabilities in CMIP.
>> Implementation and deployment experience demonstrated that 
>> they came at a high cost, though in areas that netconf hasn't 
>> really started to dig into.
>>
> 
> What changed in the two decades dramatically is the cost of the
> resources needed for implementation on a network device. As an
> implementer at that time I can bare direct witness that the principal
> reason we adopted SNMP at that point in time was simply that it was
> implementable in network devices (hubs, bridges, routers) while CMIP was
> not. 
> 
>>> The config database may
>>> turn out to be a 'legacy' concept, and complex verbs may replace 
>>> get/set operations on an XML tree someday.
>> If that's the case, then you may as well discard the whole 
>> notion that configuration management is about bringing a 
>> system to a reasonably known state.
> 
> I would agree. I do not see yet how interoperable management is possible
> without a config database shared between different vendors of devices
> and applications but maybe it's just that I am not imaginative enough. 
> 

I'm not saying the technology is in place to
allow a command-oriented approach to completely replace the
data-oriented approach, but...

The problem with pure data structures is that the high-level
procedures built on top of the data structures are not uniform,
and usually not even formally defined.

It may not make sense to adjust knobs arbitrarily once a network
service has been created from the XML representation
of the desired state.  This was often the case with MIBs,
and there are many DESCRIPTION clauses that say "This object
may not be modified if the associated RowStatus is equal to 'active'".

There are high implementation, interoperability, and training
costs due to the data-approach that are not immediately obvious.
Operators like to think in terms of sending commands to the device.
Translating between YANG data structures and high-level commands
is ad-hoc and usually non-trivial.

IMO, we would reach faster, better interoperability by standardizing
basic operations, and not mandating complete adoption of
complex data structures.

For example, an operation to start a DHCP service instead of a complex
data structure:

   start-dhcp (start-address=192.168.1.10, end-address=192.168.1.100, ...)

There are no internal data structures that can be
altered in arbitrary ways with edit-config and copy-config.
There is no parameter changing on the fly to support.

Obviously DHCP config would be way more complicated
than this, but my point is that RPC operations allow the WG to
standardize procedures, which can be a subset of
all possible protocol behavior.  This allows some forward progress,
in highly directed and interoperable steps.  I am not
convinced that the forklift data-model (ala ipfix-psamp.yang)
has much chance of widespread deployment.



> Dan
> 
>> Randy

Andy