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

[Martin Bjorklund <[e-mail]>]

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

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?

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


>  - Comparing the intended and applied trees is a bit more hassle
>    (they would need to perform a pairwise walk across both intended
>    and applied configuration trees). 
>  - When data is being returned from the server (if it is even
>    allowed for two datastores to be returned in the same request) then
>    data would not be co-located.  I.e. you have to read in all the
>    data for both intended and applied config datastores before you can
>    start processing any of it.  Whereas if the data is returned in a
>    single tree then co-located data would be returned together and the
>    the stream of data can be filtered/processed without building up an
>    intermediate combined tree of all the data. 
> 
> > previous email, both your solution and the datastore solution rely on
> > the assumption that the server internally knows the difference between
> > the "intended" and "applied" value for the config true nodes.
> Please can you clarify - I don't really follow this point.

In the open config solution there is just one schema and the server
just calls the instrumentation to fill in the values.  The server
doesn't know if a node is "applied" or "derived".

In our solutions, the server knows from the request what data is
requested, and calls the corresponding instrumentation.


/martin





> For all solutions, it only makes sense if the server internally
> knows the difference between intended and applied values, so I
> assume that is just a given.
> 
> 
> >
> >> (Note - I don't
> >> actually know whether they regard the solution in
> >> draft-wilton-netmod-opstate-yang to be any more palatable.)
> > Right; so if their objection is that the server cannot know the
> > difference between "intended" and "applied" for the config true leafs,
> > neither of our solutions work.
> >
> > And if their objection is that their proprietary protocol does
> > can/does not encode the datastore in the "get" request, then
> > I suspect that their protocol also does not know your proposed
> > encoding.
> >
> >>  From a clients operational perspective I can see how the OpenConfig
> >> model, with separate intended config and applied config leaves that
> >> are co-located in the schema tree makes life easy for the client in a
> >> way that having a separate applied configuration datastore doesn't
> >> seem to.
> > I can see how the applied datastore model makes life easier for the
> > client, e.g., a diff can be done w/o any data model knowledge at all.
> Possibly.  But that requires that they have to manage having a
> separate datastore for applied config in the first place, and I'm
> not convinced that doing a pairwise diff across two datastores is
> any easier than the equivalent "diff" algorithm that they would
> write for checking the config state in the OpenConfig models. 
>  
> Rob
> 
> 
> >
> >
> > /martin
> >
> >
> >> Rob
> >>
> >>
> >>>
> >>>      /js (stating a clear opinion as a technical contributor)
> >>>
> >>>      --
> >>>      Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>      Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>>      Fax:   [phone]         <http://www.jacobs-university.de/>
> >>>
> >>>
> >>>
> >>> Andy
> >>>
> >>>      _______________________________________________
> >>>      netmod mailing list
> >>>      [e-mail] <mailto:[e-mail]>
> >>>      https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>>
> > .
> >
>