Re: [netmod] a few comments on draft-wilton-netmod-opstate-yang

[Robert Wilton <[e-mail]>]

On 08/02/2016 19:41, Martin Bjorklund wrote:
> Hi,
>
> Robert Wilton <[e-mail]> wrote:
>> Hi Martin,
>>
>> On 08/02/2016 13:45, Martin Bjorklund wrote:
>>> Robert Wilton <[e-mail]> wrote:
>>>> On 06/02/2016 00:41, Andy Bierman wrote:
>>> [...]
>>>
>>>>> IMO, this solution is a non-starter.
>>>> OK, and yet my understanding is that the folks requesting a solution
>>>> to the opstate problem are saying that the applied datastore approach
>>>> is also a non-starter, or at least very undesirable.
>>> But the key to finding a solution that works for everyone is to
>>> understand *why* a datastore is a non-starter.  As I noted in a
>> [Caveat - I don't speak for the OpenConfig operators, this is just
>> my perception from previous drafts, conversations, implementing some
>> of the OpenConfig models]
>>
>> My understanding is that they want something this is very similar to
>> how the OpenConfig models look.  After all, their preferred solution
>> to the opstate problem would be for IETF to standardize on the
>> approach used in OpenConfig model design.  E.g. all config nodes are
>> defined in groupings, and then instantiated under both "config" and
>> "state" containers.
>>
>> I believe that their concerns are primarily about how the operators
>> systems interact with the models from a management client
>> perspective rather than device implementation concerns.
>>
>> With the OpenConfig model/approach they get:
>>   - The choice of having one single tree that contains all the data
>>     (intended, applied and derived) - but can be split into multiple
>>     trees if they wish.  (I.e. with their model they have no
>>     requirement to be aware of separate data stores at all.)
>>   - Every piece of data in that tree has a unique path to identify it
>>     (makes the data easy to interact with).
>>   - The intended config, applied config, and derived state can all be
>>     programmatically compared.
>>   - Related information is co-located in the tree (e.g. if you were
>>     browsing the data tree).
> Here's a slightly updated version of a drawing that has been used to
> explain how configuration data flows through the system:
>
>    [candidate] -> [running/intended] -> [applied]
>                          |
>                          v
>                      [startup]
>
> We used to have three instantiations of configuration nodes, now we
> have four (applied).
>
> Three of these are datastores.  They can be programmatically compared
> (even without data model knowledge).  Note that a "datastore" can be
> viewed as a label (with associated semantics) of an instantiation of
> these nodes.
>
> It is unclear to me why applied must be special (modelled explicitly
> rather than a named instantiation of the nodes).

I would say that applied configuration differs from the other three in 
that it isn't really configuration at all.

It is a just a representation of what the system is currently doing, but 
to make it easy to relate back to the configuration it happens to use an 
equivalent schema as for the configuration (but logically with the 
config:true labels replaced with config:false).

Given that the applied configuration is operational state, technically I 
think that it should just be part of the existing "operational state" 
datastore.  But then the problem is that the nodes have the same path as 
the intended configuration nodes in the running configuration datastore 
and hence the namespace will collide during a get request ...


>
> Your list above applies only to the intended,applied subset of the
> instantiations.  If you want to e.g. check how startup differs from
> running you need a different mechanism than to check how applied
> differs from running, which means different code paths etc.
>
>> With a datastore solution, I think that it means:
>>   - Either they have to put intended and applied config into separate
>>     trees, or they have to come up with their own scheme to combine
>>     them into a single tree (given that the cfg intended/applied names
>>     clash).
> Do you mean in their proprietary protocol?
No, I was meaning in the proprietary management systems application code.

>
>>   - If separate trees, to ensure paths are unique they would need to
>>     prefix every path with the name of the datastore/tree (hassle).
> I don't see why it would be such a hassle; compare:
>
>    /intended/interfaces/interface[name='eth0']/mtu
>
> vs.
>
>    /interfaces/interface[name='eth0']/config/mtu
I think that the existing protocol messages (e.g. NETCONF/etc) don't 
explicitly include the datastore name in the request/reply.  Often the 
appropriate data store is inferred from the context (or the request).  
Hence more code is needed to add/remove the datastore name when appropriate.

E.g. when I do a get request on 
"/intended/interfaces/interface[name='eth0']/mtu" I need to remember to 
strip off "/intended", and ensure that I frame the request to the right 
datastore.  And when I get a rpc-reply from a get-config request I need 
to know the context of the request so that I can annotate the reply with 
the appropriate datastore.

What if I want to get both 
"/intended/interfaces/interface[name='eth0']/mtu" and 
"/applied/interfaces/interface[name='eth0']/mtu"?  Do I need to split 
this into two separate requests and combine the responses?

So, given the choice between the two paths above, once of them seems to 
involve more code and work on the client side, and more chance of 
mistakes/confusion.

Rob