Re: [OPSAWG] [netmod] How many "digital twins" every single network should have? Who would map between "twins"?

Jan Lindblad <janl@tail-f.com> Wed, 07 December 2022 17:35 UTC

Return-Path: <janl@tail-f.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 8F8DCC1522B2; Wed, 7 Dec 2022 09:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 UI1DRpt4efl4; Wed, 7 Dec 2022 09:35:32 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id ACE9AC1522B6; Wed, 7 Dec 2022 09:35:31 -0800 (PST)
Received: from smtpclient.apple (unknown [173.38.220.53]) by mail.tail-f.com (Postfix) with ESMTPSA id 672C41AE0332; Wed, 7 Dec 2022 18:35:28 +0100 (CET)
From: Jan Lindblad <janl@tail-f.com>
Message-Id: <748527DD-FD9D-4CA4-8BE3-7E8EF3A7DDAC@tail-f.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_08ABF23E-8554-4270-80CB-5C795BF226DF"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Wed, 07 Dec 2022 18:35:27 +0100
In-Reply-To: <8785e8d95b7d4218af475a7ff9e44ccb@huawei.com>
Cc: "opsawg@ietf.org" <opsawg@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, Paolo Volpato <paolo.volpato@huawei.com>, Xipengxiao <xipengxiao@huawei.com>
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
References: <8785e8d95b7d4218af475a7ff9e44ccb@huawei.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/1x-fjmQqlr5KXLDr6KZzZPl4aqs>
Subject: Re: [OPSAWG] [netmod] 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: Wed, 07 Dec 2022 17:35:37 -0000

Hi Eduard,

> 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.

That is right. There are multiple attempts at modeling the use cases at each level of the management stack. This is not unlike how standards develop in other areas. Initially, and sometimes even after a long time, there are often competing standards. Sometimes even from within the same SDO.

> 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.

I think you should be careful with the word "vendor", here as we're talking about an entire vendor eco-system. It is not typical that a router product would contain this mapping, but you are right that an NMS or OSS product from some vendor might. The mapping from network use cases to network device configuration is happening widely today, and a fair portion of all that is using YANG in some way.

> 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).

Of course. Just like two router vendors would not implement a given IETF routing YANG model the same way, NMS/OSS vendors and any service providers that choose to do this on their own, will have the same freedom of implementation at their level. This freedom does not remove the value of standardized service YANG models in any way.

> Why is IETF not following RFC 8969? It looks pretty evident. Why “Data Models” for the same network are not automatically mapped?!?

How could they be automatically mapped? Such mappings necessarily depend on use case, network circumstances and operator traditions/preferences, so I can't see any one-size-fits-all mapping here. Sure, you can make one mapping and declare it the one and only. But others may not agree and prefer to go with their own mapping.

> 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.

We certainly experience the concrete value of the many thousands of device level YANG modules out there when implementing NMS/OSS type of functionality. Anyone in that business should come prepared to navigate combinatorial explosions, but I can't say I have seen any traces of the specific m*n^2 permutations you speak of above, relating to combinations of device level YANGs and service level YANGs.
 
> 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.

I'm afraid I can't decipher this statement. Feel free to elaborate.

Best Regards,
/jan