]> Orange

mohamed.boucadair@orange.com

Telefonica

luismiguel.contrerasmurillo@telefonica.com

Telefonica

oscar.gonzalezdedios@telefonica.com

Swisscom

thomas.graf@swisscom.com

Equinix

rrahman@equinix.com

network management future networks This document identifies a list of operators requirements for network management operations. These requirements reflect advances in this field since the publication of "IAB Network Management Workshop" (RFC 3535), which was instrumental for developing many key technologies that are widely deployed. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction The IAB organized a workshop (June 4-June 6, 2002) to establish a dialog between network operators and protocol developers, and to guide the IETF to 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 and YANG , in particular. Since the publication of major advances were achieved in the network managment area, such as (but not limited to):

• NETCONF
• YANG
• RESTCONF
• SDN and Programmable Networks
• Automation
• Virtualization
• Containerization
• Intent-based
• Network APIs (e.g., )
• Models for management of services, networks, and devices
• Telemetry
• JSON Encoding of Data Modeled with YANG
• CoAP Management Interface (CORECONF)
• YANG to CBOR mapping
• YANG Schema Item iDentifier (YANG SID)

See also "An Overview of the IETF Network Management Standards" . More than 20 years later after the publication of , new requirements on network management operations are emerging from the operators. This document captures these requirements that reflect the progress in this area. For completness, the document also provides an assessment of the recommendations () and to what extent that roadmap was driving network management efforts within the IETF, in particular (). Readers may also refer to .

Observations and Operators Requirements

On the Importance of Data Models An appealing aspect about network automation techniques is that they almost apply to any kind of network. From that perspective, the functional component of a network automation framework that probably matters the most, and independent of the underlying interfaces and protocols, are the data models. Concretely, data models are instrumental in the automation of networks, service delivery, and infrastructures in general, especially that they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. Data models can be used to derive required configuration information for both network and service components, and state information that will be monitored and tracked. Likewise, they can be used during the service/network management life cycle (e.g., service instantiation, provisioning, optimization, monitoring, diagnostic, and assurance). More than three decades of "Internet standardization" have shown that the specification of data models is not that straightforward. This is because of at least two major reasons:

• For more than 30 years, legacy network equipment manufacturers have considered their technology as a competitive advantage, thereby leading to proprietary, vendor-specific, data models and the burden of vendor lock-ins. For example, there are more YANG proprietary modules than standarized ones. At the time of writing, lists 13661 unique proprietary YANG modules vs. 991 Standards modules.
• Over the same period, operators have also developed their savoir-faire as a key competitive advantage. Such savoir-faire had to rely upon these proprietary data models (and their own ones). Operators were reluctant in the past to share their design and management practices.

The situation has changed since network "softwarization" strategies have been disclosed by vendors and operators. From a business standpoint, network "softwarization" is seen as a major transformation effort by operators, because of the flexibility and the "a la carte" approach that is promoted by "X-as-a-service" (XaaS) designs, "X" being network, platform, Network Slice , etc. XaaS designs assume the availability of data models that are dynamically instantiated (along with a set of relevant policies) as a function of the "X" (and its design, for that matter). XaaS services cannot be designed, delivered, and operated without data models. Standard data models are thus key as they allow to:

• Ease mapping among many (network/service) layers.
• Ease data correlation from distinct sources.
• Soften dependency on CLI specifics to vendors.
• Support both top-down and bottom-up approaches for operating services:
• Accurate control loops for adaptive and deterministic service creation, delivery, and maintenance.
• Feed an intelligence that will drive appropriate actions to adjust the current status to align with the intended status.

OPS-REQ-STRENGTHEN-DM:

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

Particularly, without data models, a Network API is essentially useless (see also ).

Fragmented Ecosystem The current YANG device models ecosystem is fragmented: some standards data models are defined through 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.

OPS-REQ-DM-RATIONALIZE:

There is a need to rationalize this space and avoid redundant efforts.

The Network Becomes Consumable Network connectivity can support tailored services in terms of Service Level Obejctives (SLOs), for instance, by means of Network Slice Services . This approach of "consuming the network" flexibly and dynamically is made possible by enabling means of exposing network capabilities to either internal or external applications. Then, network management is no longer limited to collect network status information, but it should be extended to permit the exposure of resources, capabilities, functionality, and associated information (e.g., inventory-based data).

OPS-REQ-EASE-EXPOSURE:

Focus on protocols and data models to expose network/service capabilities, network-wide services, and related operations.

OPS-REQ-NW-API-DISCOVERY:

Define a reference approach for service exposure discovery (APIs discovery).

