Some Good points on the discussion. I think I've heard several perceived issues with YANG scalability: - Validation times for large numbers of replicated instances, - User input of config data for the replicated instances - Overall size of aggregated models.
To me in standards the real value of YANG is a configuration model that describes the system. Its documentation "this is what it looks like and how you can use it". However, the nature of YANG allows it to be directly input to systems where it may hit the issues above. To address the issues: - Validation times can be handled by change where validation happens and pre-validation. - Templates address user input by capitalizing on items that will typically be set the same across instances. - The overall size of the YANG can be addressed by pruning the resulting tree and the branches for a particular implementation. What should do we do in IETF? A standard way of building templates perhaps could be valuable. Today groupings are designed to allow reuse of common items within a model. In a template, you have a slightly different goal - grouping items that are commonly set together and excluding items that are distinct per instance. In other words, it seems more logical to me to apply a template to the parts of the resulting tree. This means to me that templating mechanism might more easily be applied to the data input versus the schema itself. Cheers Don -----Original Message----- From: Robert Peschi (Nokia) <[email protected]> Sent: Thursday, July 25, 2024 10:13 AM To: Jürgen Schönwälder <[email protected]>; Robert Peschi (Nokia) <[email protected]> Cc: Italo Busi <[email protected]>; [email protected] Subject: [netmod] Re: Yang Scalability Hello Jürgen, Thanks for bringing this to discussion ! As we know, YANG standards are about defining modules including config data nodes each one with some expected functionality. The functionality supported in the device by some data node is defined by the data node description (often in combination with other data nodes). Obviously the worthiness of a function depends of the type of device and the network deployment. For instance a standardized YANG module supporting a given function, may be critically key for some deployment or totally worthless for some other ones. Useful ones will be included in the device YANG library, otherwise not. As long as there is no use case at all or zero added value for a specific function, I agree that standardization bodies should spend no effort to develop standards for it. I believe that data nodes supporting templates are no different: there may be network deployments where templates would be critically needed for the advantage they bring, while some other deployments would just not need them. From investigations that have been done, - it turns out that the access network industry at large faces important YANG scalability issues in large embedded systems - it appears that no off-the-shelf standard module can bring a solution to these issues. - there are strong indications that "template mechanisms", (which are indeed currently not standardized), can play a key role solving this issue. It looks to me that this could form a solid incentive for standardization bodies to investigate in more detail the concept of a "template mechanism" and what it implies at YANG level. Then, if the market sees virtue in it, I think that it would make sense to propose modules to standardization to make templates a deployable reality. > The question is whether it is possible now (starting in 2024) to > define a standard configuration, template mechanism that has a chance to be > implemented widely. Exactly ! This is what is at stake, and for which the access network industry has high hopes. Best regards, Robert -----Original Message----- From: Jürgen Schönwälder <[email protected]> Sent: Thursday, July 25, 2024 11:43 AM To: Robert Peschi (Nokia) <[email protected]> Cc: Italo Busi <[email protected]>; [email protected] Subject: [netmod] Re: Yang Scalability [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. On Thu, Jul 25, 2024 at 08:01:27AM +0000, Robert Peschi (Nokia) wrote: > > Using templates also means transmitting much less data from the client to the > device server, e.g. during a copy-config. Naturally, this would accordingly > reduce protocol transmission penalty. It also greatly reduces the footprint > of the running data store on the persistent memory of the device. > Configuation templates were left out of standardization many years ago. There was no interest to standardize configuration templates (perhaps companies needed ways to distinguish products or finding agreement on a standard template format was considered too hard and time consuming or ...). RFC 8342 (published March 2018) acknowledges the existence of configuration template mechanisms but also notes that they are proprietary: o Some implementations have proprietary mechanisms that allow clients to define configuration templates in <running>. These templates are expanded automatically by the system, and the resulting configuration is applied internally. The question is whether it is possible now (starting in 2024) to define a standard configuration template mechanism that has a chance to be implemented widely. See also the YANG next issue #18 (opened on 2017-03-17). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
