On 15/11/2017 10:41, Vladimir Vassilev wrote:
On 11/15/2017 01:06 AM, Robert Wilton wrote:
On 14/11/2017 23:41, Vladimir Vassilev wrote:
On 11/13/2017 04:27 PM, Robert Wilton wrote:
Hi Vladimir,
On 12/11/2017 10:39, Vladimir Vassilev wrote:
On 11/11/2017 08:07 PM, Andy Bierman wrote:
On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
Hi Andy,
The NMDA datastore draft
(draft-ietf-netmod-revised-datastores-06) mandates two
constraints that must apply:
(1) All conventional datastores must have exactly the same
schema. Hence differences in deviations or features are allowed
between these datastores. (sec 5.1, first paragraph)
(2) The schema for operational must be a superset of all
configuration datatstores, but that data nodes may be omitted
(sec 5.3, third paragraph).
This implies that only the following differences between
datastores are allowed:
(i) a feature can be disabled in conventional (and/or dynamic
configuration datastores), but enabled in operational (e.g. for
configurable router-id).
(ii) deviations apply in all datastores, except that
a) a deviation can remove nodes in the conventional datastores
(if they were not configurable, like the feature example)
b) a deviation can remove nodes in a dynamic datastore (e.g.
like I2RS)
c) a deviation can remove nodes from operational only if a
server is unable to accurately report them.
(iii) modules exist in all datastores, except:
a) a module can be omitted from conventional datastores (e.g.
if the module is not configurable)
b) a module can be omitted from a dynamic datastore (e.g. like
I2RS)
c) a module can be omitted from operational only if a server
is unable to accurately report the data nodes within the module.
I am not convinced that moving to a datastore-centric conformance
model instead of server-centric
is a good idea.
+1
IMO yang-library:1.1 can and should be optional. As a first step
NMDA modules and the minimal protocol support <get-data> etc. can
be implemented without yang-library 1.0 to 1.1 transition (read
server-centric to datastore-centric conformance model transition).
draft-ietf-netconf-nmda-netconf-01.txt requires migration to
yang-library:1.1. I do not see good argument to support this
limitation and there are usecases that can benefit from NMDA with
uniform datastore model design.
YANG library bis is the mechanism to indicate which datastores are
available to the client. E.g. a NMDA compatible client would
attempt to read YANG library bis on the new path using the
<get-data> RPC to determine whether NMDA is supported, and what
datastores are supported.
The existing module-state path in YANG library is preserved, but
marked as deprecated, so the intention is that it can be made
backwards compatible to clients.
I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library
Capability' states exactly that. IMO this text can be changed and
allow the case described above (<get-data> implementation with NMDA
modules implemented as indicated by yang-library:1.0 uniform model
applying to all datastores. For cases where the datastores do not
have common model yang-library:1.1 should still be mandatory). In
other words if yang-library:1.0 shows implemented
ietf-netconf-datastores <get-data> and NMDA modules listed as
implemented will not need yang-library:1.1 implementation which
takes one obstacle out of the way to rolling NMDA module
implementations.
Is there an argument making the proposed change unreasonable?
Yes, I think so.
In an NMDA implementation, the YANG library information reported in
the new structure can be entirely accurate. I.e. it can report which
modules are available in which datastores.
Of course, it is not possible to represent this in the old YANG
library, so the information that a NMDA server provides via the old
YANG library could be inaccurate. I.e. I think that it has to report
all modules and deviations as being reported in all datastores.
Hence the only way that a client would be able to know that it is
talking to an NMDA server with modules not implemented in some
datastores, or with deviations in some datastores would be for it to
query the new YANG library path. The new YANG library structures
that we are proposing below are intended to be easier for a client to
determine this, e.g. by checking whether any of the
"not-implemented-in" leaf-lists are populated.
So the aim for keeping the old YANG library path is to inter-operate
with old clients that don't know about NMDA, and hence would not be
expected to use the <edit-data> or <get-data> RPCs.
Thanks,
Rob
I still do not see an argument against supporting NMDA modules with
yang-library:1.0 in the case when and only when there are no
deviations and the implemented module sets are exactly identical for
all datastores.
OK, so when a client reads the YANG modules on the old YANG library
path, then how do they distinguish between:
(i) the information is accurate and correct
(ii) the information isn't precise because there are per datastore
differences.
Thanks,
Rob
Vladimir
Thanks,
Rob
I get it that it is supposed to allow the server to accurately
reflect its implementation,
but it actually says that servers MAY implement whatever partial
subset of a module they want,
and a client MUST deal with the mess.
IMO, YANG says that features and deviations are server-wide, not
per-datastore.
This new complexity is non-trivial to implement, so it may not be
widely supported.
The WG seems confused about the difference between a conformance
model and capabilities reporting.
(ii)(c) and (iii)(c) is about reporting, not conformance. There
is still no way to express
trivial use-cases in the conformance model such as "this module
is intended for the I2RS ephemeral datastore only"
Changing the type of a node between datastores, or changing its
properties is not allowed. The only difference allowed between
data nodes in different datastores is the nodes existence.
These rules seem more restrictive that what a server using split
config state trees (IETF style, or OpenConfig style) can achieve
using deviations today.
Lots of rules to enforce actually makes the code harder, not easier.
Thanks,
Rob
Andy
On 09/11/2017 19:33, Andy Bierman wrote:
Hi,
The new structure still has the same problems for the client as
before.
It is a major change in the architecture to have different
schema trees per datastore instead of per-server.
The server is allowed to have different features and deviations
for the same objects.
The client is completely on its own trying to compare
<operational> to anything
if the schema trees are different
container foo {
leaf bar {
if-feature X;
type string;
}
leaf baz {
if-feature "not X";
type string;
}
}
How does the client compare <running> to <operational> if the
features do not match?
If the server deviates the leaf (e.g. change type string to
int32) how does the client
compare the values?
This new complexity would be mandatory for the client to
support in some proprietary
manner since the NMDA standard ignores these problems.
NMDA was supposed to be simpler because the client could
compare intended
and applied values using the same object path. openconfig
required a data
model change and a trivial name-mapping. In reality, NMDA
is far more disruptive to existing implementations.
Andy
On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton
<[email protected] <mailto:[email protected]>> wrote:
Hi,
Given some of the feedback related to the complexity of the
YANG library bis structure, we have come up with two other
possible structures for the YANG library data:
(1) A simplified structure to make YANG library meet the
NMDA requirements, but that is closer to the existing YANG
library structure, and arguably simpler.
(2) An enhanced version of the structure (1) above, that is
also extended to allow the structure to be reused for
schema-mount via an augmentation.
For reference, at the end of this email, I have also
included the tree diagram of the existing YANG library, and
the current YANG library bis draft
(draft-ietf-netconf-rfc7895bis-02) version.
Considering the two new YANG library structures:
------------------------
*(1) A simplified structure to make YANG library meet the
NMDA requirements, but that is closer to the existing YANG
library structure.*
The main changes are:
(i) Split "implemented modules" and "import-only-modules"
into two separate lists, making the most important list
(i.e. implemented modules) keyed by module name only and
hence easier to reference.
(ii) Assume modules are implemented in all datastores by
default (with a "not-implemented-in" leaflist of datastores
that a module is not implemented in).
(iii) Assume that features are implemented in all
datastores by default (with a "not-implemented-in" leaflist
of datastores that a feature is not implemented in).
(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores
(that could potentially be extended with further per
datastore properties in future).
Manually generated tree output for proposed YANG library:
module: ietf-yang-library
+--ro yang-library
+--ro modules
| +--ro module* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? revision-identifier
| | +--ro schema? inet:uri
| | +--ro namespace inet:uri
| | +--ro submodule* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? yang:yang-identifier
| | | +--ro schema? inet:uri
| | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
| | +--ro feature* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
| | +--ro deviation*
| | -> ../name
| |
| +--ro import-only-module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro schema? inet:uri
| +--ro namespace inet:uri
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision yang:revision-identifier
| +--ro schema? inet:uri
+--ro datastore* [name] // Allows future per datastore
properties.
| +--ro name identityref
+--ro checksum string
------------------------------
*(2) An enhanced version of the structure (1) above, that
is extended to allow the structure to be reused for
schema-mount via an augmentation.*
This is similar to the structure above, except that the
"the set of modules" is contained in a list of named schema
(e.g. similar to the schema mount draft), allowing this
structure to be re-used for schema mount.
Schema mount would be expected to augment yang-library to
add in the additional schema mount information. In the
tree diagram, I have shown the schema-mount mount-point
augmentation, but not including namespaces yet.
Every server would be required to provide at least one
schema in the schema list, and the primary schema for the
device would always be given the name "primary".
module: ietf-yang-library
+--ro yang-library
+--ro schema* [name]
| +--ro name string
| +--ro checksum string
| +--ro module* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? yang:revision-identifier
| | +--ro schema? inet:uri
| | +--ro namespace inet:uri
| | +--ro submodule* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? yang:yang-identifier
| | | +--ro schema? inet:uri
| | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
| | +--ro feature* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
| | +--ro deviation*
| | | -> ../name
| | +- schema-mount:mount-point* [label]
| | +--ro label yang:yang-identifier
| | +--ro config? boolean
| | +--ro (schema-ref)
| | +--:(inline)
| | | +--ro inline? empty
| | +--:(use-schema)
| | +--ro use-schema* [name]
| | +--ro name
| | | -> /yang-library/schema/name
| | +--ro parent-reference* yang:xpath1.0
| |
| +--ro import-only-module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro schema? inet:uri
| +--ro namespace inet:uri
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision yang:revision-identifier
| +--ro schema? inet:uri
+--ro datastore* [name] // Allows future per datastore
properties.
| +--ro name identityref
+--ro checksum string
Please can you provide comments on these structures, in
particular:
Is this version better (i.e. simpler) that the version
currently in draft-ietf-netconf-rfc7895bis-02 (below)?
Should we try and make the structure extensible for
schema-mount via augmentation (i.e. version (2)), or is it
better that schema-mount has its own separate subtree?
For reference only I have included the existing YANG
library and YANG library bis draft tree diagrams.
Thanks,
Rob
-----------------------------
*** FOR REFERENCE ONLY ***
(3) The current YANG library structure in YANG library bis
(draft-ietf-netconf-rfc7895bis-02)
module: ietf-yang-library
+--ro yang-library
+--ro modules
| +--ro module* [id]
| +--ro id string
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro schema? inet:uri
| +--ro namespace inet:uri
| +--ro feature* yang:yang-identifier
| +--ro deviation* [module]
| | +--ro module -> ../../id
| +--ro conformance-type enumeration
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro schema? inet:uri
+--ro module-sets
| +--ro module-set* [id]
| +--ro id string
| +--ro module* ->
../../../modules/module/id
+--ro datastores
| +--ro datastore* [name]
| +--ro name identityref
| +--ro module-set
| ->
../../../module-sets/module-set/id
+--ro checksum string
-----------------------------
*** FOR REFERENCE ONLY ***
(4) The current YANG library structure (RFC 7895)
+--ro modules-state
+--ro module-set-id string
+--ro module* [name revision]
+--ro name yang:yang-identifier
+--ro revision union
+--ro schema? inet:uri
+--ro namespace inet:uri
+--ro feature* yang:yang-identifier
+--ro deviation* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
+--ro conformance-type enumeration
+--ro submodule* [name revision]
+--ro name yang:yang-identifier
+--ro revision union
+--ro schema? inet:uri
_______________________________________________
Netconf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
Netconf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netconf
.
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