Network APIfication APIs are getting momentum as means of interworking between parties, also at the time of providing network services. As an example, defines an API for dynamically establishing BGP interconnection sessions between Autonomous Systems of different administrative domains. That same objective is also covered by the YANG data model defined in as exemplified in its Appendix A.10. Tools such as YANG/OpenAPI transforms are key to leverage existing data models and allow for better integration and mapping to actual realization models.

OPS-REQ-DM2API:

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

Lack of Profiling Many NETCONF-related features are (being) specified by the IETF, but these features are not widely supported (e.g., YANG-Push ). Some of these are not implemented because of the unbalance between actual operational need vs. complexity.

OPS-REQ-GUIDE-AND-PROFILE:

The target application/applicability of a network management approach should be documented (e.g., edit profile documents that outline a set of recommendations for core/key features, along with appropriate justifications, will help foster more implementations that meet operators’ needs). This also covers security management aspects of network management. Additionaly, consider independent compliance suites to validate functions/features/etc.

OPS-REQ-ARCH:

Need to promote more architecture and framework documents to exemplify the intended use.

• Examples of such profile documents are the various RFCs that were published by the Behavior Engineering for Hindrance Avoidance (behave) WG . Another approach is to consider a model similar to the "Roadmap for Transmission Control Protocol (TCP) Specification Documents" . Such a document would serve as a guide and reference for implementers and others seeking information on 'NETCONF/RESTCONF/YANG'-related RFCs.

OPS-REQ-REASSESS:

Additionally, reassessing the value of some IETF proposals compared to competing or emerging solutions (e.g., gRPC vs. YANG-Push) would be beneficial.

Lack of Agile Process for (The Maintenance of) YANG Modules RFCs might not be suited for documenting YANG modules (it takes much too long, especiallly for updates). In the meantime, there is a need for reference data models and "sufficiently stable data 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. By drawing a parallel between YANG data models and the concept of ontology used in the field of Semantic Web, the topic of YANG module maintenance could greatly benefit from proven methodologies in knowledge engineering such as and automatic documentation tools like .

OPS-REQ-QUICK-BUT-WELL:

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

Integration Complexity One of the requirements listed in is the ease of use which, according to , is claimed to be addressed by NETCONF and YANG. For configuration this holds true, for network observability it is unfortunately not yet. This has been confirmed with a set of network operators asking how long it takes from subscribing YANG data to make it accessible to the operator. Minutes, Hours, Days, or Weeks. None of them answered Minutes or Hours. All of them responded Days or Weeks. Hinting manual post processing of YANG data. Collecting YANG metrics from networks is already a struggle due to late arrival of , , , , and for configured subscription transport protocols which defined YANG-Push in the industry. This caused network vendors to implement alternative solutions to collect real-time streaming data in the meanwhile, such as gNMI which was proposed in 2018 in to the IETF but not followed up on. Unfortunately, these implementations differ between network Operating Systems (OSes) due to the lack of standardization, specifically for the metadata which would ensure machine readability. When a set of network operators where asked to where operational YANG data needs to be integrated to, the answer homogeneously was Apache Kafka Message Broker and Time Series Databases. There is a need to specify how YANG-Push can be integrated into Apache Kafka and references needed YANG-Push extensions and YANG schema registry development. The YANG-Push extensions addressing needs to make YANG-Push messages machine readable and against semantic validate able to ensure a consistent data processing. Another challenge is that the subscribed YANG data referenced with 'datastore-subtree-filter' or 'datastore-xpath-filter' breaks semantic integrity which needs to be addressed by either updating or proposing a new YANG module being used at the YANG-Push receiver.

OPS-REQ-INTEGRATION:

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

OPS-REQ-ITERATE:

Need a velocity and approach to standardization that allows for business goals to be incrementally realized.

YANG-formatted Data Manipulation The use of a flat tree hierarchy in YANG data models may induce some performance issues compared to other graph models. This can be the case, for example, during a path calculation on a network topology. Different approaches using graph theory and compatible with YANG are currently available, but require further experimentation to generalize their adoption. For instance, OpenDaylight implements an in-memory connected graph version of YANG-based data to enable fast breadth-first search (BFS).

OPS-REQ-Y2KG:

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

For example, and discuss YANG-2-KG proposals to leverage automated reasoning and graph traversal techniques.

OPS-REQ-SCALE:

Consider approaches for YANG data models to scale.

Translation and Mapping Between Service/Network and Device Models Navigating among multiple levels of the hierarchy (service, network, device) relies currently on proprietary solutions to graft and translate between two layers. There is no programmatic approach to ensure lossless mappings.

