Re: [CCAMP] [netmod] [TEAS][NETMOD] Efficiency issues with YANG model data in integration

[Robert Varga <[e-mail]>]

On 15/03/2022 02:30, yuchaode wrote:
> Hello Friends,
> 
> I have a question about YANG data model efficiency issues discovered 
> during integration with OSS.
> 
> This issue is also mentioned in section2.2 of 
> draft-yg3bp-ccamp-network-inventory-yang that we are planning to present 
> at the CCAMP WG during IETF 113.
> 
> YANG data models define schema trees such as:
> 
> module: example
>     +--rw root
>        +--rw leaf-a?   string
>        +--rw list-b* [leaf-c]
>        |  +--rw leaf-c    string
>        |  +--rw list-d* [leaf-e]
>        |     +--rw leaf-e    string
>        |     +--rw list-f* [leaf-g]
>        |        +--rw leaf-g    string
>        |        +--rw leaf-h?   string
>        +--rw list-i* [leaf-j]
>           +--rw leaf-j    string
>           +--rw leaf-k?   string
> 
>  From the point of view of data model definition, it is convenient to 
> define objects and their relationship using a tree structure.
> 
> However, from a practical perspective, relational databases, in which 
> these objects are saved in different tables, are widely used by network 
> controllers and OSS/BSS. In this type of implementations, the model data 
> need to be cut into several pieces of small object data for management 
> and this is causing some efficiency issues with the integration between 
> systems.

[snip]

> So my question is whether, to address this efficiency issue, the only 
> viable option is to define the YANG model with a more flat structure, as 
> shown below:
> 
> module: example
>     +--rw root
>        +--rw root-summay-information
>        |  +--rw leaf-a?             string
>        |  +--rw contained-list-b*   string
>        |  +--rw contianed-list-i*   string
>        +--rw list-b* [leaf-c]
>        |  +--rw leaf-c              string
>        |  +--rw contained-list-d*   string
>        +--rw list-d* [leaf-c leaf-e]
>        |  +--rw leaf-c              leafref  (path 
> "/exmp:root/exmp:list-b/exmp:leaf-c")
>        |  +--rw leaf-e              string
>        |  +--rw contained-list-f*   string
>        +--rw list-f* [leaf-c leaf-e leaf-g]
>        |  +--rw leaf-c    leafref  (path 
> "/exmp:root/exmp:list-b/exmp:leaf-c")
>        |  +--rw leaf-e    leafref  (path 
> "/exmp:root/exmp:list-d/exmp:leaf-e")
>        |  +--rw leaf-g    string
>        |  +--rw leaf-h?   string
>        +--rw list-i* [leaf-j]
>           +--rw leaf-j    string
>           +--rw leaf-k?   string
> 
> The leaf-list object contained-list-* is a list of identifier reference 
> to list-* instance. With this kind of modeling, all the list-f instances 
> in the whole network can be retrieved without the need to specify its 
> parent’s and grandparent’s identifiers in URI.

Well, this is flat, but it brings 'leafref' and some amount of XPath 
evaluation to the runtime -- btw. I assume those are 'require-instance 
true'.

Sounds like a trade-off implementers should weigh in on...

Regards,
Robert