Skip to content

RFC 9968: Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS)

  • W. Hardaker,  
  • D. Dhody
Informational
RFC Tips

Abstract

The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024 as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535, identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet's operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Building on RFC 3535, this document provides the report of the follow-up IAB workshop on network management.

Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9968.

1. Introduction

The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF).

The IAB organized a workshop in 2002 to establish a dialog between network operators and protocol developers and to guide the IETF's work on network management protocols. The outcome of that workshop was documented in the "Overview of the 2002 IAB Network Management Workshop" [RFC3535], which identified 14 operator requirements and 11 recommendations for consideration in future network management protocol design and related data models within the IETF.

Those requirements were instrumental in developing the Network Configuration Protocol (NETCONF) (in the NETCONF Working Group) [RFC6241], the associated YANG data modeling language (in the NETMOD Working Group) [RFC7950], RESTCONF [RFC8040], and most recently the CoAP Management Interface (CORECONF) [CORECONF].

The recent NEMOPS IAB workshop focused on the following key tasks:

  • Review the outcomes and results of the 2002 workshop (current deployments and state of the art) and identify any operational barriers that prevent these technologies from being widely implemented (limitations and hurdles).

  • Sketch new requirements for future network management operations in a collaborative manner with the industry, network operators, and protocol engineers.

  • Develop a plan of action and recommendations for the IETF.

This document builds on RFC 3535 with new information gathered from the second IAB workshop on the future of network management. The goal of the second workshop was not to invalidate or replace the first but to extend the discussion with lessons learned since then. Together, both documents capture a snapshot of the evolving needs of network management over time.

1.1. About the Content of This Workshop Report

This document is a report on the proceedings of the workshop. The views and positions documented in this report are expressed during the workshop by participants and do not necessarily reflect the IAB's views and positions.

Furthermore, the content of the report comes from presentations given by workshop participants and notes taken during the discussions, without interpretation or validation. Thus, the content of this report follows the flow and dialogue of the workshop but does not necessarily attempt to capture a consensus, unless stated otherwise.

2. Outreach and Survey

The IAB workshop's Program Committee (PC) planned outreach initiatives to foster discussions and gather interest by engaging with operators at various operational venues (Réseaux IP Européens (RIPE), North American Network Operators Group (NANOG), Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), Latin American and Caribbean Internet Addresses Registry (LACNIC), AutoConn, etc.) and conducting information-/requirement-gathering sessions. Participants were encouraged to submit "position papers" or "expressions of interest" to join the workshop. Additionally, a [SURVEY] was conducted to collect valuable insights to inform the workshop.

After the workshop, some PC members continued to engage with network operators at operational venues to facilitate information sharing and gather their feedback on the workshop, thereby helping to shape the next steps and outcomes.

3. Workshop Scope and Discussion

The workshop was organized across three days, with all participants contributing to one discussion per day. The workshop was organized around three topic areas: "Session I: Past - Lookback and Analysis" (Section 3.1), "Session II: Present - Identified Problems and Requirements" (Section 3.2), and "Session III: Future - Possible Solutions, Recommendations, and Next Steps" (Section 3.3). The program committee organized the paper submissions to fit these three main themes in order to drive discussion during each of the slots. During each discussion, the papers were presented sequentially, and an open discussion was held afterwards. On the last day, an additional discussion took place on the key takeaways from the workshop and possible next steps (Section 3.4).

The workshop agenda for each day can be viewed at "Past (Session 1)", "Present (Session II)", and "Future (Session III)". All workshop papers and slides can be viewed at "materials".

3.1. Session I: Past - Lookback and Analysis

The first day of the workshop focused on reflecting on the past by reviewing the evolution of network management since the 2002 workshop, analyzing both the successes and the challenges encountered along the way. The presentations covered a range of topics, including reflections on the history of network management, lessons learned from widely used tools, practices in constrained networks, and the need to reconsider how network management models and protocols are standardized within the IETF.

3.1.1. Reflections

The workshop began by reflecting on the IAB's role in shaping the evolution of network management away from Command-Line Interface (CLI), SNMP, and MIB technologies, focusing on the context and key outcomes of the previous workshop, an assessment of the current state of network management as a whole, and an acknowledgement of some regrets in how network management technologies developed in the last two decades (such as XML as the data representation format). [SCHONWALDER] emphasized the need to shift the focus from device-level configuration to network and service-level configuration. Key properties highlighted for effective network and service configurations included being Composable (assembled out of modular configurations), Declarative (define state while systems themselves determine how to implement those goals), Reproducible (reliably and consistently recreated), and Verifiable (asserting that the correct changes have been applied).

