[netmod] Re: Yang Scalability

Don Fedyk <dfedyk@labn.net> Thu, 25 July 2024 17:59 UTC

Return-Path: <dfedyk@labn.net>
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 E6855C1840DE for <netmod@ietfa.amsl.com>; Thu, 25 Jul 2024 10:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.com
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 gLZvVjTLG52R for <netmod@ietfa.amsl.com>; Thu, 25 Jul 2024 10:59:28 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2092.outbound.protection.outlook.com [40.107.244.92]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDBEC1DA2FD for <netmod@ietf.org>; Thu, 25 Jul 2024 10:59:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xyWGJTBLw1SDObLxYGXX/iTcdueXuXZlYBptGEAIQBw56/kerwMESFOSKQezdbgjqB9xPxVYK+2oJGyji+N9+mDLJ87aT3DHLiZRq9Zzb3eysz2WV55dE6IH9hWd9865ySwzDj6ZS60RbAv9muTzjzdipdn3WfksaonUiKXeRmBRC90G1mJdGybF+/l5TD3gQUqn9WW3q7/fSfqGzM3G5h3+bjgv5ISjmgEj3QT5/LkCpv6tFpq0krPvyCs1631/CJdayJDMzs+9ayD7yL2DANztJ3Cti/bOIcvvlTgMtQwW6A8AFtG9sQQFSsEdiIWGQcgFijhATErNsv5TEOCgEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KT8rsIXeKA6OyBJCmx4fuOcn3HMO/hoSTEOpWo40lZ4=; b=NIF44VXgrSZd74XnxE6XZNAKNU6GfvNM2LoPDuV1je+E5Q2ZnB+5d4t1Az6pYZAtbWwaFjrT9axWWWckwFucCQ9tiq9XD9BYGs2mo3VRUIT0qctXqWAWRtgc8ZTAH38hUcNLLSYATMwLoIbcQmlMCHiKFqbLN2mhUymoe08YW/P0WAf7exz/lYbnH0TwJGcYxjkX/TDcmA5USK4c1D87DUfk10QYAfq4k0wIfY/TPpUk1w5ziqkqcW2mCJXvOLOxATd6sT0TV6dfzODq4pMUGWTuKeZtvX9htWA3Zm3VKWASQ/G0E7eq3xaZNN3AqcErqem++Bg8yUa/fETFJNu54g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KT8rsIXeKA6OyBJCmx4fuOcn3HMO/hoSTEOpWo40lZ4=; b=SByfipzrsLj0nV4vEZ5BORir+4hWiqcAXz0Oaf2+o2AypUOuO/lAWlwUfH0bLU3J/Uo1ZWowYy5btvq1EJrWdsbEzrYDPUaTa1AslXUNUMCR68/NpFeY2J42cTiE6VDKWK9hGVtgHGIi0ci6XaqaylLW+SecZ5Qog8GN8PYQKdA=
Received: from PH7PR14MB5368.namprd14.prod.outlook.com (2603:10b6:510:133::11) by SJ0PR14MB5323.namprd14.prod.outlook.com (2603:10b6:a03:427::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7784.16; Thu, 25 Jul 2024 17:59:13 +0000
Received: from PH7PR14MB5368.namprd14.prod.outlook.com ([fe80::600e:5c3c:c961:2e91]) by PH7PR14MB5368.namprd14.prod.outlook.com ([fe80::600e:5c3c:c961:2e91%7]) with mapi id 15.20.7784.013; Thu, 25 Jul 2024 17:59:12 +0000
From: Don Fedyk <dfedyk@labn.net>
To: "Robert Peschi (Nokia)" <robert.peschi=40nokia.com@dmarc.ietf.org>, Jürgen Schönwälder <jschoenwaelder@constructor.university>
Thread-Topic: [netmod] Re: Yang Scalability
Thread-Index: Adrc2Wg3jNtQ1tF7RRKseYVve/FgFABR9iDwABCpOjAABMucAAAI2towAAX8XxA=
Date: Thu, 25 Jul 2024 17:59:12 +0000
Message-ID: <PH7PR14MB53681B1B2A6A2F41DD316DAEBBAB2@PH7PR14MB5368.namprd14.prod.outlook.com>
References: <AS4PR07MB8411551211BE217ACE4D9EBF81A92@AS4PR07MB8411.eurprd07.prod.outlook.com> <850b8060a1fa4e04833ce09873aed2f3@huawei.com> <VI1PR07MB1011581B2C59AE3F91F8D9DF1E1AB2@VI1PR07MB10115.eurprd07.prod.outlook.com> <ZqIeNgrzsCLVX911@alice.eecs.jacobs-university.de> <VI1PR07MB10115CD06B34B8E7870D64809E1AB2@VI1PR07MB10115.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB10115CD06B34B8E7870D64809E1AB2@VI1PR07MB10115.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=labn.net;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH7PR14MB5368:EE_|SJ0PR14MB5323:EE_
x-ms-office365-filtering-correlation-id: 6c0938d8-13be-4895-71cc-08dcacd37dbd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|4022899009|38070700018;
x-microsoft-antispam-message-info: /u91rq4T14lLeeh5F9wZEhJBhwBffEve0Kk/kuklkf6shfN48x2COr7NGF1/oEb9OJKwOQH9hPd8S+qBtdzMzT5ezzfAjXFG9kbDn/zdFbeccGvzGMbHd5qTwYzXSvFtzhAZnFlTN9Cmb0aQ+ESBbKJVYFubu83QuC8pV9CE+mAK3JXPbq9C/rDwRplVey/sIP3v4XVmuNjdbiwZ+H4VdB0cSnCbn+CAAr/OzjYD044/2ZMwU3qsVLEdocksja9+5yG9KViUFrBH+pu7tWtwjBGqkJhILEKam1+IubP447YGJUtoUIIkWpIWTBliPAA+H4IwXytz3GWc/3Tdd+kPVsAtuSSKfDYmg6Uz8JSlib0eyy09guGx2seOiJ3b4wchnsTMSJguKnM9+DuZ2ssg5eGOSzX9T6kVNgoNI4yd19gGShvnBov+SybRIrJg3daKEvrmHFprVeXi/4eEXQ9TP2rKFGw5pGFVZ6eaG7yGQSoLJjZrb2V0O+IgbV4EYwZ4R08qOdATCQDeViDG7UCkyTQ9IERzV0EDmrrBmCQer1V33EuEmEK+DVDJEFXkybg2giRCeUKACEj/8FSRzItg65C4Gy31hVtZgMwcPCeiKFGad23DFFPK1vKh0awmBRPhlp24OYfoNaCCBLFtiF1wF4QrpSPRHd9TNTMwg+2h/OaR8swRbE0sMeg80My2JcFppVenroJCqMJiNuv+v4b6kerkvJE5iPzMU8X1CWrWdrzToOdgBl+qhOYU5WtxO4hZBarc0cnNIMIbrjWJlkRD/r/LrNYZ+A/SRT4wSS7LH6gX8ngNJYNgKNlnGMZEjXq4ajC6aVx1M1nYa7ma7/hR89HMTYezHk8oPLGjEBbep6+dj4O2HeQX+Z8hNyxbDRLOfmrks7iMYBKq9VaXpPn560uSqtcy6RLa0uVZJbN06jOx9EVKq9PMBbbBZSYV/8nQiLkdXiVcyuHi8Q+4bqqQ31RxLE/4DcpVyzMWgfDD7TB2WXdYcGm8wGI5PKSRQPerZ69pICl4H7M2/ZSrtcmaJDxSbEvId3NYGx/e4tVypz3B+9sAyMRkRaJ38SKVeTQOba88ExGL31KIKLhoVq5J93Q2U6waIbFkYIEVx6Z+DOnPAeQW/kCGdITdboLYpDHw2+ejiLPAimBnXjUPi2CjLPCeKe8hfcz/x1psfAKnKUJcv1XS9Mwf6FXEwBs2q+yXzRfi7lzUcn7AewH2vbJed8PnftxGQaBRMiwl8dYZs8TsRlZW++nlEv2lNwVZE8Ppn7mMQpMJmAkL7rqhx9MRb4nuvvCZ9F0vv3NWpxyDYoCiGgXzUs3wv0tTJqUj4PmLD0A0OUf/2J2gRXg9GWdHmSp8De+N5VdAgaDMeua1KJM=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH7PR14MB5368.namprd14.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(4022899009)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: nbRMamIGmZ1IRaOIPiTGQgTbPTMKE9XdZYV1jHuj30G4jjoKahUeW3z1dwOtNN204SucSnccEcyr1fJNi4nwvAg1nnwrpQBOtaK7j4UQiF29aKXsYM+QwuLQ485uQ0CrSdbdMk4OipugwdKJ3fw0vsB6Ld5Y8/TAw/Cldv5hsWGCJ1w4INZA6eeGpfhj3YD5FMktDzpKDwqfvQXyST0809lwvqVJnHotYqcKcDqAJ87z1JPgRnU0n5mKxcKoPjKnyQqZdjpV7vc3olS4IX2KjiIPtjAyCbjRTAf79Y8LFOeLjdgugIk65odqPoErOObC0uiCuI3R11yvPwMuJeLXB96EeCEgJiRe3K/OzAqq90ZXfy99YAs7eMFrsxRI9pUrFGdAfy1tpyaXmJtR32Pj2Sp3wdhYpEsYNuBNIkh2TOE1/Vx67cvOzSwu0Lz+/itU5c8uWOqi7XMnpc3XWEZD+lqaIUFbFtCwYqLasfTn2bOcwAPx/xt16JBa83wbI0vfdXocd+m1BGS99P+pLo3WOtMJrKdNBkCixsw0l/kp68c42b3oGYS2Ap3Wa+oTkiZ00E4CqUyXTBBdqQblKSjnSKpyMz1JtM7RvYYjroWopAkWlvwRUgyG1IHy6QMrE76b/8iCGcTiznWJljXy0/Bo0onXEYX0ur3PSbZvvvUvI1TDZgCQknu9abvziaDW7Sxer2GryA8bmjVCakDs7++EJZBtHyvzNqLtLZJ51Hh0YFsPSBgm6B6Hn+5K5CEN6pjbnn2qxvAEk1m+06rkX7jyx8whE3yHjJmF3hg24GMMbI8INJ9ZmpqfTwkXAQnEmxy6H/6p3XWf3Y72YkDQiuFt5VODzb7UZ28x4Y9GfKtifQteuprayWfBSeoCzVz2nHVpdC1mlDGz7CXUbpOlfudbf0JtQN/+85G0zYBIDtsX4+TED9YORsfQDiUR+Dl8WDKB8s9cVVMh4XjDD5njZ57yewtNBbX0KNUHWt9bk+VZw1EuLyrnQTD+DJ3GYEF5KsLja3v25yeP2OCjfScuGCgev+fXUZhfzTQwpKvYUj5gv1CKmCY12+GQoEV2XsOdwTcnohRyK4y3zZKNOZS8YSCs2FR7NdzaDHGzcO7laCQEpHej6HR2HAC+g0DR/Y6H45mLl5rIhVF1DENRl+FswkxwamPRVMvroMMQTput4dmgP/ocibXc0EybAn78mTSYRbPcnWeff35SQvEk2DBqxL1j0NlmfNx/qDD0cDBPgizMYfQpt89n3rC+UyuACd3XeAUqOQwNM7rJpu1Nk30XT2TFqL6GToY5r67a5H1ioWitfeJ1/JoEO9Z/MVssAMfN4rvJ/C3cCBq+qTT09eUeMDGwCRtA89vlqnO+Gqs8UbsJ1+0CnAu/mpIejY2qBRSnU5vJxyvOQTF5x3FTwohJatUWFMbVxMPr5bvee4Db8ZU5LCKhQdFbRFbB69cqFRxErCjN2wbr4tzFQ4YWkNLl0QKmBSR0LigHTH5XIRllhDq8f90KCllL2+GX4Dii4dkQik85u8GCszTRa35lEYjkqYBDoGcQuyRqM/IOm9RQH2inL4mig650PQke0um6nKRcXKov85uyupPDQSgXHC3bpcrqoNmiGOh5bYbw2feDJMBJuXA=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: labn.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH7PR14MB5368.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c0938d8-13be-4895-71cc-08dcacd37dbd
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2024 17:59:12.7250 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xuTvCtik2deiJPEPent8utILr+ZTLD1aPVC7MDHXDWosfuQZeFacCNOqmZfVScHhktjFaMSeiL/utzC46mQjQA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR14MB5323
Message-ID-Hash: 2SIWMNS34A324WOMV6YCPYBT6EBEU3KS
X-Message-ID-Hash: 2SIWMNS34A324WOMV6YCPYBT6EBEU3KS
X-MailFrom: dfedyk@labn.net
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: Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org>, "netmod@ietf.org" <netmod@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/rpcShTlVgWvz4ZTtNeeA9mimPvI>
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>

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) <robert.peschi=40nokia.com@dmarc.ietf.org> 
Sent: Thursday, July 25, 2024 10:13 AM
To: Jürgen Schönwälder <jschoenwaelder@constructor.university>; Robert Peschi (Nokia) <robert.peschi=40nokia.com@dmarc.ietf.org>
Cc: Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org>; netmod@ietf.org
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 <jschoenwaelder@constructor.university>
Sent: Thursday, July 25, 2024 11:43 AM
To: Robert Peschi (Nokia) <robert.peschi=40nokia.com@dmarc.ietf.org>
Cc: Italo Busi <Italo.Busi=40huawei.com@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-leave@ietf.org _______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-leave@ietf.org