IETF Logo Mail Archive

[netmod] Re: Yang Scalability

Carsten Bormann <cabo@tzi.org> Thu, 25 July 2024 21:23 UTC

Return-Path: <cabo@tzi.org>
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 E7F38C14F6BA for <netmod@ietfa.amsl.com>; Thu, 25 Jul 2024 14:23:58 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 zne0HCctENMY for <netmod@ietfa.amsl.com>; Thu, 25 Jul 2024 14:23:57 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C60C14F694 for <netmod@ietf.org>; Thu, 25 Jul 2024 14:23:57 -0700 (PDT)
Received: from smtpclient.apple (p5dc5d6c5.dip0.t-ipconnect.de [93.197.214.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4WVP5R4gtQzDCbL; Thu, 25 Jul 2024 23:23:55 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <VI1PR07MB101154EFE521F296E0D156FE0E1AB2@VI1PR07MB10115.eurprd07.prod.outlook.com>
Date: Thu, 25 Jul 2024 23:23:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <95992D74-5319-4C61-AD42-58A8B3DF9E74@tzi.org>
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> <B205ECAF-7537-4F78-9850-64C9789D81CE@tzi.org> <VI1PR07MB101154EFE521F296E0D156FE0E1AB2@VI1PR07MB10115.eurprd07.prod.outlook.com>
To: "Robert Peschi (Nokia)" <robert.peschi@nokia.com>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: ZDUQ34K7KRHNSN4WZJHVGX7FDGUJMMOR
X-Message-ID-Hash: ZDUQ34K7KRHNSN4WZJHVGX7FDGUJMMOR
X-MailFrom: cabo@tzi.org
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: Jürgen Schönwälder <jschoenwaelder@constructor.university>, Italo Busi <Italo.Busi@huawei.com>, "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/M4jmAS0ZcEseWy4ZTk3hV1O49Wc>
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>

On 25. Jul 2024, at 16:59, Robert Peschi (Nokia) <robert.peschi@nokia.com> wrote:
> 
> The actual data nodes of an instance to be configured are internally generated from a “photocopy” of the data nodes of an original configuration (template, green dots on slide 12) that is customized here and there (cf blue dots on slide 12) for this specific instance. The gain in the running data store size is that
>     • only one copy of the many green dots of one (or say, a few) templates need to be persistently configured and stored on the device
>     • only a few blue dots need to be persistently configured and stored on the device, different for each instance (many ones)

So a mental model of “default-value + merge-patch where needed” (RFC 7396) would work?

Grüße, Carsten

v2.26.15 | Report a Bug | By Email | System Status