Hi Andy,
Thanks for you comments, please see inline.
On 14/12/2016 15:41, Andy Bierman wrote:
On Wed, Dec 14, 2016 at 6:42 AM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
On 14/12/2016 14:09, Andy Bierman wrote:
On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <m...@tail-f.com
<mailto:m...@tail-f.com>> wrote:
Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>>
wrote:
> On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue
<mer...@gmail.com <mailto:mer...@gmail.com>> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > This architectural change needs to be implemented in
various protocols.
> >
> > > I am not sure a 6241bis is the best approach because it
is not clear
> > which
> >
> > > servers really need to implement the revised datastores.
> >
> >
> >
> > I agree fully. This is the reason why I wrote in my mail:
> >
> >
> >
> > >> - a new protocol- and language-independent standard
document (RFC XYZ)
> > defining the generic datastore concept and framework and
describing its use
> > (based on and following the DT solution draft),
> >
> > >> - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g.
with the <get>
> > operation,
> >
> >
> I do not agree with the text you wrote.
> I do not want to remove candidate, running, and startup
from RFC 6241.
> IMO the new datastores can be defined in a new document
that does not
> redefine the existing datastores.
>
> I also do not want to get rid of <get>, It works as intended.
> It is not a problem on small devices.
Andy, the problem with <get> has nothing to do with the size
of the
device. The problem is that <get> returns two things
(running config
+ operational state) in one merged output document. This forces
people to split data models so that config and state are mutually
exclusive (/interfaces and /interfaces-state). This draft
proposes a
fix for this, which makes <get> less useful.
This "problem" exists for some new overloaded use of <get> that
did not exist before.
The <get> operation only mixes config=true and config=false. It
never had anything
to do with intended vs. applied. IMO your proposed solution is
not very backward compatible
with simple systems that do not have delays between intended and
applied.
I've been informed (repeatedly ;-) that <running> has always only
ever meant intended configuration. I.e. that it is reasonable
behaviour for a system to accept config into <running> and then
fail to apply that configuration for some reason (daemon is
unavailable, linecards is down, resources have been exceeded,
programming error, etc). If this interpretation is correct then
the NETCONF <get> operation is poorly defined because it is mixing
"intended configuration of the system" along with "actual running
state".
What NETCONF <get> should really be providing is "actual
configuration in use by the system" along with "actual running
state". Of course this is effectively what the new operational
state datastore is defined as containing.
If I understand it correctly, I think that Andy's point is that
for lots of systems "intended configuration of the system" and
"actual configuration of the system" are effectively one and the
same thing. If this is the case then it should be easy for
clients/servers to migrate from an existing <get> request to a
<get-data> request that just returns the data from the operational
state datastore. It sounds like the actual data returned in both
cases should be the same?
I do not understand the new solution because it has not been well-defined.
In the old solution, I have 2 leafs /foo and /foo-state.
I can retrieve both of these leafs at once with <get>.
I can decide if /foo and /foo-state are the values I expect.
Yes, this is true. But to be a programmatically easily consumable
solution it requires that the structure under /foo is also exactly
replicated under /foo-state. This probably means that most config needs
to be put into groupings, and IMO, I think that it makes the models hard
to read, and also harder to maintain.
But if I overload /foo such that it represents different semantics in
different datastores, now a retrieval operation can only get 1 at a time.
Yes, this is true. Although it should be possible to define RPC
operations that fetch more than one datastore in the same message if
required, although I'm not convinced that is truly needed.
If I set /foo, then get-state(/foo), how do I know the config value
for /foo
has not changed in the meantime?
You don't, unless you also do a get on the running config datastore as well.
But I also don't see why this is a problem. Either the client knows
what the config should be, in which case it probably doesn't need to
explicitly ask the device, but can infer it from the operational state.
Alternatively, if another client may also be modifying the configuration
at the same time then the client needs to be designed to expect and
handle this.
Even with the existing <get> request, I don't think that any non trivial
device can guarantee that all the data returned in that get request is
atomically consistent with itself.
If the server returns 2 /foo leafs in the same
message body, then it is no longer YANG schema-valid (only 1 /foo node
is allowed)
The message body would need to return two separate data trees, one for
each datastore that is being returned.
The <get> operation does not overload objects with different semantics.
Only a new server that eliminates /foo-state is overloading the
semantics of /foo.
The new server doesn't overload the same object with different
semantics, it is really just saying that the value of an object depends
on what datastore it is being read from, which is true in NETCONF even
today. I.e. the value for a given config leaf could already differ
between candidate, running, startup. What is being proposed doesn't
seem to fundamentally change the meaning of the config leaves in a new
and different way, it is just defining new datastores with associated
more tightly specified semantics.
The ability to retrieve /foo-state is lost for a client that only
knows <get> (and not <get-state).
This does not mean <get> is broken. It just means the ability to
access /foo-state is removed.
I think that <get> is broken in the sense that it is combining together
two sets of data that cannot always be combined in a meaningful way.
For me the bigger problem is that it is only under rare conditions that
the problem scenarios arise, meaning that clients may not be coded to be
robust under those scenarios devaluing the YANG automation proposition.
Thanks,
Rob
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
