Hi Martin,
On 08/02/2016 13:45, Martin Bjorklund wrote:
Robert Wilton <[email protected]> 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).
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).
- If separate trees, to ensure paths are unique they would need to
prefix every path with the name of the datastore/tree (hassle).
- 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.
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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
Andy
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
