NMRG Online Meeting February 2024

• Tuesday, 6 February 2024, 06:00 EST / 12:00 CET / 19:00 CST
• https://datatracker.ietf.org/meeting/interim-2024-nmrg-01/sessions/nmrg.ics

Contacts:
- RG Chairs
- Laurent Ciavaglia <laurent.ciavaglia@nokia.com>
- Jérôme François <jerome.francois@uni.lu>
- RG Secretaries
- Jéferson Campos Nobre <jcnobre@inf.ufrgs.br>
- Pedro Martinez-Julia <pedromj@gmail.com>

Useful links:
- Materials: https://datatracker.ietf.org/meeting/interim-2024-nmrg-01/session/nmrg
- Meetecho: https://meetings.conf.meetecho.com/interim/?group=985f263f-66bf-4c13-a0c7-2b54222eab7f
- Notes: https://notes.ietf.org/notes-nmrg-20240206

Agenda:

Main topic of the meeting: Network Digital Twin (NDT)

• 12:00 CET: Introduction

• 12:10 CET: NDT architecture and defining characteristics

  • Short presentations & discussion

    • NDT: Concepts and Reference Architecture - open discussion, Cheng Zhou

      • 3: update definition DTN -> NDT

      • 3: key characteristics: more than a network simulator or emulation platform

        • observability, policy generation and verification, interaction mapping and closed-loop

      • Christopher Janz: Slide 3: the functional definition here of network digital twin is much larger in scope than the cited definition of digital twin generically

      • Thierry Coupaye: why not using a well known definition of DT such as the one by the Digital Twin Consortium ?

        • Qin Wu: @coupaye, the idea is apply digital twin to the network, not completely align

      • Daniel King: Slide 2: "The Scope of NDT" for "real-time" interaction. "real-time" typically refers to processes or events that are perceived to occur instantaneously or notable perceptible delay. Does this mean NDT might not be used for planning applications, or sensitivity analysis where a response might take minutes or hours?

      • Qin Wu: I think network planning phase can be covered. Agree the real time needs to be clarified.
      • Christopher Janz: There is no reason to define two types of NDT, online and offline. Having to do so is a consequence of having defined NDT (online) with a broader functional scope than is conventionally done for DTs.
      • Marco Liebsch:In the presented framework, can an application (App) use the NTD to simulate an intent and receive results before enforcing the changes to the physical network? Just to allow the App to elaborate if the impact of the intent is acceptable or not..? upstream it looks like an App can only receive capabilities
      • Danyang Chen: we can do the simulation verification in the inner closed loop
      • Marco Liebsch: does it include the App itself?
      • Danyang Chen: in the inner closed loop, the physical network and APP itself can be unaffected
      • Qin Wu: this is more than verify intent is acceptable, NDT can collect telemetry data to check to match the intent
      • Marco Liebsch: that would mean that the App's intent needs to include sufficient information and semantics to allow the inner closed loop to assess the result and take a decision to enforce or not enforce.
      • Qin Wu: intent may set the target or SLA, NDT can for example, collect the data to see whether network performance meet the SLA
      • Daniel King: @Qin, thanks. So that intent scenario would be "online"? I guess an "offline" intent scenario might be. Analyse my network and highlight possible resilience or future capacity concerns based on planned demand. The latter scenario requires information to perform the intent request. Maybe exploring passive (offline) and active (online/realtime) terminology, for the deployment models/use cases.
      • Daniel King: Slide 6: Online & Offline – We need further discussion and clarification. We had similar discussions in the PCE WG. Online, typically means it is connected to a network for data retrieval. An Offline NDT, might use historical data but it still needs to be connected to the network at some point to retrieve it. Otherwise, you need to add another layer of partitioning. As an application/use case of NDT, “offline” it should not really sit under the “realtime” bullet as shown on the slide.
      • Thierry Coupaye: not sure it should always mirror the behaviour?
      • Qin Wu: the state is data, the core is data driven management or how data is mapped, correlated, derived or verified.

    • Proposed Modifications to NDT Concept and Architecture Draft, Chris Janz

      • Marco Liebsch: What I see from Christoper's material in the context of my previous comment is that we may treat an NDT as a tool for a controller and not as the controller per se.
      • Daniel King: Re: Slide 4 - Proposed Representation. Given the current architecture in the NMRG I-D, where do the Scenario Generation and Scenario Evaluation components reside? Are they within “Data Repository” (left-side box) and “DT Network Mgmt” (right-side box), or are they currently missing from the NMRG architecture?
      • Cheng: slide #6, figure 1 is conceptual
      • Daniel King: defining NDT as "Network Control" would be helped by further detailed the application of "Active Network Control" and "Passive Network Control", for the different use cases.
      • Passive control, at least to me, means gathering data (which may be historic) and insights, which can then inform control decisions or strategies for the future.
      • Qin Wu: @Chris, interface, Data, Models, Mapping will be four phase of data driven management, i.e., where you get the data, how data is stored, how data is modelled, how data i mapped, verified, drived to populate the policy, which build close loop
      • I think the open issue where the controller or analyer sit in the picture? I like analogy of Mark, four elements can be seen as tools.
      • Daniel King: Re: Slide 3 Figure 2: DTN Controller - The controller interface to the real network, which scenarios are you investigating. Is the interface a network/device model, or more abstracted interface that is talking to a controller, which than makes a configuration change?
      • Marco Liebsch: Fig 1 we may be a bit more flexible regarding the upper right box (Interface) and the inner function of the NDT about Control. By intent an App may delegate control to the NTD, but in case the App may be a controller and requests feedback from the NTD. This means a control arrow in Fig.2 may also be from the App to the physical network after the NTD expose simulated figures back to the App.

• 13:10 CET: Next steps

  • NDT topic progress
    • Architecture draft
      • list open questions and issues
        • e.g. on control (in/out of scope)
        • interactions (upper/lower bound), bi-directionality ; real/near-real time
        • capturing generic aspects of NDT architecture vs. specific aspects/characteritics (/requirements)
    • which supporting documents, type of work/interactions --> for what goals (RG level, research studies/results)
    • series of online meetings (à la design team)
  • NDT research agenda
    • Research directions and goals
    • Tentative, proposed research items/documents
      • Questions: separate engineering from research ; inside/outside NDT
      • Use cases
      • Categories
      • Integration with legacy Network Management Systems
      • How can ‘knowledge’ be injected to network digital twin to help achieve vision of ‘autonomous network’?
      • More assessment to quantify the gain brought by DTN to Network management?

• 13:30 CET: End of meeting