[netmod] Re: Yang Scalability

Italo Busi <Italo.Busi@huawei.com> Wed, 24 July 2024 23:49 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AA2C1DA1EF; Wed, 24 Jul 2024 16:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.204
X-Spam-Level:
X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtgOZzoiHWkI; Wed, 24 Jul 2024 16:49:32 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A48C1EBF4E; Wed, 24 Jul 2024 16:49:31 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4WTrK33ZRJz6K8wy; Thu, 25 Jul 2024 07:47:03 +0800 (CST)
Received: from frapeml100006.china.huawei.com (unknown [7.182.85.201]) by mail.maildlp.com (Postfix) with ESMTPS id BAE32140594; Thu, 25 Jul 2024 07:49:28 +0800 (CST)
Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100006.china.huawei.com (7.182.85.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 25 Jul 2024 01:49:28 +0200
Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Thu, 25 Jul 2024 01:49:28 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: "Deepak Rajaram (Nokia)" <deepak.rajaram@nokia.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Yang Scalability
Thread-Index: Adrc2Wg3jNtQ1tF7RRKseYVve/FgFABR9iDw
Date: Wed, 24 Jul 2024 23:49:28 +0000
Message-ID: <850b8060a1fa4e04833ce09873aed2f3@huawei.com>
References: <AS4PR07MB8411551211BE217ACE4D9EBF81A92@AS4PR07MB8411.eurprd07.prod.outlook.com>
In-Reply-To: <AS4PR07MB8411551211BE217ACE4D9EBF81A92@AS4PR07MB8411.eurprd07.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.241.254]
Content-Type: multipart/alternative; boundary="_000_850b8060a1fa4e04833ce09873aed2f3huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: SF47CZP4FPFGKLRSGV7X4XO5WPPC76GA
X-Message-ID-Hash: SF47CZP4FPFGKLRSGV7X4XO5WPPC76GA
X-MailFrom: Italo.Busi@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "netconf@ietf.org" <netconf@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] Re: Yang Scalability
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vT3Iok6m234ceOWjA4dQf1rxrfo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>

Hi all,

I think that the YANG scalability issue should better addressed as a generic issue within the relevant IETF WGs

We have discovered similar issue also in IVY WG when working on the base network inventory model. You can see Appendix B of https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang and the conclusion was that this is mainly a protocol issue

I think that it would be also worthwhile understanding what issues are implementation specific (and outside the scope of standardization), a YANG modelling specific or a protocol specific.

The idea of using templates to avoid repeating the same set of information on multiple instances look a good idea and valid in general, as a YANG modelling specific issue. IMHO we should further explore what needs to be changed in existing models to support templates.

I have some concerns with the approach of re-defining the interface models under a different root. I think this would defeat one of the major advantages of re-using RFC8343 which is to be able to have a common model for managing all the interfaces of any system.

The scalability concerns here appears to me more a protocol specific issue (therefore I am cc-ing the Netconf WG for further feedbacks)

IMHO, there is a need to have a flexible definition of some filtering criteria (on the server side) when it is needed to retrieve only a limited set of instances on a list, pagination mechanisms (which is already a work in progress within Netconf WG) and/or a more efficient protocol encodings.

Italo

From: Deepak Rajaram (Nokia) <deepak.rajaram@nokia.com>
Sent: martedì 23 luglio 2024 01:52
To: netmod@ietf.org
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