]> Orange

mohamed.boucadair@orange.com

Telefonica

luismiguel.contrerasmurillo@telefonica.com

Telefonica

oscar.gonzalezdedios@telefonica.co

Swisscom

thomas.graf@swisscom.com

Equinix

rrahman@equinix.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 Advances Since RFC 3535 To be further elaborated:

• NETCONF
• YANG
• RESTCONF
• SDN & Programmable Networks
• Automation
• Virtualization
• Containerization
• Intent-based
• Network APIs
• 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" .

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.

   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., ).

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 or ONF. 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.

Lack of Profiling Many NETCONF-related features are (being) specified by the IETF, but these features 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 the various RFCs that were published by the behave WG . Another approach is to consider an approach similar to the "Roadmap for Transmission Control Protocol (TCP) Specification Documents" . Such a document would serve as a guide and reference for implementers and any other parties who desire information contained in the 'NETCONF/RESTCONF/YANG'-related RFCs.

Likewise, reassess the value of some IETF proposals vs. competing/emerging solutions would be useful (e.g., gRPC vs. YANG-Push).

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 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 describes a set of network operator requirements. One of the requirements is the ease of use which, according to , is 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 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.

YANG-formatted Data Manipulation The use of a flat tree hierarchy in YANG models may induce some performance issues compared to other graph models. See, for example, .

Translation and Mapping Between Service/Network and Device Models TBC.

(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.

Proprietary YANG Modules, CLI, and Limited Abstraction Pluggins/Proxy YANG/CLI is still the rule in many operations. Complexity in dev the pluggins (as you need to cover many OS/vendors). Network models for the realization provides some "level" of abstraction and then automations. TBC.

Distinct Networks, Distinct Management Requirements From the time RFC 3535 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. Also, 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) .

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. Furthermore, 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. That convergence shown the last years also implies the need of an up-to-date refresh of management capabilities and tooling of the conventional networks. Also, it highlights the need to easily map the data models that are used to manage each specific segment.

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. 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.

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 (we need the XML tags).

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). 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). Soongsil University The Linux Foundation Soongsil University Soongsil University Recently, the Benchmarking Methodology Working Group has extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). Considering the network function implementation trend moving from virtual machine-based to container- based, system configurations and deployment scenarios for benchmarking will be partially changed by how the resources allocation and network technologies are specified for containerized network functions. This draft describes additional considerations for benchmarking network performance when network functions are containerized and performed in 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. 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. 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. 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 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 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. Huawei Huawei Swisscom INSA-Lyon INSA-Lyon NTT This document describes a UDP-based protocol for YANG notifications to collect data from network nodes. A shim header is proposed to facilitate the data streaming directly from the publishing process on network processor of line cards to receivers. The objective is to provide a lightweight approach to enable higher frequency and less performance impact on publisher and receiver processes compared to already established notification mechanisms. 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]. 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. 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 Individual The MITRE Corporation Nvidia This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane.

Acknowledgments TODO acknowledge.