Hi Jan, Thanks and appreciate your inputs. The 30k+ interfaces is an indication of just the number of physical and logical interfaces and not the entire stack and associated services, ie: the actual datastore could be much bigger and traversing/validating such a datastore will be challenging, not to forget in an embedded environment, we will be limited by the hardware capabilities/computational power as well.
i do agree that dealing with any scalability/performance aspects could of course involve different techniques including effective implementation, caching, efficient data retrieval/storage etc.. But the focus is also on modular schema design which would complement and help in re-usablity and refinements. It makes a lot of sense to approach configuration of repetitive data with templates/profiles(reduced datastore size), i am not aware of any available standard option to templatise standard models. It could be a first objective to create a draft to clarify how templates could be used in YANG. The usage of templates, while also providing flexibility to customize certain nodes for specific instances leads to a requirement to handle defaults and mandatories more carefully as it might lead to a silent failure. While custom models could be designed, I believe it will positively help if such flexibility is also available with standard modules which has indeed proved to be effective for various other use cases. So the focus is on better modular design in exiting models rather than the yang language/implementation. Regards, Deepak From: Jan Lindblad (jlindbla) <[email protected]> Sent: Tuesday, July 23, 2024 4:19 PM To: Deepak Rajaram (Nokia) <[email protected]>; [email protected] Subject: Re: Yang Scalability 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. Deepak, Thank you for your presentation yesterday. Even if it was severely compressed, I think the basic message got across, and I browsed through your presentation. Scaling is certainly an interesting topic for many of us. Scaling any solution will always require some forethought, care and iteration, but I would not consider 30k interfaces or 30k of any kind of object as remarkable under YANG-based management. Lots of operators are managing such networks today using YANG-based tools, and some would consider 30k outright tiny as they are dealing with millions of objects under control by a single YANG-based server. Obviously, it makes sense to model things using templates to capture the similarity between large groups of objects, if that is a common situation with your use cases. It may also make sense to organize your objects into hierarchies for easier navigation and separation of concerns. If the ietf-interfaces module doesn’t do that the way you need, you (or BBF) is free to build your own independent or augmenting model that is better suited to your goals. YANG-mount and similar techniques may or may not be needed or ideal for this. On the topic of validation using must- and when-expressions, you state that “For very large data stores, performance collapses far below practical levels !” I would argue that this is an implementation issue rather than something that should concern the NETMOD WG. The YANG language allows you to describe the constraints of your data structure, but it does not prescribe any particular approach to how it should be validated. Many implementations will use an XPath evaluation engine to validate these expressions, and that is fine and great in most cases. But as you say, when data sets grow, naïve XPath evaluation will often not scale. For those cases, you will need to implement the validation in a smarter way in your server. I’d be happy to join a discussion with you on this topic. Either privately or as an IETF side meeting, or whatever, if others are interested. In that discussion, I think we should rephrase the vague term “YANG scalability”, which is used a lot in the presentation, with something that clarifies if the issue is about i) The YANG language itself ii) Specific YANG modules (by NETMOD, other IETF WGs, other SDOs or vendors) iii) Implementations of those YANG-based management interfaces Thanks for bringing up this topic. Best Regards, /jan From: Deepak Rajaram (Nokia) <[email protected]<mailto:[email protected]>> Date: Tuesday, 23 July 2024 at 10:53 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [netmod] Yang Scalability Dear all Thanks for the opportunity to present on yang scalability, this is a follow-up after having briefly introduced the real-life YANG scalability and performance challenges layed out in the Broadband Forum liaison. I would encourage NETMOD participants to go over the slides in the meeting materials section of ietf-120/netmod. slides-120-netmod-10-bbf-liaison-on-management-at-scale-projects<https://datatracker.ietf.org/meeting/120/materials/slides-120-netmod-10-bbf-liaison-on-management-at-scale-projects> Short summary: Based on studies conducted by several Broadband Forum meeting participants, it is found that existing standard YANG implementations do not scale up to configurations that contain a very high number of interfaces; for instance in a Passive Optical Network, a single Optical Line Termination (OLT) can easily surpass 30.000 interfaces (i.e. a few per Optical Network Unit). This is a real challenge for network deployments. We are seeing scaling challenges in terms of datastore sizes and datastore manipulations (slow configuration, slow data retrieval). While a PON network is taken as an example, it’s more than likely this scaling challenge will find its way to other parts of networks as products and industry evolves. We believe this is something NETMOD needs to address with urgency. As a result of the study, to address such scalability issues, few salient points were analyzed and translated into following requirements: 1. “Clustering” data nodes 2. Reducing datastore size by using shared profiles 3. Reducing datastore size by using “templates” Existing ietf-schema-mount (RFC8528<https://www.rfc-editor.org/rfc/rfc8528>) and the new draft of full: embed<https://datatracker.ietf.org/doc/draft-jouqui-netmod-yang-full-include/> definitely prove to be useful for certain aspects, including reusability of modules as-is. Still, in their current form they fall short for overcoming the scalability issues, which we believe can be mitigated using “templates” and profiles. I expect a more detailed ID will be brought forward explaining the proposal of templates/profiles. In anticipation of this ID, I would welcome the group to go over the slides for more details on the concepts. Any feedback/suggestions are more than welcome 😊 Regards Deepak
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