OPS-REQ-LOSSLESS:

Consider programmatic approaches to ensure lossless mappings between service/network/device data models. Means to detect, characterize, and expose loss may be considered. Note that lossless mapping is an enabler for support of deterministic verification, auditing, and tracing back along layers/models.

(In)Consistent Data Structures in Network Protocols for Data Export Network Telemetry, as described in , involve a set of protocols. Due to the different requirements, one Network Telemetry protocol doesn't address all needs. This is mainly due to the nature of the subscribed data. BGP Monitoring Protocol (BMP) adds monitoring and tracing capabilities natively to the BGP process to minimize the processing overhead. While IPFIX can be applied according to to gain visibility into the data and forwarding planes, due to the amount of data, sampling as defined in and applied to IPFIX in and aggregation as defined in for IPFIX is needed to reduce the amount of exposed data. While YANG-Push focuses on exposing already YANG modelled data, which eases the correlation among network configuration and operational data. is an informational document and does not specify what these Network Telemetry protocols should have in common to ensure consistent data structures for data export. While data types are fairly good aligned, a lack of metadata standardization among the Network Telemetry protocols is observed. In particular describing from where the metrics has been exported from and timestamping. In timestamps are optional and sysName is only carried in the BMP initiation message (), while the message header of IPFIX defined in lacks the 'sysName' definition. The lack of information from where the data is being pushed from is only known to the Network Telemetry data collection due to the transport session being established from the network node exporting the information. When Network Telemetry messages are being transformed and forwarded, this information is being lost. Therefore, it is common among network operators to augment 'sysName' and other metadata at the data collection. The same common principle applies to when observation timestamping is missing in the Network Telemetry message. Since the data collection is the closest element to the network, a time stamp is added to give the network operator at least the information when the Network Telemetry message was collected. However, since Network Telemetry addresses real-time streaming needs, this is often not accurate enough for data correlation.

OPS-REQ-REUSABILITY:

Consider approach to ensure reuse/consistent data structure.

Proprietary YANG Modules, CLI, and Limited Abstraction Leveraging on pluggins, propietary YANG data models or even CLI is still the rule in many operations, sometimes forced by the need of operating legacy infrastructures. The complexity of developing and maintaining these means of operation is huge, as it is required to to cover many OSes and vendors along the lifetime of the network device. Network models for the realization of services provide some "level" of abstraction and then allows for for more automation.

Distinct Networks, Distinct Management Requirements From the time was released up to now, new kind of services and applications have been developed and deployed over the time, with very diverse, and some times contradicting, requirements. Those services have been engineered on top of multi-service networks for the sake of efficiency and simplicity, accommodating such a variety of needs. As a result, services requiring mobility, data replication, large capacity, adaptability, multi-path support, determinism, etc., coexist on the same shared network, needing from it mechanisms for graceful operation. Likewise, such diversity of services also require different management capabilities. For example, session continuity, distribution trees, traffic engineering, congestion status notification, reordering, or on-time delivery impose very different management needs to be satisfied. This reality is different from the one existing at the time of , and as such, the new identified needs can require from novel approaches to guarantee the aforementioned co-existence of services. Some networks have specific network management requirements such as the need for asynchronous operations or constraints on data compactness. An example of such networks is Delay-Tolerant Networking (DTN) or DetNet .

OPS-REQ-NEW-NEED:

Profiling main network management technologies (e.g., recommend customized transport parameters such as timeouts and transport services) is recommended than defining network management technologies that are applicable to a single deployment context.

Implications of External Dependency Networks are being updated to abandon the silo approach from the past towards an increasing convergence. Specifically, there are trends towards a tighter interaction and integration of different technologies previously considered as totally separated from an operational perspective. Examples of that trends are the IP and Optical integration (e.g., the introduction of colored interfaces on routers), or the extension of deterministic-behavior features to Layer 3 networks. This kind of convergence in most cases creates dependencies on the conventional network management features, which require to incorporate or integrate functionality from other technological domains. Such convergence is also reflected on the need of interacting and interworking with distinct network parts participating in the end-to-end service delivery. Mobile access, fixed access, data center, enterprise, radio functional split (i.e., fronthaul and midhaul), neutral exchanges, intensive data networks (e.g., scientific academic networks), content distribution, etc., represent network parts constituent of end-to-end services that can impose dependencies of the management of an intermediate network.

OPS-REQ-UNSILO:

The convergence observed in recent years also implies the need for an up-to-date refresh of management capabilities and tools for conventional networks.

It highlights the necessity to handle the heterogeneity of data, configuration, and network management/requirements.

