Network Management Operations (nmop) WG Agenda - SIMAP Interim

• When: Fri, Feb 14, 2025
• Co-Chairs: Benoît Claise & Mohamed Boucadair

1. Agenda Bashing & Introduction (Chairs) (5 min)

• Slides
• no agenda bashing

2. SIMAP Activities Since IETF#121 (Olga Havel, 45 min)

• Slides

Benoit Claise: Two use cases (service -> subservice -> resource AND resource->subservice->service), we are missing the use case text in the section.

Olga Havel: Exactly. I am raising this in the list of use cases.

Olga Havel: Adrian, would you like to define the term "Service" in draft-ietf-nmop-terminology?

Adrian Farrel: I rather not to avoid lengthy discussions. I suggest to scope the definitions to your document.

Mohamed Boucadair: What about not using subservice, but use resources (as it covers the composite aspects) instead?

Olga Havel: Subservice is being defined with RFC 9417 (SAIN). Maybe better remove subservice as a use case.

Benoit Claise: Just double check wherever the subservice in SAIN (RFC 9417) is aligned with the definition in this draft?

Olga Havel: Are "service->subservice->resource" and "resource->subservice->service" really a business use case?

Benoit Claise: They are but they are more related to SAIN than SIMAP. Proposal: we can move those two under "intent / service assurance".

Olga Havel: That makes sense. It could be used then for Postmortem or Capacity Planning for example. It is widely applicability.

Benoit Claise: On the use cases, many are linked. The question is whether or not there are some specific requirements for SIMAP. Example: Network Digital Map could be part of Simulation. Out of this, are there any specific requirements for SIMAP?

Olga Havel: In terms of queries. Example: Show me all resources for a given service, Show me all services for a given resource.

Med: Agree with Benoit that the use cases are related. What I understood from network operators so called service impact analysis is important. We don't need to be comprehensive (we have many use cases already). We can merge the service->subservice->resource" and "resource->subservice->service" under "Intent /Service Assurance". Some uses may be mentioned there (e.g., service impact analysis). We need to focus on those with unique requirements.

Oscar Gonzalez de Dios: Network Digital Twin. The term might not clear enough. It's best to remove it. Instead cover it under simulation and emulation. We can then avoid the controversy of Digital Twin.

Oscar Gonzalez de Dios: wrt "service->subservice->resource" and "resource->subservice->service", the main use case is assurance BUT also consistency checks. Move them inside "Intent / Service Assurance", focusing on the intent. Oscar will help with the text.

Benoit Claise: In order to improve the use case section, do you agree to move under intend and service assurance section and focus on intend.

Oscar Gonzalez de Dios: traffic engineering is not a use case, so a set of techniques. Proposal: Define clear use cases where traffic engineering is being used. For instance consistency checks. Oscar will provide some text.

Mohamed Boucadair: TE is already mentioned in the simulation use case. Closed Loop applies to traffic engineering.

Oscar Gonzalez de Dios: Traffic engineering could be also applied to capacity planning. In what-if scenarios.

Mohamed Boucadair: Regarding Network Digital Twin (NDT), draft-irtf-nmrg-network-digital-twin-arch is used as a reference. IOWN people are interested in SIMAP and its relationship to Digital Twin. Please clarify your concern.

Oscar Gonzalez de Dios: When started this document, the term Digital Twin is not clear. Claiming that we do a standard for Digital Twin is too: let's not mislead people.

Mohamed Boucadair: Fair but at that time, the document first focus was Digital Twin. Let's avoid this confusion, if you believe there is. NDT is a consumer of this work. No one challenged that.

Oscar Gonzalez de Dios: If you can put the correct wording, would be more than happy.

Thomas Graf: Regarding "Inventory queries", "Network design" and "Capacity planning". I think they are related. Reading into "Inventory queries", I understand the objective is to optimize physically the network. My suggestion is to replace "Inventory queries" and "Network design" with physical and logical network planning.

Benoit: We can extend the use cases. What is important is whether there are new requirements for the SIMAP modeling (the last paragraph of each use case section).

Olga: Do you agree to add these requirements?

Oscar Gonzalez de Dios: Yes, let's see wherever we want to add the other use cases mentioned as well.

Mohamed Boucadair: Please include the new requirements after the discussion on the mailing list.

3. Do We Need Link State in SIMAP Core Model (Oscar Gonzales de Dios, 15 min)

• Slides

Pierre: I will be talking about this issue in the next presentation. Wherever it should be an augmentation or a reference. How to link that external information. In case of the mentioned link state, it depends what use case you try to cover. I suggest to keep the model open in term of wherever to augment or reference.

Thomas Graf: The state, up/down, depends on the layer. It could be up on a lower layer and down on a upper layer. Regarding planned, it should be in a separate topology where topology planning takes place. As Pierre mentioned, this will be relevant as well in the postmortem replay use case.

