Brand New IETF Working Group: Network Management Operations (NMOP)

0

One paragraph summary (TL;DR) of this blog: there is a new cool NMOP just working group just created, with 4 important operational topics (YANG-Push & Kafka, anomaly detection and incident management, digital modeling, and collecting operator operational requirements). You should, at the very minimum, be aware. You should be involved, especially if you are an operator.

Now that the dust has settled on the busy IETF 119 week (March 16th to 22th) in Brisbane, down-under, let me share some news regarding the first Network Management Operations (NMOP) Working Group (WG) meeting. Indeed, this was the first NMOP WG meeting ever.

This WG was created based on the following observations, as mentioned in the charter:

The increased drive by operators for integration and deployment of network management protocols and YANG data models may expose issues and problems with the individual protocols and models, or with the wider integration of both the protocols and the models. Some of these problems may only be witnessed when trying to manage large-scale networks, e.g., due to the increased complexity and handling large volumes of data exported in frequent updates.

A little bit of background here. Based on the numerous and growing amount of side meetings in past IETF meetings, focused on Operations & Management topics (YANG-Push, Digital Map, SRv6 OPS, etc.), the Operations and Management OPS Area Director Rob Wilton gathered operators in a room at IETF 118 in Prague. Obviously, the discussions were centered on the importance of the operations but also on the potential creation of new WG based on the operators need for a place to gather deployment experiences based on the real deployments. As a typical example, the YANG-Push and Kakfa integration (blog post 1 & blog post 2) had several side meetings since IETF 115 … if not before … my memory might fail me!

Based on this initial discussion, and obviously the feedback from the IESG and the IETF as a whole, this WG was chartered, with the following characteristics:

  • First, it’s a operators-focused WG, meaning that the operators will select the topics of interest. Logically, this comes with a time commitment on the operator front.
  • “The goals of the Network Management Operations working group are to solicit input from network operators to identify existing and anticipated operational issues arising from the near-term deployment of network management technologies, and to consider potential solutions or workarounds for those issues.”, as mentioned in the charter. So, this WG focuses on the deployments on existing technologies, most of the time developed in other WGs.
  • However, this WG has different style compared to the regular ones, as it contains the notion of “experiment”, meaning that the code-based experiments is key for the deployment of management protocols and YANG data models. In essence, this WG is at the intersection of the pure protocol & data models WGs, such as OPSAWG, NETCONF, NETMOD, etc. and NMRG, which is exclusively research-focused. In other words, this WG focuses on short-term experiments, achievable within 1-2 years.
  • Finally, there is incentive to develop code in opensource (the charter mentions “Seek involvement with developers of open-source software to help drive adoption of IETF network management standards and to improve protocol maturity.”). The hackathon is obviously a good venue for code development. Regular experiment reports should be presented during the NMOP meetings.

As expressed in the charter, the current topics of focus for the working group are:

  • NETCONF/YANG Push integration with Apache Kafka & time series databases
  • Anomaly detection and incident management
  • Issues related to deployment/usage of YANG topology modules (e.g., to model a Digital Map)
  • Consider/plan an approach for updating RFC 3535-bis (collecting updated operator requirements for IETF network management solutions)

Let’s cover them one by one.

NETCONF/YANG Push integration with Apache Kafka & time series databases

Read more on this effort in this blog.

Anomaly Detection and Incident Management

The idea (presented by Thomas Graf – Swisscom) here is to specify what the network anomaly and incident are, how to annotate an anomaly with some extra semantic information, to explain the network anomaly lifecyle, and how an anomaly relates to an incident. The proposed semantics uniforms the network anomaly data exchange between and among operators and vendors to improve their network outlier detection systems. The experiment consists of verifying whether the approach is usable in real use case scenarios to support proper refinement and adjustments of network anomaly detection algorithms.

Issues related to deployment/usage of YANG topology modules (e.g., to model a Digital Map)

There are a lot of topology-related YANG models augmentations based on RFC 8345 – A YANG Data Model for Network Topologies, as you can see from the picture below (source here).

The key question at stake here, presented by Oscar González de Dios, Telefonica,: Are all these YANG modules a good basis to create THE Digital Map, defined as: “Digital Map: Basis for the Digital Twin that provides a virtual instance of the topological information of the network. It provides the core multi-layer topology model and data for the Digital Twin and connects them to the other Digital Twin models and data.”. Oscar’s approach to start focusing on two apparently easier modeling technologies : OSPF and IS-IS.

And guess what, from our proof-of-concepts, we found limitations in trying to model this Digital Map. First off, in how the related YANG models were (inconsistently) specified. On top of that, we found RFC8345 limitations, which prevents us from building the correct Digital Map.

A new revision of RFC 8345 might be in question here. More background information in this blog.

Consider/plan an approach for updating RFC 3535-bis (collecting updated operator requirements for IETF network management solutions)

The Overview of the 2002 IAB Network Management Workshop (RFC3535) stems from an workshop where a dialog started between network operators and protocol developers to guide the IETFs focus on future work regarding network management. This workshop lead to the creation of the NETCONF WG where both NETCONF and RESTCONF were specified, and to the development of YANG modeling language in the NETMOD WG, following by the specifications of a series of YANG models in the IETF and other places in the industry.

20 years later (the RFC 3535 was published in 2003), it’s time to collect the new operator requirements, which will lead to the next series of IETF innovations. At this stage, the NMOP WG role is to brainstorm on on how to collect those requirements.

You are more than welcome to contribute to the NMOP work, especially if you are an operator. Some references:

If you have any questions, don’t hesitate to contact me.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.