From a YANG perspective, this involves easily mapping and relating the data models used to manage each specific segment.

Resolving such issue 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.

Too Much Time Between Publication of New Networking Functionality and the Associated YANG For example, (IS-IS extensions for SR) was published in December 2019, while will be published ~5 years after. There are cases where modules are not published after more than a decade of WG adoption (e.g., ).

OPS-REQ-TIMELY-DM:

Consider having YANG as part of the protocol specification/change where possible, or have the YANG document progress in parallel. That may slow down the protocol specification, though.

Lack of Implementation of Proposed Solutions New solutions proposed by WGs such as NETMOD and NETCONF very often lack an implementation or only have a partial implementation. The situation has improved with the last hackathons (e.g., for YANG-Push), but these solutions became RFCs without a known implementation:

• YANG-Push
• Schema-mount
• NMDA

Schema-mount allegedly has only one known implementation because of the complexity of the solution. That means the IETF most likely spent lots of cycles for something which won't be deployed ever. While hackathons have improved the situation, the availablability of implementations is concerning. For open-source, 'sysrepo'/'libyang' are decent choices.

OPS-REQ-READILY-IMPLEM:

The availablability of implementations is concerning. Consider catalyst approaches to trigger more (open) implementations, especially during the development of protocols/extensions.

Tooling & Skills

Integration with "native" IT Tooling

OPS-REQ-IT-INTEGRATION:

There is a need to ease the integration of low-level/network-oriented solution with native "IT tooling" (e.g., "https://opentelemetry.io/").

IETF Support for Better YANG Integration

OPS-REQ-IETF-TOOLS

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

Open-source Tools While there are open-source implementations for NETCONF (e.g., NETOPEER), the gRPC/gNMI suite seems to have more support for tools on the client side. For example, "ygot" generates structures from YANG models and these can easily be used by a client to configure a device with gNMI. NETCONF is not supported though (the XML tags are needed).

OPS-REQ-CLIENT-TOOLS:

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

Skills The IETF is not the expert community in data engineering. The experts are in the data industry. Without them, integration in data processing chains like Data Mesh is going to be a challenge.

OPS-REQ-BRIDGE:

Create an eco-system where data and networking engineers can collaborate.

New Service Approaches The virtualization trend have made posible to dynamically instantiate Service Functions (SFs) in distributed compute facilities in the form of virtual machines or containers, as micro-services. The instantiation of the SFs is governed by cloud management systems, as it is the connectivity among the different instances or micro-services. That connectivity is typically realized by using overlay mechanisms, without any further interaction with the network. However, this appraoch seems to be insuficient for future services demanding stringent requirements in terms of SLOs.

OPS-REQ-GLUE:

The distinct approaches followed in both the compute and the network environments makes necessary to define suitable mechanisms for enabling an efficient interplay, while highly automating the overall service delivery procedure.

Many Solutions for the Same Problem, but Lack of Clear Applicably Guidance There are several solutions that were standardized for network management purposes. For example, management of ACLs by means to BGP FlowSpec or by means of NETCONF/YANG . There is no cross referencing between the two standards or delimits its applicability scope vs the other approach. Likewise, BGP FlowSpec did not reuse the IPFIX Information Elements.

OPS-REQ-GUIDANCE:

The target application/applicability of a network management approach should be integrated in the specification itself.

Updated Operators' Requirements

Summary

OPS-REQ-STRENGTHEN-DM:

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

OPS-REQ-DM-RATIONALIZE:

Rationalize this space and avoid redundant efforts (in almost all layers (IP, optic, etc.)). Unlike service and network models, Standard-based device models are not widely implemented.

OPS-REQ-EASE-EXPOSURE:

Focus on protocols and data models to expose network/service capabilities, network-wide services, and related operations.

OPS-REQ-NW-API-DISCOVERY:

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

OPS-REQ-DM2API:

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

OPS-REQ-GUIDE-AND-PROFILE:

The target application/applicability of a network management approach should be documented (e.g., edit profile documents that outline a set of recommendations for core/key features, along with appropriate justifications, will help foster more implementations that meet operators’ needs). This also covers security management aspects of network management. Additionaly, consider independent compliance suites to validate functions/features/etc.

OPS-REQ-ARCH:

Need to promote more arch and framework documents to exemplify the intended use.

OPS-REQ-REASSESS:

Reassess the value of some IETF proposals, including compared to competing or emerging solutions (e.g., gNMI).

OPS-REQ-QUICK-BUT-WELL:

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

OPS-REQ-INTEGRATION:

