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

[Robert Wilton <[e-mail]>]

On 11/12/2017 15:53, Vladimir Vassilev wrote:
> On 12/11/2017 12:16 PM, Robert Wilton wrote:
>
>> Hi Vladimir,
>>
>>
>> On 09/12/2017 11:49, Vladimir Vassilev wrote:
>>> On 12/08/2017 07:01 PM, Andy Bierman wrote:
>>>
>>>> Hi,
>>>>
>>>> A library per datastore sounds too complicated.
>>> I am not proposing that.
>> I'm slightly lost, because I thought that was exactly what you were 
>> proposing! ;-)
> I propose a solution that keeps ietf-yang-library a data model of a 
> single YANG context specification doing the datastore specific 
> modeling in ietf-datastores model instead. The solution can be both 
> flexible (independent yang-library data instances per datastore as my 
> example was focused on) or constrained ('not-implemented-in' modules 
> leaf-list). Here is everything that is needed:
>
> module: ietf-datastores
>     +--ro datastores-state
>        +--ro datastore* [name]
>        +--ro (model)?
>           +--:(same-as-operational)
>           +--:(constrained-to-operational)
>           |  +--ro not-implemented-in*       -> 
> /yanglib:module-state/module/name
>           +--:(unconstrained)
>              +--ro yang-library-datastore?   identityref
>
> YANG:
> ...
> container datastores-state {
>     config false;
>     list datastore {
>       key name;
>     }
>     choice model {
>         case same-as-operational {
>         }
>         case constrained-to-operational {
>           leaf-list not-implemented-in {
>             type leafref {
>               path "/yanglib:module-state/yanglib:module/yanglib:name";
>             }
>           }
>         }
>         case unconstrained {
>           leaf yang-library-datastore {
>             type identityref {
>               base ds:datastore;
>           }
>         }
>       }
>     }
>   }
> ...
>
> IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I 
> do not see why this has to be compromised.

But a major version change to YANG library is happening here.

In rfc7895, if a module is implemented then it is implemented in all 
configuration datastores, and <operational> doesn't exist.

Alas, that is not what is required for NMDA, it needs different 
semantics with more granularity.  You cannot achieve this without 
changing the meaning of the existing YANG library data nodes, which will 
break clients.


>>>
>>> The fundamental point proposed is that the datastore relevant bits 
>>> are kept in the ietf-datastores module instead of merging everything 
>>> in a new ietf-yang-library entangled monster module. If needed 
>>> ietf-datastores can augment ietf-yang-library but ietf-yang-library 
>>> should be usable on its own without ietf-datastores. The solution is 
>>> coherent and modular and addresses the problem statement.
>>
>> The issue with this is that datastore augmentations to YANG library 
>> would end up changing the meaning of the existing YANG library 
>> nodes.  E.g. an old client that ignores the datastore augmentations 
>> is going to get a nasty surprise when the server does not behave how 
>> it expects.  E.g. because the configuration node that it thinks 
>> should be there isn't there because it only supported in <operational>.
>>
>> This was one of the reasons for changing YANG library.
> A well written client that finds out unsupported newer versions of 
> ietf-yang-library (which is reported in the capabilities) or any of 
> the NMDA modules is deployed should not do any damage. How exactly did 
> you solve the problem for the bad clients by changing the structure of 
> yang-library in a incompatible way is something I do not understand.

Servers have a choice:
If a server just wants to supports pre NMDA models + RPCs then it would 
use rfc7895.
If a server only wants to support post NMDA models + RPCs + clients, 
then it can use the new YANG library (and not implement the 
modules-state container).

If a server wants to support old and new clients then there are few choices:
(1) Use configuration to control which mode the server is running in.
(2) Run separate copies of the mgmt protocols on separate port numbers.
(3) Implement the NMDA models, and then publish the schema of 
<operational>, or perhaps <running>, in the modules-state container.  
Pre NMDA clients, using <get> would probably not see all system 
information.  This approach starts to have issues if there are 
differences between what is configurable and what is in operational.


>>
>> In terms of the idea of just re-using YANG library but export a 
>> separate copy for each datastore I think that this has its own problems:
>> - I don't like the idea of returning meta-data along with 
>> configuration for a <get-data> on any of the configuration datastores.
> There is no meta data. The datastores contain only the config false; 
> /modules-state tree. I think I explained that very clearly.

YANG library doesn't represent regular server operational data, but 
instead it is meta-data about the server instance, which is why it is 
allowed to differ between NETCONF and RESTCONF (which I don't really like).

Yes, you explained returning /modules-state from candidate, running, 
intended, i2rs, etc.  Unfortunately I really dislike this approach 
because it feels like a backwards step where we have trying to get a 
clean split between configuration and state.   Hence defining a 
<get-server-metadata> RPC would be a better choice.


>> - How does a client know whether the YANG library for <running> 
>> applies to the whole server (as it does today) vs just applies to the 
>> <running> datastore (as it would for an NMDA server)?
> All datastore models are "case same-as-operational" for such systems.

This isn't about how the server implements it, but instead my concern is 
about how the client interacts with it.

I appreciate that it avoids a client having to parse a new YANG library, 
but more concerning for me is that the existing YANG clients will not 
see the behavior that they expect, and rather than failing, they will 
work in an unknown degraded fashion.


>
>> - It requires more handshaking between the client and server to get 
>> the schema, since a separate request would be required for each 
>> datastore that is supported.
> Correct. Flexibility and modularity come at a price. IMO modularity is 
> more important in this case. And there are solutions for the problem 
> e.g. send all <get-data> requests before waiting for replies. NETCONF 
> supports this.

I perceive that your argument is less about modularity, and instead it 
seems to be more centered around not making any changes to the structure 
of the existing YANG library.


>>
>> So, for me, I think that the only way that this solution works, would 
>> be to define a new <get-server-metadata> RPC, but even then I think 
>> that it would make sense to combine the data together into a new YANG 
>> library structure.
> As I said my focus is on keeping ietf-yang-library modular (single 
> YANG model context). <get-server-metadata> or just adding datastore 
> identities allowing the client to use <get-data> to achieve the 
> retrieval of the data is of little importance to me.
This seems to be a complex approach, introducing new protocol semantics, 
or overloading operations, to avoid revising an existing module structure.

I don't think the new proposed YANG library structures are less modular, 
in fact, I would argue that some of the approaches are designed to make 
the structure more modular and reusable (e.g. by having named schema).

Thanks,
Rob


>
>>
>> At the end of the day, I don't think that a new YANG library is going 
>> to be were the real cost for supporting NMDA comes from. I think that 
>> the real work is supporting <operational> independently from 
>> <running> both in the client and servers. But I also think that once 
>> servers start implementing this properly that it will simplify 
>> automation, because rather than a client having to guess what state a 
>> server is in, it can actually querey, or be notified of it, without 
>> having to write a lot of model specific code.
> +1
>
> Vladimir
>>
>> Thanks,
>> Rob