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 <jschoenwaelder@constructor.university> Sent: Thursday, July 25, 2024 11:43 AM To: Robert Peschi (Nokia) <robert.peschi=40nokia....@dmarc.ietf.org> Cc: Italo Busi <Italo.Busi=40huawei....@dmarc.ietf.org>; netmod@ietf.org Subject: [netmod] Re: Yang Scalability [You don't often get email from jschoenwaelder@constructor.university. 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 -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
