[NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

Christopher Janz <christopher.janz@huawei.com> Thu, 11 December 2025 16:23 UTC

Return-Path: <christopher.janz@huawei.com>
X-Original-To: nmop@mail2.ietf.org
Delivered-To: nmop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 93AB4992EA00; Thu, 11 Dec 2025 08:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2eu-3MlL35z; Thu, 11 Dec 2025 08:23:09 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 1BED6992E9F4; Thu, 11 Dec 2025 08:23:09 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4dRyYS2kLWzHnH61; Fri, 12 Dec 2025 00:22:52 +0800 (CST)
Received: from lhrpeml500010.china.huawei.com (unknown [7.191.174.240]) by mail.maildlp.com (Postfix) with ESMTPS id 13A424056B; Fri, 12 Dec 2025 00:23:06 +0800 (CST)
Received: from ytopeml500001.china.huawei.com (7.184.16.223) by lhrpeml500010.china.huawei.com (7.191.174.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.39; Thu, 11 Dec 2025 16:23:05 +0000
Received: from ytopeml100002.china.huawei.com (7.184.16.70) by ytopeml500001.china.huawei.com (7.184.16.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 11 Dec 2025 11:23:04 -0500
Received: from ytopeml100002.china.huawei.com ([7.184.16.70]) by ytopeml100002.china.huawei.com ([7.184.16.70]) with mapi id 15.01.2507.061; Thu, 11 Dec 2025 11:23:04 -0500
From: Christopher Janz <christopher.janz@huawei.com>
To: Olga Havel <olga.havel=40huawei.com@dmarc.ietf.org>, "draft-ietf-nmop-simap-concept@ietf.org" <draft-ietf-nmop-simap-concept@ietf.org>
Thread-Topic: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)
Thread-Index: AQHcYtCGnB/TXhwTdEat+oNX69hbyLUOcmXAgA6LQoD//7C3kA==
Date: Thu, 11 Dec 2025 16:23:04 +0000
Message-ID: <aa95f4169ee54b6c95b032ea7d9bd219@huawei.com>
References: <176340967570.870530.1378056747043023396@dt-datatracker-5bd94c585b-wk4l4> <CA+nRKkrghMsd1+8DMonhYaOtq=mE3JqnPM8oyDuwuB+S-x3Gig@mail.gmail.com> <6452ca7de1a5431b8d505622c30a535e@huawei.com> <4dee813b410f4bc6b774a2a07c8de6b9@huawei.com>
In-Reply-To: <4dee813b410f4bc6b774a2a07c8de6b9@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.211.34]
Content-Type: multipart/alternative; boundary="_000_aa95f4169ee54b6c95b032ea7d9bd219huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: SPGTPBCYIJM2OL5SQ7Y2ULI3XEWR2FEK
X-Message-ID-Hash: SPGTPBCYIJM2OL5SQ7Y2ULI3XEWR2FEK
X-MailFrom: christopher.janz@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "nmop-chairs@ietf.org" <nmop-chairs@ietf.org>, "nmop@ietf.org" <nmop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)
List-Id: "Network Management Operations (NMOP) Working Group" <nmop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nmop/NbPDCU1OLzFsLEQQrUDy2GPhDbQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nmop>
List-Help: <mailto:nmop-request@ietf.org?subject=help>
List-Owner: <mailto:nmop-owner@ietf.org>
List-Post: <mailto:nmop@ietf.org>
List-Subscribe: <mailto:nmop-join@ietf.org>
List-Unsubscribe: <mailto:nmop-leave@ietf.org>

Thanks Olga, appreciate and am familiar with the history. At the end of the day, what’s important in the document is clarity. Can be improved I think even constraining any rewording to the NDT clause. Will take a crack next week.

Best


From: Olga Havel <olga.havel=40huawei.com@dmarc.ietf.org>
Sent: Thursday, December 11, 2025 11:04 AM
To: Christopher Janz <christopher.janz@huawei.com>; draft-ietf-nmop-simap-concept@ietf.org
Cc: nmop-chairs@ietf.org; nmop@ietf.org
Subject: RE: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

Dear Chris,

Thanks for the review and the feedback. I opened the issue 130 https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues/130 for the NDT Use Case.

Just some history on why we have NDT use case separate from other use cases:

  *   It was clear to everyone that NDT will need to support most if not all the use cases
  *   Nevertheless, some operators wanted to ensure that SIMAP is the data model that can be used outside of the NDT for the existing operations use cases
  *   NDT is in IRTF and we are in IETF, so we agreed to include NDT at the end as a separate use case.
  *   There was a specific comment about network emulation use case versus NDT use case from Reshad during the shepherd’s review, so we added the section you mentioned to clarify that NDT includes emulation use case, but other things as well .Please refer to the NMOP thread ‘Comments on draft-ietf-nmop-simap-concept-06 (Section 3)’ for the email exchange.

It would be great if you want to suggest an alternative phrasing, it would really help. But please just keep in mind that the split between the NDT use cases and other use cases was intentional and driven by operators.

Best Regards,
Olga


