From: Robert Wilton -X, January 31, 2018 6:31 AM
Hi Andy,
On 31/01/2018 09:22, Andy Bierman wrote:
On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>> wrote:
On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
Hi,
I have some questions about these drafts.
1) what if datastore set to "conventional"?
There are many places where a datastore-ref type is used.
However, "conventional" is valid for base "datastore", even though
it is ambiguous as a datastore selector.
We can add explicit text that an identity that does not resolve to a
datastore implemented by the server results in an invalid value error.
OK
2) origin filter is limited to 1 source
This filtering seems rather limited. A client must retrieve
<with-origin> and check
all the values in use, then make repeated requests for each source as a
different
<origin-filter> leaf
If the client does <with-origin>, then it has all origin information
and it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=or:system or origin-filter=or:learned in one request.
OK
3) with-defaults broken
The operational datastore does not support with-defaults.
Instead, the client must use origin-filter=or:default or with-origin
and check all the origin attributes. Since a client needs to use
with-defaults for other datastores, this special handling of
<operational>
seems unhelpful.
I think the with-defaults semantics for conventional configuration
datastores are much more complicated than necessary for the
operational state datastore. Note that that the operational state
datastore reports in-use values not really defaults:
<leaf or:origin='default'>foo</leaf>
This reports that the value 'foo' is in use and that it originates
from a default value. Note that this could also be
<leaf or:origin='intended'>foo</leaf>
in case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The with-defaults
solution is pretty complex because it tries to handle how different
systems deal with configuration defaults. The idea is to not carry
this complexity over to in-use values in the operational state
datastore.
Before NMDA, the client could decide if it wanted to retrieve default nodes or
not.
This client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned from operational
(defined in section 5.3 of the NMDA architecture):
- it should return explicit values for everything that is affecting the actual
running state of the device (regardless of whether the operational value
matches a schema default value).
- it does not need to, and should not, return operational values for stuff that
isn't actually in use, i.e. don't return needless and unwanted data.
In particular, if no value is returned from a particular data node in
<operational> then, barring mgmt protocol errors, a client can assume that any
functionality associated with that data node is off (i.e. not in use).
Some examples to illustrate the behavior:
(i) If a protocol, e.g. OSPF, is not enabled/running then <operational> does
not need to return any data for it. It would be reasonable to return a flag to
indicate that OSPF is not enabled/running.
(ii) If you have some funky widget on an interface that defaults to being off and
isn't being used then <operational> don't need to return any data for it.
(iii) But, if you have some funky widget on an interface that defaults to being
on, then the server should return data for it. If it is actually enabled, then
it would indicate that it is on and return any associated values with its
operational state, or if it is disabled then it should explicitly report that
it is off.
(iv) I would regard that all applied configuration is "in use" by the system,
even if it matches the default value, and hence it should be reported.
This behavior for <operational> is obviously slightly different from the existing
with-default handling that is supported for configuration datastores. As I recall, there
were a couple of reasons that we decided to have a different behavior for
<operational>:
(a) to have consistent semantics for all servers, rather than different servers
supporting different with-defaults behaviors (which makes life harder for
clients because they must cope with all variants).
(b) to remove any potential ambiguity if data isn't returned. I.e. with the
existing with-defaults semantics it is not clear to me that servers will always
return an explicit value to indicate that a particular widget is off if the
schema defines that the default it that is enabled. If the server doesn't
support a given widget at all, it is quite plausible that it will just return
no data for it. In theory features/deviations should handle this, but those
don't work so well if different linecards have different capabilities. Hence
being explicit about stuff that is in use seems more robust.
<eric> These are good examples. It would be great if section 5.3 could be
tweaked to make clearer the relationship between running datastore defaults and other
operational datastore defaults for the same tree.
For example, let’s say I create a configured subscription, and the default
transport protocol is NETCONF. NETCONF will be used for that subscription even
though the node might not be populated. In this case, the object would not
appear in the running datastore, but MUST* appear in the operational datastore
with the default origin (as it is in-use).
This to me is the desired behavior as it doesn’t incorrectly add information to
the running datastore, but shows what is in-use within operational. I suspect
other such relationships for other operational tree defaults could be asserted,
perhaps based on the origin.
(* Maybe ‘MUST eventually’, as obviously there is a temporal relationship
between the two datastores.)
Eric
Thanks,
Rob
/js
Andy
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