An operator's perspective highlighted that the recommendations of [RFC3535] (which led to the development of YANG and NETCONF) have been successful in addressing device configuration in many, but not all, environments. In certain areas, the advancements in semantics and protocols for streaming telemetry have even surpassed the original scope of [RFC3535]. [FARRER] cautioned against making changes that could disrupt the ecosystem. The presentation emphasized the need to prioritize service modeling in the IETF and addressed the challenges of mapping to the Business Support Systems (BSS) domain. It also stressed the importance of including the operational state in service models to enable closed-loop automation for end-to-end (E2E) services. Revisiting [RFC8309], which asserts that the operational state of a service is not part of a customer service model but can be achieved through extensions, was suggested. Additionally, the lack of open-source Network Management System (NMS) implementations, tools, and device model implementations was identified as a significant barrier to advancing standardization efforts. The IETF could play a key role in fostering and enabling collaborations to address these challenges. While the IETF does not itself build tools, it was suggested that having a translation tool that runs outside the network device to map IETF device models to vendor-specific ones would be beneficial.

3.1.2. Lessons to be Learned

[HARDAKER] emphasized that the success of Net-SNMP [NET-SNMP] was driven by empowering users through simplicity, stressing that the focus should remain on ensuring ease of use and adaptability of the protocols. Emphasis was placed on the two distinct audiences for standardized network management protocols: toolkit vendors and system operators. Their requirements for protocol simplicity differ, and it is essential to address the needs of both to ensure success. [BORMANN] presented an overview of the CORECONF architecture, showcasing how model-driven network management techniques can be applied to manage Internet of Things (IoT) devices (which is different from other network management scenarios), with a focus on the unique characteristics of constrained nodes. Some participants noted that the binary encoding of Concise Binary Object Representation (CBOR) has applications that extend beyond the IoT networks.

Drawing from the experience of OpenConfig [OPENCONFIG], [SHAKIR] emphasized that protocol definition and data models cannot be done in isolation; instead, they must integrate lessons learned from implementation and large-scale deployment. Thus, highlighting the importance of enabling quick iterations, shipping rapidly, embracing open source, readily available tools, adopting systems thinking driven by business outcomes, and reusing existing technologies rather than developing solutions exclusively for operator network management. A call was made for the IETF to rethink the approach to standardize data models and the associated network management protocols under this guidance.

3.1.3. Discussion

The Session I open discussion highlighted the divergence between vendor implementations of YANG models and what is accessible via the models, particularly when compared to CLI. Questions were raised about how to incorporate fast iteration and rapid changes within the established IETF process and culture, especially in contrast to the approach used by OpenConfig. Common challenges identified included a lack of tooling, performance issues at scale, the steep learning curve for network management protocols/models/tools, initial difficulty in moving away from CLI, and the backward compatibility of models (versioning). Some participants suggested that the IETF should focus on system-level APIs that address specific problems. Additionally, the lack of simple tools for smaller networks operating under tight timelines and budgets was emphasized. A key question raised was whether the proliferation of protocols and languages complicates adoption and if converging on a single approach would improve adoption. The existence of multiple schemas and protocols beyond NETCONF, such as the BGP Monitoring Protocol (BMP) and IP Flow Information Export (IPFIX), to address network management challenges beyond configuration is an established reality. One conclusion was that a mechanism was needed to interconnect and harmonize these schemas to provide a cohesive and comprehensive understanding of the data.

3.2. Session II: Present - Identified Problems and Requirements

The second day of the workshop concentrated on challenges and emerging requirements for future network management operations. The presentation emphasized the importance of validation, observability, automation, and the need for agile, incremental development of both network models and management protocols. A compilation of new requirements from operators was presented; they are being maintained in [OP-REQ-NM]. The final presentation of the day provided a summary of the survey results and operator feedback gathered from outreach events.

3.2.1. Operator Feedback

[KELLER] shared Deutsche Telekom's perspective, emphasizing that while YANG models perform well for provisioning, they currently fall short in providing the operational stability required for validation. In their experience, the IETF service models (where available) were considered stable and in good condition, whereas the OpenConfig device models were noted as lacking feature richness and stability. In contrast, vendor YANG models are often more flexible and available in a more timely manner. Achieving fully closed-loop automated and autonomous networking will require a greater focus on observability, particularly through advancements in streaming telemetry with the "on-change" feature [RFC9196].

[JIMENEZ] discussed the challenges associated with the Software Defined Networking (SDN) Transport Automation Platform, including observability and analytics requirements, issues with data streaming, scalability, diverse models in heterogeneous multi-vendor environments, and mechanisms to secure the network management protocols. The presentation also emphasized how advancements in AI and machine learning, along with the potential adaptation of protocols designed for constrained environments, could drive the next evolution in network management.

