[OPSAWG] How many "digital twins" every single network should have? Who would map between "twins"?
Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 05 December 2022 18:19 UTC
Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81A3C14F746; Mon, 5 Dec 2022 10:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 F92jGacr0GeS; Mon, 5 Dec 2022 10:19:14 -0800 (PST)
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 253BAC14CF0F; Mon, 5 Dec 2022 10:19:14 -0800 (PST)
Received: from frapeml100002.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NQsHW71F3z689SB; Tue, 6 Dec 2022 02:18:31 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by frapeml100002.china.huawei.com (7.182.85.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Mon, 5 Dec 2022 19:19:11 +0100
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.034; Mon, 5 Dec 2022 21:19:11 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
CC: Xipengxiao <xipengxiao@huawei.com>, Paolo Volpato <paolo.volpato@huawei.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Thread-Topic: How many "digital twins" every single network should have? Who would map between "twins"?
Thread-Index: AdkI0S8BpgMaS1j9Q7GLr3uBhdtxcQ==
Date: Mon, 05 Dec 2022 18:19:11 +0000
Message-ID: <8785e8d95b7d4218af475a7ff9e44ccb@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.195.33.130]
Content-Type: multipart/alternative; boundary="_000_8785e8d95b7d4218af475a7ff9e44ccbhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/fDO0ZlW5Wc7WZhd0odBDJHd-XPE>
Subject: [OPSAWG] How many "digital twins" every single network should have? Who would map between "twins"?
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2022 18:19:20 -0000
Hi Automation Gurus, YANG modules may be treated like a "digital twin" of the network with different resolution/accuracy (depending on Module details). It looks like RFC 8969 is discussing that different YANG models (for different layers or functions) of the same network should be the clarification of the same "digital twin". Below are some excerpts from RFC 8969 that make me believe in the common Data Model after all YANG modules clarification for the same network. But comparing RFC 8299 (L3SM) with RFC 9182 (L3NM) I conclude that "Data Models" are different (could not be automatically mapped). Yet they should describe/represent the same network. It is evident in this situation that a big job for the vendor is needed to *map* Data Model of L3SM to the Data Model of L3NM. It is not just a cost/time, additionally, it is a big source of interoperability issues. Engineers from different vendors would never map it in the same way. I could pose similar examples for the other RFCs (like L2SM and L2NM, and many more). Why is IETF not following RFC 8969? It looks pretty evident. Why "Data Models" for the same network are not automatically mapped?!? It was logical to define initially top-level approximation for the network (the service model is probably the loosest one), Then extend Data Model (augment in RFC 7950 terminology) to the network model and so on (continue to clarify more details). As it is rightfully stated in RFC 8969: only a top-down approach permits resolving the challenge of "closed loop control". I would add "in the multivendor environment". If I understand right (not sure): it was the primary idea of OpenConfig to have the common Data Model for Configuration and Assurance at every layer (the unified "Digital twin" for the network). The value of hundreds of already developed YANG modules looks questionable because vendor mapping by different vendors between functional and layered YANG modules could produce m*n^2 permutations. It may not permit interoperability in the multi-vendor environment. I could imagine some reasons why it may not be possible in some cases but the general rule should be to always use "augment" of the parent YANG model. RFC 8969 excerpts proving the value of the common, automatically mapped "digital twin": * Network models can be derived from service models and used to provision, monitor, and instantiate the service. * To operate a service, the settings of the parameters in the device models are derived from service models and/or network models. * In addition, the operational state including configuration that is in effect together with statistics should be exposed to upper layers to provide better network visibility and assess to what extent the derived low-level modules are consistent with the upper-level inputs. * In addition, the operational state including configuration that is in effect together with statistics should be exposed to upper layers to provide better network visibility and assess to what extent the derived low-level modules are consistent with the upper-level inputs. Eduard
- [OPSAWG] How many "digital twins" every single ne… Vasilenko Eduard
- Re: [OPSAWG] [netmod] How many "digital twins" ev… Jan Lindblad
- Re: [OPSAWG] [netmod] How many "digital twins" ev… Vasilenko Eduard
- Re: [OPSAWG] [netmod] How many "digital twins" ev… Qin Wu
- Re: [OPSAWG] [netmod] How many "digital twins" ev… tom petch
- Re: [OPSAWG] [netmod] How many "digital twins" ev… Qin Wu