]> Orange

mohamed.boucadair@orange.com

network management future networks The IAB has organized an important workshop to establish a dialog between network operators and protocol developers, and to guide the IETF focus on work regarding network management. The outcome of that workshop was documented in the "IAB Network Management Workshop" (RFC 3535) which was instrumental for developing NETCONF and YANG, in particular. 20 years later, it is time to evaluate what has been achieved since then and identify the operational barriers for making these technologies widely implemented. Also, this document intends to capture new requirements for network management operations. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction The IAB has organized a workshop (June 4-June 6, 2002) to establish a dialog between network operators and protocol developers, and to guide the IETF focus on work regarding network management. The outcome of that workshop was documented in the "IAB Network Management Workshop" which was instrumental for developing NETCONF , YANG , and RESTCONF . 20 years later, new requirements on network management operations are emerging from the operators. This document intends to capture these requirements that reflect the progress in this area. The document also provide an assessment of the RFC3535 recommendations and to what extend that roadmap was driving network management efforts within the IETF. Early version of the document includes many placeholders on purpose as the intent is to collect inputs from interested parties. Items listed in are provided to exemplify candidate items to discuss in that section.

Summary of Technology Advences Since RFC 3535 To be further elaborated:

• NETCONF
• YANG
• RESTCONF
• SDN & Programmable Networks
• Automation
• Virtualization
• Containerization
• Intent-based
• Network APIs
• Telemetry

See also "An Overview of the IETF Network Management Standards" .

Assessment of RFC 3535 Recommendations includes the following recommendations:

1. The workshop recommends that the IETF stop forcing working groups to provide writable MIB modules. It should be the decision of the working group whether they want to provide writable objects or not. Status Update: In 2014, the IESG published a statement Writable MIB Module, which states that: > SNMP MIB modules creating and modifying configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration, and in consultation with the OPS ADs/MIB doctors.
2. The workshop recommends that a group be formed to investigate why current MIB modules do not contain all the objects needed by operators to monitor their networks. Status Update: xxx
3. The workshop recommends that a group be formed to investigate why the current SNMP protocol does not satisfy all the monitoring requirements of operators. Status Update: xxx
4. The workshop recommends, with strong consensus from both protocol developers and operators, that the IETF focus resources on the standardization of configuration management mechanisms. Status Update: NETCONF, RESTCONF, CORECONF, YANG.
5. The workshop recommends, with strong consensus from the operators and rough consensus from the protocol developers, that the IETF/IRTF should spend resources on the development and standardization of XML-based device configuration and management technologies (such as common XML configuration schemas, exchange protocols and so on). Status Update: OK. This recommendation was also mirrored in other documents such as .
6. The workshop recommends, with strong consensus from the operators and rough consensus from the protocol developers, that the IETF/IRTF should not spend resources on developing HTML-based or HTTP-based methods for configuration management. Status Update: The IETF deviated from this recommendation, e.g., RESTCONF or CoAP Management Interface (CORECONF) .
7. The workshop recommends, with rough consensus from the operators and strong consensus from the protocol developers, that the IETF should continue to spend resources on the evolution of the SMI/SPPI data definition languages as being done in the SMIng working group. Status Update: SMIng WG was concluded in 2003-04-04.
8. The workshop recommends, with split consensus from the operators and rough consensus from the protocol developers, that the IETF should spend resources on fixing the MIB development and standardization processs. Status Update: The IETF dedicated some resources to fix some SNMP shortcomings with a focus on security (e.g., Transport Layer Security (TLS) Transport Model for the SNMP or , HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 ).

also includes the following but without tagging them as recommendations:

1. The workshop had split consensus from the operators and rough consensus from the protocol developers, that the IETF should not focus resources on CIM extensions. Status Update: The IETF didn't dedicate any resources on CIM extensions.
2. The workshop had rough consensus from the protocol developers that the IETF should not spend resources on COPS-PR development. So far, the operators have only very limited experience with COPS-PR. In general, however, they felt that further development of COPS-PR might be a waste of resources as they assume that COPS-PR does not really address their requirements. Status Update: The IETF has reclassified COPS Usage for Policy Provisioning to Historic status.
3. The workshop had rough consensus from the protocol developers that the IETF should not spend resources on SPPI PIB definitions. The operators had rough consensus that they do not care about SPPI PIBs. Status Update: The IETF has reclassified Structure of Policy Provisioning Information , as well as three Policy Information Bases (, , and ) to Historic status.