Using YANG-Push as an example, [GRAF] highlighted how standards development often fails to align with the needs of network operators, the constraints of network vendors, and integration requirements. Most critically, it lacks an agile, incremental development process. The presentation advocated for adopting an iterative approach to standards development, focusing on delivering minimal viable products as part of the process.

[CONTRERAS] emphasized reassessing deployment assumptions and incorporating updated operator requirements. The authors are addressing these aspects through [OP-REQ-NM], leveraging feedback and discussions from the workshop. Some key requirements, suggestions, and observations that were highlighted in the workshop:

  • Network software implementations can only happen with a strong, committed standardization effort, complemented by active involvement in open-source projects that facilitate access to code.

  • Need to rationalize the device model space and avoid redundant efforts. Unlike service and network models, IETF-defined device models are not widely implemented.

  • Define a reference approach/process for service exposure discovery (API discovery).

  • Outline a set of recommendations for core/key features, along with appropriate justifications, that will help foster more implementations that meet operators' needs.

  • Reassess the value of some IETF proposals, including comparison to competing or emerging solutions (e.g., gRPC Network Management Interface (gNMI) vs. YANG-Push)

  • Need for a more agile process for the development and maintenance of YANG modules in the IETF. RFCs might not be suited for documenting YANG modules.

  • Consider approaches to ease integration by design (e.g., protocols and data models).

  • Need for a reference specification to translate YANG-based data into the knowledge graph (KG).

  • Consider approaches to help YANG models scale.

  • Consider programmatic approaches to ensure lossless mappings between service/network/device data models.

  • Consider approaches to ensure reuse of / consistent data structure across various network management segments.

  • Some networks have specific network management requirements, such as the need for asynchronous operations or constraints on data compactness.

  • Necessity to handle the heterogeneity of data, configuration, and network management/requirements. Resolving such issues could draw on insights from parallel technical fields such as knowledge engineering practices and concepts associated with Linked Data in the Semantic Web, areas where it is common to manage problems of heterogeneity and data reconciliation across various application domains.

  • Consider having YANG as part of the protocol specification/change where possible, or have the YANG document progress in parallel.

  • Need to ease the integration of low-level/network-oriented solutions with common "IT tooling".

  • Ease exposure of libraries and host tools (e.g., yangkit) to ease integration.

  • Focus on tooling is needed, especially on the client side.

  • Create an ecosystem where data and networking engineers can collaborate.

  • Distinct approaches are followed in both the compute and the network environments to define suitable mechanisms for enabling an efficient interplay, while highly automating the overall service delivery procedure.

  • The target application/applicability of a network management approach should be documented.

  • Readily available API specifications could be generalized from YANG modules for fast development, prototyping, and validation.

3.2.2. Survey

As outlined in Section 2, the workshop program committee organized outreach initiatives to gather direct feedback and conducted a survey. [SURVEY-INSIGHTS] provided an overview of the respondents' backgrounds, as well as insights into the most widely used tools, protocols, and APIs for configuration, monitoring, and other network operations. Notably, the survey revealed that Ansible and CLI are the most popular configuration tools, NETCONF is the preferred configuration protocol, and Prometheus and SNMP are widely used for monitoring. The survey also captured feedback on network automation and streaming telemetry. Issues and future requirements such as scalability, performance, the need for easier mapping of various models, tooling, management of legacy devices, collaboration with open source, and vendor-specific issues were highlighted. Additionally, valuable insights from direct operator feedback were presented (see Appendix A).

3.2.3. Discussion

The Session II open discussion featured feedback from implementers, highlighting the difficulty in moving to YANG and mapping to vendor implementations and how divergence in implementations creates complexity and necessitates workarounds. Implementations need to support standard models alongside vendor-specific models, which adds complexity and leads to confusion. Challenges were highlighted in mapping standard models to internal device models and legacy devices, with some cases where mapping is not feasible at all (device-specific knobs). The conversation also emphasized the importance of developing open-source reference implementations, compliance and interoperability testing for vendors with real data, and better quality of vendor implementation and documentation. The implementation and support of multiple models (IETF, OpenConfig, and vendor-specific models) is an unavoidable reality in network management. Additionally, since the services offered by operators vary significantly, reaching a consensus on a common service model within the IETF can be a challenging task. It was also noted that the IETF should expedite the publication of standards as well as consider gating them with multiple interoperable implementations.

3.3. Session III: Future - Possible Solutions, Recommendations, and Next Steps

The final day of the workshop centered on exploring potential future solutions and identifying key takeaways, recommendations, and next steps. At the end of day three, to conclude the workshop, the chairs worked to summarize the key takeaways (see Section 3.4) that garnered consensus among the participants.

3.3.1. Suggestions on Future Directions