Consider approaches to ease integration by-design (e.g., protocols and data models). The integration covers both horizontal and vertical realms. For example, there is a lack of enablement of this integration across standard bodies that operators are left to solve.

OPS-REQ-ITERATE:

Need a velocity and approach to standardization that allows for business goals to be incrementally realized.

OPS-REQ-Y2KG:

Need for reference specifications to translate YANG-based data into the knowledge graph. Sample use cases to illustrate the intended use should be considered as well.

OPS-REQ-SCALE:

Consider approaches for YANG models to scale, including protocol considerations (transactions, touches, etc.). Specifically, address Telemetry scalability enhancements.

OPS-REQ-LOSSLESS:

Consider programmatic approaches to ensure lossless mappings between service/network/device data models. Means to detect, characterize, and expose loss may be considered. Note that lossless mapping is a enabler for support of deterministic verification, auditing, and tracing back along layers/models.

OPS-REQ-REUSABILITY:

Consider approaches to ensure reuse/consistent data structure across various NM segments. This will ease correlating data learned from different means (IPFIX, BMP, SYSLOG, etc.).

OPS-REQ-NEW-NEED:

Profiling main network management technologies (e.g., recommend customized transport parameters such as timeouts and transport services) is recommended than defining network management technologies that are applicable to a single deployment context.

OPS-REQ-UNSILO:

Necessity to handle the heterogeneity of data, configuration, and network management/requirements. Resolving such issue 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.

OPS-REQ-TIMELY-DM:

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

OPS-REQ-READILY-IMPLEM:

The availability of implementation is concerning. Consider catalyst approaches to trigger more (open) implementations, especially during the development of protocols/extensions.

OPS-REQ-IT-INTEGRATION:

There is a need to ease the integration of low-level/network-oriented solution with native "IT tooling" (e.g., https://opentelemetry.io/).

OPS-REQ-IETF-TOOLS:

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

OPS-REQ-CLIENT-TOOLS:

Focus on tooling is needed, especially on the client side. There is a need for tools that are easy to use. Likewise, there is need for support for multiple friendly, stable, and feature-rich libraries for programming languages.

OPS-REQ-BRIDGE:

Create an eco-system where data and networking engineers can collaborate.

OPS-REQ-GLUE:

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

OPS-REQ-GUIDANCE:

The target application/applicability of a network management approach should be integrated in the specification itself.

Categorization provides a classification of the requirements listed in .It specifically tag whether a requirement:

• Belongs to data modeling (DM)
• Requires protocol work (Protocol)
• Impacts deployability of standardized approaches (Deployability)
• Has implications on integration effort by operators (Integration)
• Requires some adaptations to an SDO process (SDO Process)
• Allows better coordination (Collaboration & Cooperation)
• Is relevant to skills transformations (Skills)

Requirements Classification

Ops Requirement Label	DM	Protocol	Deployability	Integration	SDO Process	Collaboration & Cooperation	Skills
OPS-REQ-STRENGTHEN-DM	X		X
OPS-REQ-DM-RATIONALIZE	X		X		X	X
OPS-REQ-EASE-EXPOSURE	X	X	X	X
OPS-REQ-NW-API-DISCOVERY			X	X
OPS-REQ-DM2API			X
OPS-REQ-GUIDE-PROFILE	X	X	X
OPS-REQ-ARCH		X	X
OPS-REQ-REASSESS		X
OPS-REQ-QUICK-BUT-WELL	X	X	X
OPS-REQ-INTEGRATION			X	X	X
OPS-REQ-ITERATE					X	X
OPS-REQ-Y2KG			X	X
OPS-REQ-SCALE	X	X
OPS-REQ-LOSSLESS			X	X	X
OPS-REQ-REUSABILITY		X		X	X
OPS-REQ-NEW-NEED		X
OPS-REQ-UNSILO			X	X
OPS-REQ-TIMELY-DM	X		X
OPS-REQ-READILY-IMPLEM	X	X	X		X
OPS-REQ-IT-INTEGRATION			X	X
OPS-REQ-IETF-TOOLS					X		X
OPS-REQ-CLIENT-TOOLS			X	X			X
OPS-REQ-BRIDGE						X	X
OPS-REQ-GLUE				X			X
OPS-REQ- GUIDANCE			X

Overall New Requirements Levels: Operators View provides the requirement level of from an operator perspective. Operators Requirements Levels

Ops Requirement Label	Overall Level
OPS-REQ-STRENGTHEN-DM	Strong
OPS-REQ-DM-RATIONALIZE	Strong
OPS-REQ-EASE-EXPOSURE	Strong
OPS-REQ-NW-API-DISCOVERY	Nice to have
OPS-REQ-DM2API	Strong
OPS-REQ-GUIDE-AND-PROFILE	Nice to have
OPS-REQ-ARCH	Strong
OPS-REQ-REASSESS	Strong
OPS-REQ-QUICK-BUT-WELL	Strong
OPS-REQ-INTEGRATION	Strong
OPS-REQ-ITERATE	Strong
OPS-REQ-Y2KG	Nice to have
OPS-REQ-SCALE	Strong
OPS-REQ-LOSSLESS	Nice to have
OPS-REQ-REUSABILITY	Strong
OPS-REQ-NEW-NEED	Nice to have
OPS-REQ-UNSILO	Strong
OPS-REQ-TIMELY-DM	Strong
OPS-REQ-READILY-IMPLEM	Strong
OPS-REQ-IT-INTEGRATION	Nice to have
OPS-REQ-IETF-TOOLS	Nice to have
OPS-REQ-CLIENT-TOOLS	Strong
OPS-REQ-BRIDGE	Strong
OPS-REQ-GLUE	Nice to have
OPS-REQ-GUIDANCE	Nice to have

Consolidated Requirements This section provides a consolidated view of main requirements that takes into account inputs from actors beyond operators:

• Put more focus on service and network data models (OPS-REQ-STRENGTHEN-DM) while ensuring that the realization of these abstractions can be easily correlated with underlying functionalities (OPS-REQ-INTEGRATION)
• Progress much faster (OPS-REQ-QUICK-BUT-WELL, OPS-REQ-TIMELY-DM)
• Implement minimal functionality, not bells and whistles (OPS-REQ-ITERATE)
• Have running code while a specification is under development (OPS-REQ-READILY-IMPLEM, OPS-REQ-TOOLS)
• Have vendors and operators on board at the time of developing the solution
• Provide independent compliance suites to validate features (OPS-REQ-GUIDE-AND-PROFILE)
• Need for means to correlate data learned from different means (OPS-REQ-REUSABILITY)
• Investigate approaches to ease adoption and integration into an operator’s environments (OPS-REQ-EASE-EXPOSURE, OPS-REQ-DM2API, OPS-REQ-INTEGRATION)
• Network-centric approaches have limits, need to better integrate and learn from techniques in other domains (OPS-REQ-BRIDGE).

Security Considerations This document does not define any protocol or architecture.

IANA Considerations This document has no IANA actions.

References Normative 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. Informative References 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). Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment. It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification. Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations. Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG). Electronics and Telecommunications Research Institute Electronics and Telecommunications Research Institute The Linux Foundation Soongsil University Soongsil University Recently, the Benchmarking Methodology Working Group extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). With the ongoing shift in network function implementation from virtual machine-based to container-based approaches, system configurations and deployment scenarios for benchmarking will be partially influenced by how resource allocation and network technologies are specified for containerized network functions. This draft outlines additional considerations for benchmarking network performance when network functions are containerized and executed on general-purpose hardware. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments. This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. Trilliant Networks Inc. consultant IMT Atlantique 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. YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). Trilliant Networks Inc. IMT Atlantique Google Switzerland GmbH Universität Bremen TZI Sandelman Software Works YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items, as a more compact method to identify YANG items that can be used for efficiency and in constrained environments (RFC 7228). This document defines the semantics, the registration, and assignment processes of YANG SIDs for IETF managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. // The present version (–24) is intended to address the remaining // IESG comments. 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. 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. This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. Amazon FullCtl Meta Google Cloudflare AS207960 Cyfyngedig We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods. Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as a "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., RFC 9543 Network Slice Service). The document also specifies a YANG service data model for managing bearers over which ACs are established. This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. 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. This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes. This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. Kloud Services Watsen Networks This document defines a protocol for sending asynchronous event notifications similar to notifications defined in RFC 5277, but over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. INSA-Lyon INSA-Lyon Huawei Swisscom NTT This document describes a UDP-based transport for YANG notifications to collect data from network nodes within a controlled environment. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enables higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. Google Google Google Google Google Google This document describes the gRPC Network Management Interface (gNMI), a network management protocol based on the gRPC framework. gNMI supports retrieval and manipulation of state from network elements where the data is represented by a tree structure, and addressable by paths. The gNMI service defines operations for configuration management, operational state retrieval, and bulk data collection via streaming telemetry. The authoritative gNMI specification is maintained at [GNMI-SPEC]. Telefonica Telefonica NICT The success of the YANG language and YANG-based protocols for managing the network has unlocked new opportunities in network analytics. However, the wide heterogeneity of YANG models hinders the consumption and analysis of network data. Besides, data encoding formats and transport protocols will differ depending on the network management protocol supported by the network device. These challenges call for new data management paradigms that facilitate the discovery, understanding, integration and access to silos of heterogenous YANG data, abstracting from the complexities of the network devices. This document introduces the knowledge graph paradigm as a solution to this data management problem, with focus on YANG-based network management. The document provides background on related topics such as ontologies and graph standards, and shares guidelines for implementing knowledge graphs from YANG data. Orange Research EURECOM Orange Research Orange Research Orange Research TiDB Operational efficiency in incident management in networking requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge Graphs (KG) can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management Knowledge Graph (ITSM-KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102. In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks. This memo provides information for the Internet community. This document specifies the export of packet information from a Packet SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process. For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. [STANDARDS-TRACK] This memo defines an information model for the Packet SAMPling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK] This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP-based internets. [STANDARDS-TRACK] This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83. This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties. Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane. Cisco Systems Futurewei Technologies LabN Consulting, L.L.C. The MITRE Corporation Nvidia This document defines a YANG data model that can be used to manage IS-IS Extensions for Segment Routing over the MPLS data plane. Kloud Services Arrcus Huawei HPE This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document. The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624. The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text. This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services. The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. Orange Juniper Telefonica Nokia Huawei Technologies Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a YANG service model for managing bearers over which ACs are established. Orange Juniper Telefonica Nokia Huawei Technologies This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). This document defines a Remote Procedure Call (RPC) operation to compare management datastores that comply with the Network Management Datastore Architecture (NMDA). The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes YANG mechanisms for defining abstract data structures with YANG. This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. This document obsoletes RFC 8782. 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. 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.

