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

[Robert Wilton <[e-mail]>]

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.

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