[CLAISE] highlighted the challenges of integrating data models across different silos, protocols, and data structures, emphasizing the need for a machine-readable approach to expose semantics. Additionally, the related tools being developed and showcased in the IETF Hackathons, along with the various challenges in mapping across protocols and models, were discussed. A potential solution was proposed that uses a knowledge graph based on the Semantic Web Stack, along with the need to define a basic ontology for the networking domain in an iterative manner (outside of RFCs).

[WATSEN] recommended prioritizing the following into four areas: (1) using RESTCONF+JSON (including YANG-Push Lite) as a single protocol beyond network management, (2) utilizing Network Management Datastore Architecture (NMDA) model, (3) creating data model adapters (off-box so that common standard models can be developed in parallel to the required device vendor-specific models), and (4) defining device protocol adapters (with RESTCONF-like Northbound Interface (NBI) for a common shared-by-all repository).

[WILTON] recommended reducing unnecessary complexity, delivering timely solutions, fostering open collaboration between vendors and operators, prioritizing simplicity, and converging to a single model/protocol (though this was discussed as difficult to accomplish). Practical suggestions include focusing on YANG-Push Lite, introducing YANG 2.0 through incremental updates, developing NETCONFv2, and managing IETF YANG models as code or APIs rather than embedding them within RFCs.

3.3.2. Discussion

The open discussion in Session III explored a range of topics. These included the absence of NMDA in OpenConfig and debate over whether its complexity is justified; the historical context of gNMI's introduction in the IETF and whether RESTCONF offers advantages over it; and the broader challenges of building consensus, with participants noting that while the process takes time, it should not be short-circuited. The discussion also addressed the practicality of converging on a single protocol and concluded that such convergence is, in fact, feasible.

The discussion emphasized off-box adapters, which allow vendors to continue innovating and developing vendor-specific models rapidly. One suggestion that attracted a lot of discussion centered on developing a standard model mapping to vendor-specific models that could be maintained in a common repository, enabling the community to assess coverage and alignment.

Further, the discussion explored alternative approaches to YANG models within the IETF but outside of RFCs, such as leveraging GitHub to accelerate the process (along with the challenges associated with it), living documents within the WG charter, and supporting academia to take up the open source efforts, such as device adapters. The discussion emphasized the need for process experimentation, particularly at the working group or area level, where we could have consensus among the YANG/OPS community on how we iterate in WGs without IETF-/RFC-wide changes, but making sure the operators are involved in the process.

Conversations ensued around questions asked, such as "Is YANG applicable beyond network management?" and "Can applications adopt YANG as a modeling language to define their services?"

Some key recommendations made by operators during outreach (Section 2) are listed in Appendix B.

3.4. Key Takeaways

At the end of the third day, the discussion turned to key takeaways that have a high-level consensus. These were edited live during the last discussion of the workshop, and anything that did not reach a wide consensus was moved into a "future considerations" list (Section 3.4.5).

3.4.1. Ecosystem Conclusions

The following takeaways try to document the general thinking of the participants with respect to the entire network management ecosystem as it exists today.

  1. The current network management protocols, models, and tools still fail the 'ease of use' requirement. Participants noted that the tools almost matter more than the protocols.

  2. The overall ecosystem is still fragmented for both protocols and data models. SNMP is still used extensively for monitoring, and the CLI is still heavily relied on for configuration in many networks. Popular protocols include SNMP, NETCONF, RESTCONF, and gNMI.

  3. Documentation about the architecture and usage of the network management ecosystem is lacking. More work is needed to create general architecture documentation, deployment guides, tutorials, training material, and getting-started guides.

  4. Transitioning between network management frameworks is challenging, just like it is for transitioning between other protocols like IPv4 to IPv6.

  5. Model-driven network management is generally a success where it has been implemented and is possible to use.

  6. More easily usable network management tools for the operators are needed. The lack of open-source tools is seen as a barrier to adoption. Tools need good use cases, example flows, and better analysis of when and how they work and have been successful.

3.4.2. Protocol Conclusions

The following conclusions were reached while discussing network management protocols, more specifically.

  1. NETCONF and YANG are not used much for monitoring tasks.

  2. NETCONF and YANG do not have full coverage on many devices.

  3. Polling-based solutions are still frequently deployed. Push-based solutions are often desired but are not yet widely available.

3.4.3. Modeling Conclusions

The following conclusions were reached while discussing network management modeling, more specifically.

  1. Some YANG models can become complex due to the underlying features they represent, not due to the language itself.

  2. Multi-vendor compatibility support is required.

  3. Even vendor-specific features, not just standardized protocol features, need to be exposed through network management models and protocols for a network management ecosystem to be viable.

  4. Greater support for service-level modeling is needed. Device-level modeling can be a building block to achieve a sufficient service-level model, but it is not a complete solution by itself.

  5. Network configuration needs to be verifiable to ensure any potential changes can be accepted by devices. Model translation adapters (likely performed on the management station, not the end device) may be the best path forward to simultaneously achieve this and the goal of supporting one configuration set across a diversity of devices with different internal models.

