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

[Vladimir Vassilev <[e-mail]>]

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.
>
>
>>
>> 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
>>>
>>
>> .
>>
>