**Session Date/Time:** 06 Feb 2024 11:00

# [NMRG](../wg/nmrg.html)

## Summary

The NMRG meeting focused on an in-depth discussion of Network Digital Twin (NDT) concepts, architecture, and defining characteristics. Two presentations, one from Chen on updates to the `draft-chen-nmrg-network-digital-twin` and another from Chris on architectural clarity, stimulated a lively exchange. Key themes included the precise definition of NDT, the scope of its architecture, the distinction between the NDT core and broader control systems, and the implications of real-time requirements. While no formal decisions were made, the chairs will synthesize the discussion points and propose next steps for further development.

## Key Discussion Points

*   **NDT Definition and Scope:**
    *   The authors proposed standardizing on "Network Digital Twin" (NDT) and presented updated definitions, distinguishing a generic Digital Twin from an NDT in the context of networking.
    *   Three key characteristics were highlighted for NDTs: network observability, optimal policy generation with pre-verification, and virtual-real interaction mapping with closed-loop network automation.
    *   Four conceptual elements were described: Data, Model, Mapping, and Interface.
    *   The architectural scope of the NDT was clarified to focus on the "Twin Network" layer, with the "Real Network" and "Network Applications" layers being out of scope for the current draft.

*   **Architectural Interpretation and Clarity:**
    *   Concerns were raised regarding the architectural clarity of the current draft, specifically that Figure 2 implicitly depicts the NDT as a network controller (with intent input and control output), but its internal components only cover modeling and analytical capabilities. This blurring between the NDT and a full control system was seen to cause misinterpretation.
    *   The conceptual nature of Figure 1 was clarified by the authors, stating it represents elements and characteristics, not a strict architecture. However, its relationship and consistency with the architectural Figure 2 were questioned.
    *   A modular "layer cake" approach was proposed, advocating for defining the NDT as a core modeling/emulation engine, with use cases (e.g., sandboxing, optimization) being "super-architectures" built around this core. This approach aims to create a use-case-invariant definition of the NDT, providing a clearer architectural separation from broader management and control functions.
    *   There was a shared sentiment that the current architectural representation could lead to a "fuzzy" or use-case-dependent definition of NDT, which is not optimal for a robust architecture.

*   **Real-time and Bidirectional Interaction:**
    *   The draft authors stated that real-time and bidirectional interactions are not always universally required, differentiating "online NDT" (for continuous data exchange and real-time decisions) from "offline NDT" (for historical data analysis and planning).
    *   Participants suggested further clarification on these terms, potentially exploring alternatives like "active/passive" to better delineate the context.
    *   It was noted that while the core NDT architecture could be use-case invariant, real-time requirements do influence the design choices for the models and supporting systems (e.g., in terms of scalability, update speed, and performance).

*   **NDT's Role in Control Systems:**
    *   A significant part of the discussion revolved around whether the NDT *is* a control system or *enables* a control system. It was argued that if the NDT has the capacity to affect change in the network, it functions as an intelligent control system.
    *   The authors clarified that NDT is more of a closed-loop system with representation and decision-making abilities, rather than solely a controller.
    *   The need for flexibility was emphasized, allowing applications to use the NDT as a tool for simulation, emulation, or prediction, while retaining the option for applications to delegate control to the NDT or act as controllers themselves, using information from the NDT. The portion of control should be manageable through interfaces.

## Next Steps

The chairs will consolidate the main discussion points from this meeting and propose a plan for organizing future work. This proposal will be shared on the NMRG mailing list for group feedback and further discussion. Potential avenues for progression include:

*   **Dedicated Meetings:** Organizing a series of online calls specifically for the NDT topic to address outstanding issues and converge on architectural concepts.
*   **Issue Tracking:** Exploring the use of tools like GitHub for more formal tracking of issues and their resolutions related to the NDT draft.
*   **Document Strategy:** Considering whether the current comprehensive draft should be split into multiple documents to better manage the discussion of different facets (e.g., core NDT architecture, use cases, requirements).
*   **Prioritization:** Identifying and prioritizing specific investigation topics to systematically address the complexity of the NDT work.

The group aims to work collaboratively towards a clear and robust architectural description of Network Digital Twins, with the goal of enhancing the current draft by IETF 120 and promoting it for an adoption call.