Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Robert Wilton <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     On 14/12/2016 14:09, Andy Bierman wrote:
>>
>>
>>     On Wed, Dec 14, 2016 at 3:07 AM, Martin Bjorklund <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Andy Bierman <[e-mail] <mailto:[e-mail]>>
>>         wrote:
>>         > On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue
>>         <[e-mail] <mailto:[e-mail]>> 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