Some Observations

Fragmented Ecosystem The current YANG device models ecosystem is fragmented: some standards models are defined in the IETF while similar ones are defined in other fora such as Openconfig. Unlike service and network models, IETF-defined device models are not widely implemented. There is a need to rationalize this space and avoid redundant efforts.

Need for Profiling Many NETCONF-related tools are (being) specified by the IETF, but these tools are not widely supported (e.g., Push). Editing a profile document with a set of recommendations about core/key features with the appropriate justification will help the emergence of more implementations that meet the operators’ needs. Examples of such profile documents are RFCs that were published by the behave WG . Likewise, reassess the value of some IETF proposals vs. competing/emerging solution would be useful.

Lack of Agile Process for YANG Modules RFCs might not be suited for documenting YANG modules. In the meantime, there is a need for "reference models" and "sufficiently stable models". An hybrid approach might be investigated for documenting IETF- endorsed YANG modules, such as considering an RFC to describe the initial module sketch and objectives and an official IETF repository for maintaining intermediate YANG versions.

Integration Complexity TBC.

YANG-formatted Data Manipulation TBC.

Another Item TBC.

Another Item TBC.

Perspectives & Recommendations TBC

Security Considerations TBC

IANA Considerations This document has no IANA actions.

Informative References This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide the IETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. This memo provides information for the Internet community. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. This document is not an Internet Standards Track specification; it is published for informational purposes. New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. This memo provides information for the Internet community. Trilliant Networks Inc. consultant Acklio YumaWorks Universität Bremen TZI This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of an SNMP Transport Subsystem to make this protection possible in an interoperable way. This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS-TRACK] This document updates RFC 6353 ("Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)") to reflect changes necessary to support Transport Layer Security version 1.3 (TLS 1.3) and Datagram Transport Layer Security version 1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3". This document is compatible with (D)TLS 1.2 and is intended to be compatible with future versions of SNMP and (D)TLS. This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353. This document specifies several authentication protocols based on the SHA-2 hash functions for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIB MODULE-IDENTITY value was incorrectly specified. This document describes the use of the Common Open Policy Service (COPS) protocol for support of policy provisioning (COPS-PR). [STANDARDS-TRACK] This document, the Structure of Policy Provisioning Information (SPPI), defines the adapted subset of SNMP's Structure of Management Information (SMI) used to write Policy Information Base (PIB) modules. [STANDARDS-TRACK] This document defines a set of PRovisioning Classes (PRCs) and textual conventions that are common to all clients that provision policy using Common Open Policy Service (COPS) protocol for Provisioning. Structure of Policy Provisioning Information (SPPI) describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined (PRCs) and instances of these classes (PRIs) residing in a virtual information store called the Policy Information Base (PIB). One way to provision policy is by means of the (COPS) protocol with the extensions for provisioning. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS, virtual private networks, or security. As described in COPS usage for Policy Provisioning (COPS-PR), each client supports a non-overlapping and independent set of PIB modules. However, some PRovisioning Classes are common to all subject-categories (client-types) and need to be present in each. This document describes a portion of the Policy Information Base (PIB) to control policy usage collection and reporting in a device. The provisioning classes specified here allow a Policy Decision Point (PDP) to select which policy objects should collect usage information, what information should be collected and when it should be reported. This PIB requires the presence of other PIBs (defined elsewhere) that provide the policy objects from which usage information is collected. This memo provides information for the Internet community. This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787. This document clarifies and updates several requirements of RFCs 4787, 5382, and 5508 based on operational and development experience. The focus of this document is Network Address Translation from IPv4 to IPv4 (NAT44). This document updates RFCs 4787, 5382, and 5508.

Acknowledgments TODO acknowledge.