3.4.4. Standardization Conclusions

The following conclusions were reached while discussing the best ways to standardize network management protocols and associated models.

  1. A methodology of rapid model development procedures is needed to ensure model deployment can keep pace with new feature deployment. We need a solution that significantly increases the speed and predictable timeline for developing and publishing models within the IETF. New approaches and methods to make models live outside of published RFCs should be explored. An experiment should be started to test a new rapid development approach.

  2. Protocol and model complexity should be reduced to keep additions and changes to a minimal set of agreed-upon core features.

  3. More standardization focus is needed on the scalability of the different roles of network management: monitoring, configuration, and notifications.

  4. Enhancements to network management protocols and models need to be backed by real-world operator use cases and expected adoption by vendors. Vendors and operators will need to work together to ensure these goals are appropriately met.

3.4.5. Conclusions That Did Not Reach Consensus During the Takeaways Discussion

Here, we list the things that the group realized needed significantly more attention in order to come to a conclusion, while updating the key takeaways in real time.

  1. Some, but not all, saw NETCONF for configuration as being successful in some larger-scale deployments. Although this statement is true in some contexts, many operators indicated their need to rely on other forms of access to manage their networks, such as CLIs, Expect scripts, and other protocols.

  2. Many hope that NETCONF, and RESTCONF more specifically, will continue to move to a long-term configuration management solution. However, some participants doubted whether the protocol and its data models can ever be truly ubiquitous and keep pace with the device deployment pace.

While many other items also need further discussion, this list specifically includes those that were actively discussed during the live editing session in the workshop.

4. Not Covered in the Workshop

Some topics absent from the workshop discussions included tooling (what is currently missing) and strategies to support tool development (who pays, who develops, and who maintains). The primary focus of the discussion was on YANG and NETCONF/RESTCONF, while several other network management protocols and techniques currently used received less attention. During the workshop, the discussion on possible future directions prioritized improving existing solutions rather than introducing entirely new ones (such as enabling intelligence in network management).

5. Security Considerations

This document is a workshop report and does not impact the security of the Internet.

6. IANA Considerations

This document has no IANA actions.

7. Informative References