Assessment of RFC 3535 Operator Requirements

Detailed Analysis includes the following recommendations: 3535-OPS-REQ-EASE-USE:

Status Update:

This is still a valid requirement. It is even exacerbated with the amount of techniques and extensions that were specified since then.

3535-OPS-REQ-CONFIG-OPS-SEPARATE:

Status Update:

This requirement was taken into account when designing IETF solutions. Specifically, datastores are a fundamental concept in NETCONF/YANG (e.g., ).

3535-OPS-REQ-CONFIG-OPS-FETCH-SEPARATE:

Status Update:

This is supported by NETCONF and RESTCONF.

3535-OPS-REQ-NETWORK-NOT-DEVICE:

Status Update:

Protocols such as NETCONF supports means to handle transactions at the level of a network. For example, a controller can establish parallel sessions with a set of devices and make use of confirmed commit.

Also, describes how YANG/RESTONF/YANG can be used to manage a network and map it to involves underlying functions/nodes. Several service and network data models are required for this aim.

The IETF defined in the past models to manage few servcies such as VPN at both service and network levels (e.g., the Layer 2 Service Model (L2SM) , the Layer 3 Service Model (L3SM) , the Layer 2 Network Model (L2NM) , and the Layer 3 Network Model (L3NM) ).

A similar effort is currently ongoing for handling attachement circuits at both service and network layers (e.g., , ).

More effort is still needed in this area.

3535-OPS-REQ-NETWORK-WIDE-TRANSACTIONS:

Status Update:

This feature is supported by NETCONF.

3535-OPS-REQ-CONFIG-DIFF:

Status Update:

This feature is supported by NETCONF.

3535-OPS-REQ-CONFIG-DUMP-RESTORE:

Status Update:

This feature is supported by NETCONF.

3535-OPS-REQ-CONFIG-CONSISTENCY-CHECK:

Status Update:

A mechanism is specified in .

3535-OPS-REQ-CONFIG-NETWORK-WIDE-SCHEMA:

Status Update:

Covered by current implementations.

3535-OPS-REQ-TXT-PROCESSING-TOOLS:

Status Update:

This is deployment-specific.

3535-OPS-REQ-ACCESS-CONTROL-OPS-CENTRIC:

Status Update:

Role-based Access Control (RBAC) is supported by existing implementation. Also, the IETF defined for this purpose.

3535-OPS-REQ-ACCESS-CONTROL-CHECKS:

Status Update:

This is implementation-specific.

3535-OPS-REQ-CONFIG-SEPARATE-DISTRIB-ACTIV:

Status Update:

This is supported by existing NETCONF methods.

3535-OPS-REQ-ACCESS-CONTROL-BOTH-DATA-TASK:

Status Update:

This is supported by .

Summary

