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

[Robert Wilton <[e-mail]>]

On 08/02/2016 21:37, Martin Bjorklund wrote:
> Robert Wilton <[e-mail]> wrote:
>>
>> 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).
> Just like "running" is not writable in a server that supports
> "candidate" but not :writable-running.
That isn't really the same.

The issue isn't so much about whether this is writable or not, but 
whether the data is configuration or state.

>> 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 ...
> This is a problem/known issue with <get> in NETCONF.  There have been
> various proposals to fix this, e.g. Andy's "get2".  I'd rather fix the
> problem in the protocol once, than in all data models.
>
>
>>> 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.
> ... just like I have to remember to remove the last occurance of
> "config" and replace it with "state" to get applied.  This (path
> handling) is trivial in both solutions.
I don't agree that the complexity is the same here for both cases.

In the OpenConfig models you just get and process the item that you want:
  - No extra path manipulation is required.
  - The path itself always fully resolves to an individual value.
  - There is never any ambiguity.

>
>> 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?
> Currently yes.  Just like if you want to get both the values from
> startup and from running.  Also in this case, I'd prefer to solve the
> problem generically in the protocol.
OK.

Can you please suggest an approach of how to return a single tree that 
contains the data from two separate datastores (where the leaf paths may 
overlap)?  I think that the approach would need to work both for get 
requests and also notification data.

Rob


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