[BLESS]
Bless, R., "An Invariant for Future Resilient Network Management Operations", , <https://www.ietf.org/slides/slides-nemopsws-paper-an-invariant-for-future-resilient-network-management-operations-00.pdf>.
[BORMANN]
Bormann, C., "CORECONF: Managing IoT Devices with YANG Models", , <https://www.ietf.org/slides/slides-nemopsws-paper-coreconf-managing-iot-devices-with-yang-models-00.pdf>.
[CLAISE]
Claise, B., Graf, T., Keller, H., Voyer, D., Lucente, P., Lopez, D., Martinez-Casanueva, I. D., Peters, B., Fasano, P., Ran, P., Cheng, W., and M. Mackey, "Knowledge Graph Framework for Network Operations", , <https://www.ietf.org/slides/slides-nemopsws-paper-knowledge-graph-framework-for-network-operations-00.pdf>.
[CONTRERAS]
Boucadair, M., Contreras, LM., Gonzalez de Dios, O., Graf, T., Rahman, R., and L. Tailhardat, "RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling", , <https://www.ietf.org/slides/slides-nemopsws-paper-rfc3535-years-later-an-update-of-operators-requirements-on-network-management-protocols-and-modelling-00.pdf>.
[CORECONF]
Veillette, M., Ed., Van der Stok, P., Ed., Pelov, A., Ed., Bierman, A., and C. Bormann, Ed., "CoAP Management Interface (CORECONF)", Work in Progress, Internet-Draft, draft-ietf-core-comi-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-21>.
[ECKERT]
Eckert, T. and M. Richardson, "Resilient Remote Manageability of Wide-Area Network Infrastructures", , <https://www.ietf.org/slides/slides-nemopsws-paper-resilient-remote-managability-of-wide-area-network-infrastructures-00.pdf>.
[FARRER]
Larsson, K., Lambrechts, K., and I. Farrer, "RFC3535, 20 Years Later from an Operator's Perspective (Deutsche Telekom)", , <https://www.ietf.org/slides/slides-nemopsws-paper-rfc3535-years-later-from-an-operators-perspective-deutsche-telekom-00.pdf>.
[FOROUGHI]
Foroughi, P. and L. Ciavaglia, "Projecting Data Mesh to Model-driven Telemetry: A Path to Data Ecosystem's Management Operations", , <https://www.ietf.org/slides/slides-nemopsws-paper-projecting-data-mesh-to-model-driven-telemetry-a-path-to-data-ecosystems-management-operations-00.pdf>.
[GIRALT]
Contreras, LM., Schott, R., Randriamasy, S., Yang, R., and J. Ros-Giralt, "Towards a Unified Compute and Communication Infrastructure for Application and Network Management", , <https://www.ietf.org/slides/slides-nemopsws-paper-towards-a-unified-compute-and-communication-infrastructure-for-application-and-network-management-00.pdf>.
[GRAF]
Graf, T., Keller, H., Voyer, D., Lucente, P., Claise, B., Wilton, R., Huang-Feng, A., and P. Francois, "Agile Incremental Driven Development for Network Management", , <https://www.ietf.org/slides/slides-nemopsws-paper-agile-incremental-driven-development-for-network-management-01.pdf>.
[GUDI]
Gudi, M., Pelov, A., Toutain, L., and J. M. Bonnin, "Evolving Network Management Architecture: Integrating CORECONF with NETCONF for Efficient Telemetry and Management", , <https://www.ietf.org/slides/slides-nemopsws-paper-evolving-network-management-architecture-integrating-coreconf-with-netconf-for-efficient-telemetry-and-management-00.pdf>.
[HARDAKER]
Hardaker, W., "Lessons Learned from 30 Years of Net-SNMP", , <https://www.ietf.org/slides/slides-nemopsws-paper-lessons-learned-from-30-years-of-net-snmp-00.pdf>.
[JIMENEZ]
Jiménez, J., Mansfield, S., Rodriguez A, R., Pesonen, M., Torvinen, V., and J. Karvonen, "Evolving Challenges and Solutions in Network Management", , <https://www.ietf.org/slides/slides-nemopsws-paper-evolving-challenges-and-solutions-in-network-management-00.pdf>.
[JIMENEZ-2]
Jiménez, J., "Managing IoT Devices with LwM2M", , <https://www.ietf.org/slides/slides-nemopsws-paper-managing-iot-devices-with-lwmm-00.pdf>.
[KELLER]
Warnke, N., Geib, R., Horneffer, M., and H. Keller, "NEMOPS: RFC3535 and the forgotten word - Or Provisioning is only a subset of Network Management", , <https://www.ietf.org/slides/slides-nemopsws-nemops-rfc3535-and-the-forgotten-word-00.pdf>.
[MARTINEZ]
Martinez-Casanueva, I. D., "IAB NEMOPS Position Paper - Telefonica", , <https://www.ietf.org/slides/slides-nemopsws-paper-iab-nemops-position-paper-telefonica-00.pdf>.
[NET-SNMP]
"Net-SNMP", <http://www.net-snmp.org/>.
[OP-REQ-NM]
Boucadair, M., Contreras, L. M., Gonzalez de Dios, O., Graf, T., and R. Rahman, "An Update of Operators Requirements on Network Management Protocols and Modelling", Work in Progress, Internet-Draft, draft-ietf-nmop-rfc3535-20years-later-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-rfc3535-20years-later-04>.
[OPENCONFIG]
"OpenConfig", <https://www.openconfig.net/>.
[RFC3535]
Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, DOI 10.17487/RFC3535, , <https://www.rfc-editor.org/info/rfc3535>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
[RFC8309]
Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, , <https://www.rfc-editor.org/info/rfc8309>.
[RFC9196]
Lengyel, B., Clemm, A., and B. Claise, "YANG Modules Describing Capabilities for Systems and Datastore Update Notifications", RFC 9196, DOI 10.17487/RFC9196, , <https://www.rfc-editor.org/info/rfc9196>.
[SCHARF]
Scharf, M., "Network Management Challenges for IP-based Cyber-Physical Networks", , <https://www.ietf.org/slides/slides-nemopsws-paper-network-management-challenges-for-ip-based-cyber-physical-networks-00.pdf>.
[SCHONWALDER]
Schönwälder, J., "Composable, Declarative, Reproducible, Verifiable Network and Service Configurations", , <https://www.ietf.org/slides/slides-nemopsws-paper-composable-declarative-reproducible-verifiable-network-and-service-configurations-00.pdf>.
[SHAKIR]
Shakir, R., "Rethinking Standardisation of Network Management", , <https://www.ietf.org/slides/slides-nemopsws-paper-rethinking-standardisation-of-network-management-00.pdf>.
[SURVEY]
"Next Era of Network Management Operations (NEMOPS) workshop survey", , <https://ietf.iad1.qualtrics.com/jfe/form/SV_9vQxBRiZqDntarc>.
[SURVEY-INSIGHTS]
"Insights from Operator Survey & Outreach", , <https://datatracker.ietf.org/meeting/interim-2024-nemopsws-02/materials/slides-interim-2024-nemopsws-02-sessa-6-insights-from-operator-outreach-survey-03.pdf>.
[WATSEN]
Watsen, K., "Four Thoughts for How to Improve Network Management for Operators", , <https://www.ietf.org/slides/slides-nemopsws-nemops-position-paper-kent-watsen-00.pdf>.
[WILTON]
Wilton, R. and N. Corran, "Device Network Management - Current Status, and Future Direction", , <https://datatracker.ietf.org/doc/slides-nemopsws-paper-device-network-management-current-status-and-future-direction/>.