Olga Havel: There are some complications in layered approach (VPN, TE, SAP, AC, etc.). Unless we want to add some status specific to SIMAP, it will be difficult to add here and maintain it. There might be some duplication.

Benoît Claise: What type of status we want? It is likely to be complex quickly (e.g., staging, dormant, partially up, depend on the topology). If only of key concept in SIMAP (present or not?), this would work but not for every component. And there is a link with the snapshots?

Oscar Gonzalez de Dios: Agree, but the very first one is when the object appears/disappears from the structure.

Sherif Mostafa: If we add status, this opens the door for other items (including in another time). Rather than having this in the base, consider managing it for specific uses.

Oscar Gonzalez de Dios: There are two open issues on this point. Please take a look.

Mohamed Boucadair: Please keep the mailing list when discussing these points. Thanks.

Thomas Graf (chat): +1 on Sherif's proposal on having network entities which are state down, make them visible for network planning relate topology.

4. Overview of the Approaches to Extending the SIMAP with Conf/Stats (Pierre Francois/Vivekananda Boudia, 30 min)

• Slides

Pierre Francois: Sponsored by Huawei to conduct some work on SIMAP for SRv6 in the context of SAIN.

Thomas Graf (chat): +1 to Pierre that SIMAP only scales if it is distributed and layered as the network it represents.

Thomas Graf (chat): (on Slide#10) The main use case is to find the common root cause, identify the causality chain. Anomaly Detection is capable to monitor connectivity services on some of these aspects. When failure is detected, it points to a cause, but not to a common root cause. There SIMAP will help.

Thomas Graf (chat): (on Slide#19) I agree on approach 1 and 2. I believe the choice between 1 and 2 depends on the amount of information to be mapped vs. how fast the map needs to be drawn. For approach 1 it needs to be in real-time. In approach 2, it is perfectly fine if a query in the map takes several minutes.

Pierre Francois: Both approaches are likely to be supported.

Thomas Graf: Publish this as an informational I-D.

Benoît Claise: Pierre is asking the right questions. We will/are reaching the limit of YANG. Defining a YANG module to fix this is interesting! Will see if it is worth to standardize it; let first show this SIMAP is useful for one use case (SIMAP + SAIN + SRv6). Yes, you are one year ahead.

Vivekananda Boudia: Request can be of any type, not only NETCONF/RESTCONF.

Mohamed Boucadair: Agree, it would be very useful to make the work publicly available.

Mohamed Boucadair: For the link with SAIN, this is a concern about the usability of the model. As this work was done in OPSAWG, consider reaching out with OPSAWG/NMOP to explain the issue and take it from there.

Pierre Francois: Will do.

5. Passive Topology Comments (Olga Havel, 20 min)

• Slides

Thomas Graf: From an operator perspective, having the visibility to the passive topology is useful but my concern is implemented in the current active topology together. I suggest to separate in a dedicated topology. Would you agree wherever it would simplify?

Olga Havel: From the modelling perspective, it can be in a separate layer.

Thomas Graf: Keeping separate would work. See also the considerations discussed by Pierre in terms of scaling. Agree, in SIMAP but on keeping it as a separate layer.

Olga Havel: Topological relationships are there.

Oscar Gonzalez de Dios: Having as simple as possible as pointer to an external source to understand the relationship to the physical passive network.

Olga Havel: My proposal to have as an internal link or segment with relationships.

Daniele Ceccarelli: If planning is one core use case, then the passive part is needed. It can be separated as a layer.

Olga Havel: What about the duplicated information in both the inventory and SIMAP. Will discuss with the authors of passive I-D.

Thomas Graf: The passivity aspect to me is more wherever it is up or down. Where the planning aspect is more about time. Wherever it is replay in the past or what-if in the future.

Daniele Ceccarelli: Did I understood correctly, the passive inventory is not needed for planning?

Thomas Graf: Correct. Passivity is relevant depending on topology layers.

Daniele Ceccarelli/Mohamed Boucadair: Let's keep cross posting IVY/NMOP on this specific point.

Brad Peters: From planning and root cause analysis SIMAP and the passive layer is extremely important to cover.

Thomas Graf: Fully agree with Brad.

Daniele Ceccarelli: I agree with you assessment. There is no reason why it needs to be aligned.

Mohamed Boucadair: We had this discussion in IVY. The design is flexible and modular. We should keep it separate.

6. Next Steps (Chairs, 5 min)

1. Olga Havel: A set of open issues to be closed. Please keep the mailing list involved and close items and let the WG converge.
2. Pierre Francois/Vivekananda Boudia: Please share the hackathon finding and linking to other data sources. Please consider to document.
3. Keep IVY involved for the passive discussion
4. Great energy. Keep discussing before IETF 122 in Bangkok. The presentation time at IETF 122 in Bangkok should be spent on focused items, with the goal to reach consensus.