Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev <[e-mail]>]

On 11/15/2017 11:42 AM, Robert Wilton wrote:
>
>
> 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 
>>>>>>> <[e-mail] <mailto:[e-mail]>> 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.
It is clear that datastores with non-identical models can not be 
supported with yang-library:1.0. However for the many usecases that do 
not require the complexity of having different datastore models 
(variation of the set of modules and the relevant deviations e.g. more 
complex datastore centric conformance model) one can implement NMDA with 
yang-library:1.0.

My initial proposal was a change to draft-ietf-netconf-nmda-netconf-01 
sec. 2.4. 'YANG Library Capability' to allow that usecase:

OLD:
Support for NMDA requires the server to implement at least revision 
201X-XX-XX of the "ietf-yang-library"
...
NEW:
Support for NMDA with datastores with non-identical models requires the 
server to implement at least revision 201X-XX-XX of the "ietf-yang-library"
...

With that there is no room left for (i) is the only option.

Vladimir
> 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
>>>>>>>>     <[e-mail] <mailto:[e-mail]>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Netconf mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>
>>>>
>>>> .
>>>>
>>>
>>
>> .
>>
>