On 08/02/2016 21:37, Martin Bjorklund wrote:
Robert Wilton <[email protected]> wrote:
On 08/02/2016 19:41, Martin Bjorklund wrote:
Hi,
Robert Wilton <[email protected]> wrote:
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).
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
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