Appendix A. Operator Feedback

This section compiles the operator feedback gathered through outreach and information gathering at various operational venues (RIPE, NANOG, APRICOT, LACNIC, AutoConn, etc.). The PC synthesized this input and presented it during the workshop (see Section 3.2.2).

A.1. General

  1. In network deployments, operations are typically at the bottom of the ladder. It's the most squeezed for time and resources. Network engineers are not typically seasoned developers. The development of needed in-house tools often takes years to develop. There is a need for tools that are easy to use and just work.

  2. The vast majority of smaller operators use CLI and open source to manage their networks.

  3. There is debate fatigue. The protocol/model debate is a recurring conversation. The problem isn't going away.

  4. It was suggested that other domains (e.g., Kubernetes (K8s) / automation) are years ahead of the current network engineering stack.

  5. Support for multiple friendly, stable, and feature-rich libraries for programming languages is needed. Many DevOps routines use shell scripts, while others use a high-level programming language. In any case, on the client side, multiple programming languages are used.

  6. Screen scraping is unfortunately necessary and painful. This most often occurs when interacting with a device that only has a CLI.

  7. It was noted that there could be an outreach to Academia to establish programs to teach lessons using modern management stacks, and then a new generation of engineers could help to improve tooling and automation, with university (and/or IETF) hackathons.

A.2. Data Models

  1. In some network deployments, the focus is solely on service-level models, such that device-level protocols and device-level models are unimportant. This assumes the existence of a device adaptation layer to transcode service-level models to device-level models and conform to the device-specific protocol.

  2. There is a need for solutions to not hide vendor-specific parameters. Currently, vendors compete by differentiating their offerings in unique ways. The reason why an operator may choose a particular vendor is because of its differentiating features. Whilst standard models enable conformance, they must not hide the vendor-specific parameters. YANG deviations are a partial solution to not hiding vendor knobs.

  3. It was emphasized that streaming telemetry requires picking a model and sticking with it. It is quite a commitment, and the current environment makes the decision harder.

  4. It was noted that IETF's focus should be on defining abstract/service-level data models since it is the only thing the community may ever agree on.

  5. It was noted that navigating standard models can be difficult. A network engineer knows the vendor CLI commands but has trouble locating the corresponding leaves in the standard YANG models defined by Standards Development Organizations (SDOs).

  6. There was a wish that the IETF and OpenConfig models would merge.

Appendix B. Key Recommendations from Operator Feedback

Various recommendations were made by the operators during the outreach events. The key ones presented during the workshop were (note that there were a lot more collected):

  • Everyone: Continue to focus on model-driven management as a means to achieve automation.

  • SDOs: Re-introduce "running code" as part of the specification verification process.

  • Operators: Be actively involved with the "running code" efforts.

  • IETF: Recommend a solution stack for common use cases.

  • Technology Ambassadors: Evangelize the recommended solution stack for common cases.

  • Vendors: Support the recommended approach to the solution stack for common cases.

Appendix C. Position Papers

20 position papers were submitted to the workshop call for papers. All papers are available at <https://datatracker.ietf.org/group/nemopsws/materials/>.

