Hi -
On 2022-03-17 9:32 AM, tom petch wrote:
...
From: netmod <[email protected]> on behalf of yuchaode
<[email protected]>
Sent: 15 March 2022 01:30
To: '[email protected]'; '[email protected]'; '[email protected]'
Cc: Fatai Zhang
I have a question about YANG data model efficiency issues discovered during
integration with OSS.
...
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.
<tp>
When the data definition language that we know as YANG was being specified, the
question did arise of how object-oriented it should be and the consensus was
that it should not be. Seeking to retrofit such a concept might be a bit like
finding late in the day that the class definitions that have been chosen do not
go high up enough the tree:-(
An interesting idea but I am not sure how feasible it will prove to be.
...
The efficiency issue (mapping an object-oriented model to a relational
implementation) occurs even with slightly object-oriented modeling
techniques like SNMP's SMI, and doesn't get substantially worse with
full-on object-oriented ones like GDMO. (I think the problem is
actually easier if one starts from the GDMO perspective.) Our
experience over 30 years ago was that it is tractable, but it
requires careful thought about the representation of fully distinguished
names and of values of types with complex syntax. If you think about
it in the right way, the depth of nesting doesn't really matter.
Randy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
