Hi Eric,
On 31/01/2018 16:53, Eric Voit (evoit) wrote:
I have read and support these two drafts going forward.
I do have one additional thought below on
draft-ietf-netmod-revised-datastores section 5.3 default handling
process. See in-line...
*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
<j.schoenwael...@jacobs-university.de
<mailto:j.schoenwael...@jacobs-university.de>> 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.
I think that the boat has probably sailed on changing 5.3 in the NMDA
architecture, unless it is done as an erratum. I'm not sure that this
is required. I actually think that FAQs are a good place for these
sorts of examples, and extra explanatory text.
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).
Yes, that is the intended interpretation, although I think that we say
SHOULD rather than MUST, and give the implementation a bit of leeway in
choosing what is "in use".
Also, the NMDA definition of the "default" origin is wider than the YANG
default statement, or "with-defaults" definition. The NMDA definition
of the "default" origin is:
"Denotes configuration that does not have an configured or
learned value, but has a default value in use. Covers both
values defined in a 'default' statement, and values defined
via an explanation in a 'description' statement.";
The aim of this text is to allow more complex defaults, such as a
hierarchical default behavior that cannot be expressed using a simple
"default" statement.
Thanks,
Rob
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
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