RFC3535 Ops Requirement Label	Status
3535-OPS-REQ-EASE-USE	Still Applicable
3535-OPS-REQ-CONFIG-OPS-SEPARATE	A solution was standarized
3535-OPS-REQ-CONFIG-OPS-FETCH-SEPARATE	A solution was standarized
3535-OPS-REQ-NETWORK-NOT-DEVICE	Protocol (OK), DM (Still Applicable)
3535-OPS-REQ-NETWORK-WIDE-TRANSACTIONS	A solution was standarized
3535-OPS-REQ-CONFIG-DIFF	A solution was standarized
3535-OPS-REQ-CONFIG-DUMP-RESTORE	A solution was standarized
3535-OPS-REQ-CONFIG-CONSISTENCY-CHECK	Implementation-specific
3535-OPS-REQ-CONFIG-NETWORK-WIDE-SCHEMA	Still Applicable
3535-OPS-REQ-TXT-PROCESSING-TOOLS	Deployment-specific
3535-OPS-REQ-ACCESS-CONTROL-OPS-CENTRIC	Implementation-specific
3535-OPS-REQ-ACCESS-CONTROL-CHECKS	Implementation-specific
3535-OPS-REQ-CONFIG-SEPARATE-DISTRIB-ACTIV	A solution was standarized
3535-OPS-REQ-ACCESS-CONTROL-BOTH-DATA-TASK	A solution was standarized

Assessment of RFC 3535 Recommendations

Detailed Analysis includes the following recommendations: 3535-RECO-STOP-MANDATE-MIB:

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.

3535-RECO-MIB-INVESTIGATE:

Status Update:

No such a group was formed in the IETF.

3535-RECO-SNMP-WG4MONITORING:

Status Update:

No such a group was formed in the IETF.

3535-RECO-FOCUS-IETF-CONFIG-MECHANISMS:

Status Update:

The IETF specified NETCONF , RESTCONF , CORECONF , and YANG.

YANG is a transport-independent data modeling language. It can be used independently of NETCONF/RESTCONF. For example, YANG can be used to define abstract data structures that can be manipulated by other protocols (e.g., ).

3535-RECO-FOCUS-XML:

Status Update:

This recommendation was followed in base specifications. This recommendation was also mirrored in other documents such as .

However, the IETF integrated support for other encoding such as JSON.

3535-RECO-NO-HTTP:

Status Update:

The IETF deviated from this recommendation, e.g., RESTCONF or CoAP Management Interface (CORECONF) .

3535-RECO-MAINTAIN-SMI-SPPI:

Status Update:

SMIng WG was concluded in 2003-04-04.

3535-RECO-IETF2FIX-MIB:

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: 3535-MISC-NO-CIM:

Status Update:

The IETF didn't dedicate any resources on CIM extensions.

3535-MISC-ABANDON-PIB:

Status Update:

The IETF has reclassified COPS Usage for Policy Provisioning to Historic status.

3535-MISC-ABANDON-COPS-PR:

Status Update:

The IETF has reclassified Structure of Policy Provisioning Information , as well as three Policy Information Bases (, , and ) to Historic status.

Summary

RFC3535 Recommendation Label	Status
3535-RECO-STOP-MANDATE-MIB	Done, IESG Statement on Writable MIB Module (2014)
3535-RECO-MIB-INVESTIGATE	No such a group was formed
3535-RECO-SNMP-WG4MONITORING	No such a group was formed
3535-RECO-FOCUS-IETF-CONFIG-MECHANISMS	NETCONF/RESTCONF/CORECONF/YANG/COMI/etc.
3535-RECO-FOCUS-XML	The recommendation was followed
3535-RECO-NO-HTTP	The IETF deviated from this recommendation, e.g., RESTCONF or CoAP Management Interface (CORECONF)
3535-RECO-MAINTAIN-SMI-SPPI	SMIng WG was concluded in 2003-04-04
3535-RECO-IETF2FIX-MIB	The IETF dedicated resources to fix some SNMP shortcomings with a focus on security
3535-MISC-NO-CIM	The IETF didn't dedicate any resources on CIM extensions
3535-MISC-ABANDON-COPS-PR	The IETF has reclassified COPS-PR to Historic status
3535-MISC-ABANDON-PIB	The IETF has reclassified SPPI, as well as three PIBs to Historic status

Acknowledgments Thanks to Christian Jacquenet and Jean-Michel Combes for their inputs. Thanks to Benoît Claise and Alex Clemm for the comments. Many of the requirements were extracted from contributions to the IAB Next Era of Network Management Operations (NEMOPS) Workshop . Thanks to Ian Farrer, Brad Peters, Chongfeng Xie, and Qin Wu for their contribution to consolidate the requirements.

Contributors Orange

lionel.tailhardat@orange.com