From: Christopher Janz <christopher.janz=40huawei.com@dmarc.ietf.org<mailto:christopher.janz=40huawei.com@dmarc.ietf.org>>
Sent: Tuesday, December 2, 2025 3:50 PM
To: draft-ietf-nmop-simap-concept@ietf.org<mailto:draft-ietf-nmop-simap-concept@ietf.org>
Cc: nmop-chairs@ietf.org<mailto:nmop-chairs@ietf.org>; nmop@ietf.org<mailto:nmop@ietf.org>
Subject: RE: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

Hi all – I had wanted to offer a comment regarding clause 6.10 (NDT) and Dan’s note is a good reminder and pivot.

This final paragraph of the clause is rather awkward, though I understand it may come fairly directly from (hopefully an older version?) of the NDT C&A ID:


“While network emulation (Section 3.8) can be a component within an
   NDT, the NDT itself is a broader construct that integrates multiple
   modeling techniques, including emulation, simulation, and analytics,
   to support intelligent network operations.  NDT uses network
   emulation and includes network emulation use case, but it also
   interacts with the real network to support intelligent operations,
   including predictive analytics, intent verification, and full
   lifecycle management of network and services.”

The final sentence is the problematic one. Such a conception of an NDT is vague to the point of being a Rorschach test: it’s anything you want, up to and including the entirety of an automated network operations system. And that isn’t a particularly useful conception.

I think at least the bulk of the NDT C&A ID now reflects a clearer and more bounded conception, one that is aligned with e.g. ESTI ZSM 018:

The data foundation of an NDT is essentially the one created by SIMAP and its adjuncts, per Dan’s description below: “a multi-layer view of the network that ties services to the underlying infrastructure, connects to other models (inventory, observability, SAIN, SAP, etc.), and supports … live … views”. In other words, a data foundation sufficient to create a point-in-time virtual replica, directly supporting e.g. “visualization” - both current and historical, assuming appropriate data handling.

An NDT properly speaking supports scenario-based assessment: what-if analysis. This is needed for essentially all NDT use cases beyond visualization. A change in resources, or their connections, their use, etc. is posited, and ramifications - from changes to use-of-resource maps to predicted service performances, traffic characteristics, security implications, energy consumption, etc. – are assessed. Such assessment is enabled by included/used data models, emulation and behavioural models, etc., as deemed useful to operational decision-making. It is this NDT level/function that finds its place in an automated operations context.

But the extension of the NDT conceptual perimeter beyond that point, in arbitrary ways up to and including fully subsuming the entirety of network and service operations and management, does not promote clarity and should no longer be suggested by the NDT C&A ID (i.e., AFAIK it is no longer suggested). The current description is simply that information generated by NDTs, specifically by scenario-based assessment, may be directly “connected” to other operations and management system components, including decision-making components within closed loops.

I can suggest an alternative phrasing in clause 6.10 if that would be useful. But the bigger issue is that in the above conception, clauses 3.3 through 3.7 all actually represent NDT use cases, because they involve scenario-based assessment and not just SIMAP and its connected models.  Similarly, clause 3.8 describes functionality involved in moving beyond SIMAP(+) to scenario-based assessment.

Best

Chris


From: Dan Voyer IETF <danvoyerwork@gmail.com<mailto:danvoyerwork@gmail.com>>
Sent: Monday, December 1, 2025 9:34 AM
To: Reshad Rahman <reshad@yahoo.com<mailto:reshad@yahoo.com>>
Cc: draft-ietf-nmop-simap-concept@ietf.org<mailto:draft-ietf-nmop-simap-concept@ietf.org>; nmop-chairs@ietf.org<mailto:nmop-chairs@ietf.org>; nmop@ietf.org<mailto:nmop@ietf.org>
Subject: [NMOP] Re: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

Hi WG and Authors,

This is important work and I support the document.
SIMAP’s role is clear to me: it’s a multi-layer view of the network that ties services to the underlying infrastructure, connects to other models (inventory, observability, SAIN, SAP, etc.), and supports both live and simulated views.”


Thanks,
Dan

On Mon, Nov 17, 2025 at 3:01 PM Reshad Rahman via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:

Subject: WG Last Call: draft-ietf-nmop-simap-concept-07 (Ends 2025-12-01)

This message starts a 2-week WG Last Call for this document.

Abstract:
   This document defines the concept of Service & Infrastructure Maps
   (SIMAP) and identifies a set of SIMAP requirements and use cases.
   The SIMAP was previously known as Digital Map.

   The document intends to be used as a reference for the assessment of
   the various topology modules to meet SIMAP requirements.

File can be retrieved from:
https://datatracker.ietf.org/doc/draft-ietf-nmop-simap-concept/

Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping nmop@ietf.org<mailto:nmop@ietf.org>
in copy. Objections should be motivated and suggestions to resolve them are
highly appreciated.

Authors, and WG participants in general, are reminded again of the
Intellectual Property Rights (IPR) disclosure obligations described in BCP 79
[1]. Appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
any. Sanctions available for application to violators of IETF IPR Policy can
be found at [3].

Thank you.

[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/



--
Nmop mailing list -- nmop@ietf.org<mailto:nmop@ietf.org>
To unsubscribe send an email to nmop-leave@ietf.org<mailto:nmop-leave@ietf.org>