This is the list of all papers:

  • J. Schönwälder: Composable, Declarative, Reproducible, Verifiable Network and Service Configurations [SCHONWALDER]

  • K. Larsson, K. Lambrechts, and I. Farrer: RFC3535, 20 Years Later from an Operator's Perspective (Deutsche Telekom) [FARRER]

  • W. Hardaker: Lessons Learned from 30 Years of Net-SNMP [HARDAKER]

  • C. Bormann: CORECONF: Managing IoT Devices with YANG Models [BORMANN]

  • R. Shakir: Rethinking Standardisation of Network Management [SHAKIR]

  • N. Warnke, R. Geib, M. Horneffer, and H. Keller: NEMOPS: RFC3535 and the forgotten word - Or Provisioning is only a subset of Network Management [KELLER]

  • J. Jiménez, S. Mansfield, R. Rodriguez A., M. Pesonen, V. Torvinen, and J. Karvonen: Evolving Challenges and Solutions in Network Management [JIMENEZ]

  • M. Boucadair, LM. Contreras, O. Gonzalez de Dios, T. Graf, R. Rahman, and L. Tailhardat: RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling [CONTRERAS]

  • T. Graf, H. Keller, D. Voyer, P. Lucente, B. Claise, R. Wilton, A. Huang-Feng, and P. Francois: Agile Incremental Driven Development for Network Management [GRAF]

  • B. Claise, T. Graf, H. Keller, D. Voyer, P. Lucente, D. Lopez, I. D. Martinez-Casanueva, B. Peters, P. Fasano, P. Ran, W. Cheng, and M. Mackey: Knowledge Graph Framework for Network Operations [CLAISE]

  • K. Watsen: Four Thoughts for How to Improve Network Management for Operators [WATSEN]

  • R. Wilton and N. Corran: Device Network Management: Current Status and Future Direction [WILTON]

  • M. Gudi, A. Pelov, L. Toutain, and J. M. Bonnin: Evolving Network Management Architecture: Integrating CORECONF with NETCONF for Efficient Telemetry and Management [GUDI]

  • P. Foroughi and L. Ciavaglia: Projecting Data Mesh to Model-driven Telemetry: A Path to Data Ecosystem's Management Operations [FOROUGHI]

  • I. D. Martinez-Casanueva: IAB NEMOPS Position Paper - Telefonica [MARTINEZ]

  • J. Jiménez: Managing IoT Devices with LwM2M [JIMENEZ-2]

  • LM. Contreras, R. Schott, S. Randriamasy, R. Yang, and J. Ros-Giralt: Towards a Unified Compute and Communication Infrastructure for Application and Network Management [GIRALT]

  • T. Eckert and M. Richardson: Resilient Remote Manageability of Wide-Area Network Infrastructures [ECKERT]

  • R. Bless: An Invariant for Future Resilient Network Management Operations [BLESS]

  • M. Scharf: Network Management Challenges for IP-based Cyber-Physical Networks [SCHARF]

Appendix D. Workshop Participants

The workshop participants were Alex Huang, Alexander Clemm, Alexander Pelov, Benoît Claise, Boris Khasanov, Brad Peters, Carsten Bormann, Chongfeng Xie, Cindy Morgan, Dan Voyer, Darren Loher, Dean Bogdanovic, Dean Bogdanović, Dhruv Dhody, Diego Lopez, Ebben Aries, Frank (Chong Feng), Holger Keller, Ian Farrer, Jaime Jimenez, James Cumming, Janne Karvonen, Jason Sterne, Jiaming Ye, Jinming Li, John Carson, Julien Maisonneuve, Jürgen Schönwälder, Kent Watsen, Kris Lambrechts, Kristian Larsson, Laurent Ciavaglia, Laurent Toutain, Liz Flynn, Luis M. Contreras, Mahesh Jethanandani, Manoj Gudi, Martin Horneffer, Matthew Bocci, Med Boucadair, Michael Mackey, Michael Richardson, Michael Scharf, Mikko Pesonen, Nacho Dominguez, Naveen Achyuta, Nick Corran, Nils Warnke, Oscar Gonzalez de Dios, Paolo Lucente, Parisa Foroughi, Per Andersson, Phil Shafer, Qin Wu, Qiufang Ma, Raquel Rodriguez, Reshad Rahman, Rob Shakir, Rob Wilton, Roland Bless, Roland Schott, Rüdiger Geib, Rui Zhuang, Ruibo Han, Sabine Randriamasy, Scott Mansfield, Scott Robohn, Shengnan Yue, Suresh Krishnan, Thomas Graf, Toerless Eckert, Wangbo, Warren Kumari, Wes Hardaker, Wim Henderickx, Xue Yang, Y. Richard Yang, Yangbo, Yisong Liu, and Zhenqiang Li.

Appendix E. Workshop Program Committee

The workshop program committee members were Wes Hardaker (co-chair), Dhruv Dhody (co-chair), Qin Wu, Suresh Krishnan, Benoît Claise, Mohamed Boucadair, Mahesh Jethanandani, Kent Watsen, and Warren Kumari.

IAB Members at the Time of Approval

Internet Architecture Board members at the time this document was approved for publication were:

  • Matthew Bocci

  • Roman Danyliw

  • Dhruv Dhody

  • Jana Iyengar

  • Cullen Jennings

  • Suresh Krishnan

  • Mirja Kühlewind

  • Warren Kumari

  • Jason Livingood

  • Mark Nottingham

  • Tommy Pauly

  • Alvaro Retana

  • Qin Wu

Acknowledgments

Thanks to Benoît Claise, Jürgen Schönwälder, Kristian Larsson, Jaime Jiménez, Michael Richardson, Phil Shafer, Mirja Kühlewind, and Roman Danyliw for helpful suggestions to improve this report.

Thanks to Alvaro Retana for shepherding this document.

Authors' Addresses

Wes Hardaker
Dhruv Dhody
RFC 9968: Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS)
Informational