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? stringFrom 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? stringThe 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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
