Internet-Draft RFC 3535, 20 Years Later June 2024
Boucadair, et al. Expires 20 December 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-boucadair-nmop-rfc3535-20years-later-03
Published:
Intended Status:
Informational
Expires:
Authors:
M. Boucadair
Orange
L. M. C. Murillo
Telefonica
O. G. D. Dios
Telefonica
T. Graf
Swisscom
R. Rahman
Equinix

RFC 3535, 20 Years Later: An Update of Operators Requirements on Network Management Protocols and Modelling

Abstract

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

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at https://github.com/boucadair/rfc3535-20years-later.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 December 2024.

Table of Contents

1. 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" [RFC3535] which was instrumental for developing NETCONF [RFC6241], YANG [RFC6020][RFC7950], and RESTCONF [RFC8040].

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 Section 5 are provided to exemplify candidate items to discuss in that section.

2. Summary of Technology Advances Since RFC 3535

To be further elaborated:

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

3. Assessment of RFC 3535 Operator Requirements

Section 3 of [RFC3535] includes the following recommendations:

4. Assessment of RFC 3535 Recommendations

Section 6 of [RFC3535] 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 [RFC6241], RESTCONF [RFC8040], CORECONF [I-D.ietf-core-comi], 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 [RFC8791] that can be manipulated by other protocols (e.g., [RFC9132]).

  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 [RFC5706].

  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 [RFC8040] or CoAP Management Interface (CORECONF) [I-D.ietf-core-comi].

  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 [RFC6353] or [RFC9456], HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 [RFC7860]).

Section 6 of [RFC3535] 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 [RFC3084] 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 [RFC3159], as well as three Policy Information Bases ([RFC3317], [RFC3318], and [RFC3571]) to Historic status.

5. Some Observations

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

5.2. 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 [BCP127]. Another approach is to consider an approach similar to the "Roadmap for Transmission Control Protocol (TCP) Specification Documents" [RFC7414]. 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).

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

5.4. Integration Complexity

Section 3 of [RFC3535] describes a set of network operator requirements. One of the requirements is the ease of use which, according to Section 3.2 of [RFC6244], 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 [RFC8639], [RFC8640], [RFC8641], [I-D.ietf-netconf-https-notif], and [I-D.ietf-netconf-udp-notif] 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 [I-D.openconfig-rtgwg-gnmi-spec] 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 Section 4 of [RFC8641] or proposing a new YANG module being used at the YANG-Push receiver.

5.5. 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, [ODL].

5.7. (In)Consistent Data Structures in Network Protocols for Data Export

Network Telemetry, as described in [RFC9232], 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) [RFC7854] adds monitoring and tracing capabilities natively to the BGP process to minimize the processing overhead. While IPFIX [RFC7011][RFC7012] can be applied according to [RFC5472] to gain visibility into the data and forwarding planes, due to the amount of data, sampling as defined in [RFC5476] and applied to IPFIX in [RFC5477] and aggregation as defined in [RFC7015] 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.

[RFC9232] 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 Section 4.2 of [RFC7854] timestamps are optional and sysName [RFC1213] is only carried in the BMP initiation message (Section 4.3 of [RFC7854]), while the message header of IPFIX defined in Section 4.3 of [RFC7011] 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.

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

5.9. 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 [RFC3535], 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) [RFC838].

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

5.11. Too Much Time Between Publication of New Networking Functionality and the Associated YANG

For example, [RFC8667] (IS-IS extensions for SR) was published in December 2019, while [I-D.ietf-isis-sr-yang] 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.

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

6. Some Individual Assessments

This section captures some early assessments. The goal is first to capture received feedback, challenge it, and then structure it.

6.1. What Went Well

  • An overview of current and next possible technologies were given

  • Some rather technical, technology focused input from operators were collected

  • Some protocols were early on de-scoped and described why

6.2. What Went Wrong

  • Not enough implementers (software developers implementing the standards) and users (network operators using the network management software developed based on standards) were present and were well organized. That lead to standards which are technical not implementable and implementation that are not applicable or bringing not enough added value.

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

  • Closed Loop Operation and Intend Based Networking were not considered as a use case or overall non-technology related use cases were not considered.

  • Most drawn conclusions were not explained why the IETF community came to such conclusions.

  • We were looking at the past and present and not into the distant future. What do we need in 5-10 years?

6.3. Where Can Be Improved

  • Focus on use cases. What goal do we need to fulfill and who can describe best: Network Operators

  • Focus on how those use cases could be implemented best and what standards would help: Software and Data Engineers

  • Look at current standards and see wherever those standards contribute to those implementations: IETF community

  • List what is missing and analyze why it is missing: IETF community

  • Create an eco-systems of software developer and network operators which share their open source tools: IETF community

  • Mandate that no network management standard is being defined without having at least two reference implementations and help the IETF community to achieve that: IESG

7. Perspectives & Recommendations

TBC

8. Security Considerations

TBC.

9. IANA Considerations

This document has no IANA actions.

10. Informative References

[BCP127]
Best Current Practice 127, <https://www.rfc-editor.org/info/bcp127>.
At the time of writing, this BCP comprises the following:
Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, , <https://www.rfc-editor.org/info/rfc4787>.
Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, , <https://www.rfc-editor.org/info/rfc6888>.
Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, , <https://www.rfc-editor.org/info/rfc7857>.
[I-D.ietf-bmwg-containerized-infra]
Ngọc, T. M., Rao, S., Lee, J., and Y. Kim, "Considerations for Benchmarking Network Performance in Containerized Infrastructures", Work in Progress, Internet-Draft, draft-ietf-bmwg-containerized-infra-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-containerized-infra-01>.
[I-D.ietf-core-comi]
Veillette, M., Van der Stok, P., Pelov, A., Bierman, A., and C. Bormann, "CoAP Management Interface (CORECONF)", Work in Progress, Internet-Draft, draft-ietf-core-comi-17, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-17>.
[I-D.ietf-core-sid]
Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. Richardson, "YANG Schema Item iDentifier (YANG SID)", Work in Progress, Internet-Draft, draft-ietf-core-sid-24, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-24>.
[I-D.ietf-isis-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., Chen, H., and J. Tantsura, "A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane", Work in Progress, Internet-Draft, draft-ietf-isis-sr-yang-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-isis-sr-yang-21>.
[I-D.ietf-netconf-https-notif]
Jethanandani, M. and K. Watsen, "An HTTPS-based Transport for YANG Notifications", Work in Progress, Internet-Draft, draft-ietf-netconf-https-notif-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-15>.
[I-D.ietf-netconf-udp-notif]
Zheng, G., Zhou, T., Graf, T., Francois, P., Feng, A. H., and P. Lucente, "UDP-based Transport for Configured Subscriptions", Work in Progress, Internet-Draft, draft-ietf-netconf-udp-notif-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-12>.
[I-D.openconfig-rtgwg-gnmi-spec]
Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, C., and C. Morrow, "gRPC Network Management Interface (gNMI)", Work in Progress, Internet-Draft, draft-openconfig-rtgwg-gnmi-spec-01, , <https://datatracker.ietf.org/doc/html/draft-openconfig-rtgwg-gnmi-spec-01>.
[ODL]
"Graph Model Overview", , <https://docs.opendaylight.org/projects/bgpcep/en/latest/graph/graph-user-guide-graph-model.html#>.
[RFC1213]
McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, DOI 10.17487/RFC1213, , <https://www.rfc-editor.org/rfc/rfc1213>.
[RFC3084]
Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, DOI 10.17487/RFC3084, , <https://www.rfc-editor.org/rfc/rfc3084>.
[RFC3159]
McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, DOI 10.17487/RFC3159, , <https://www.rfc-editor.org/rfc/rfc3159>.
[RFC3317]
Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, "Differentiated Services Quality of Service Policy Information Base", RFC 3317, DOI 10.17487/RFC3317, , <https://www.rfc-editor.org/rfc/rfc3317>.
[RFC3318]
Sahita, R., Ed., Hahn, S., Chan, K., and K. McCloghrie, "Framework Policy Information Base", RFC 3318, DOI 10.17487/RFC3318, , <https://www.rfc-editor.org/rfc/rfc3318>.
[RFC3535]
Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, DOI 10.17487/RFC3535, , <https://www.rfc-editor.org/rfc/rfc3535>.
[RFC3571]
Rawlins, D., Kulkarni, A., Ho Chan, K., Bokaemper, M., and D. Dutt, "Framework Policy Information Base for Usage Feedback", RFC 3571, DOI 10.17487/RFC3571, , <https://www.rfc-editor.org/rfc/rfc3571>.
[RFC5472]
Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, DOI 10.17487/RFC5472, , <https://www.rfc-editor.org/rfc/rfc5472>.
[RFC5476]
Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, DOI 10.17487/RFC5476, , <https://www.rfc-editor.org/rfc/rfc5476>.
[RFC5477]
Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, , <https://www.rfc-editor.org/rfc/rfc5477>.
[RFC5706]
Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, , <https://www.rfc-editor.org/rfc/rfc5706>.
[RFC6020]
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, , <https://www.rfc-editor.org/rfc/rfc6020>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/rfc/rfc6241>.
[RFC6244]
Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, , <https://www.rfc-editor.org/rfc/rfc6244>.
[RFC6353]
Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, , <https://www.rfc-editor.org/rfc/rfc6353>.
[RFC6632]
Ersue, M., Ed. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, DOI 10.17487/RFC6632, , <https://www.rfc-editor.org/rfc/rfc6632>.
[RFC7011]
Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, , <https://www.rfc-editor.org/rfc/rfc7011>.
[RFC7012]
Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, , <https://www.rfc-editor.org/rfc/rfc7012>.
[RFC7015]
Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, DOI 10.17487/RFC7015, , <https://www.rfc-editor.org/rfc/rfc7015>.
[RFC7149]
Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, , <https://www.rfc-editor.org/rfc/rfc7149>.
[RFC7414]
Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, , <https://www.rfc-editor.org/rfc/rfc7414>.
[RFC7426]
Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, , <https://www.rfc-editor.org/rfc/rfc7426>.
[RFC7854]
Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, , <https://www.rfc-editor.org/rfc/rfc7854>.
[RFC7860]
Merkle, J., Ed. and M. Lochter, "HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3", RFC 7860, DOI 10.17487/RFC7860, , <https://www.rfc-editor.org/rfc/rfc7860>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/rfc/rfc7950>.
[RFC7951]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, , <https://www.rfc-editor.org/rfc/rfc7951>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/rfc/rfc8040>.
[RFC838]
Smallberg, D., "Who talks TCP?", RFC 838, DOI 10.17487/RFC0838, , <https://www.rfc-editor.org/rfc/rfc838>.
[RFC8568]
Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., Aranda, P., and P. Lynch, "Network Virtualization Research Challenges", RFC 8568, DOI 10.17487/RFC8568, , <https://www.rfc-editor.org/rfc/rfc8568>.
[RFC8639]
Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, , <https://www.rfc-editor.org/rfc/rfc8639>.
[RFC8640]
Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Dynamic Subscription to YANG Events and Datastores over NETCONF", RFC 8640, DOI 10.17487/RFC8640, , <https://www.rfc-editor.org/rfc/rfc8640>.
[RFC8641]
Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, , <https://www.rfc-editor.org/rfc/rfc8641>.
[RFC8667]
Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, , <https://www.rfc-editor.org/rfc/rfc8667>.
[RFC8791]
Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, , <https://www.rfc-editor.org/rfc/rfc8791>.
[RFC8969]
Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, , <https://www.rfc-editor.org/rfc/rfc8969>.
[RFC9132]
Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, DOI 10.17487/RFC9132, , <https://www.rfc-editor.org/rfc/rfc9132>.
[RFC9232]
Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, , <https://www.rfc-editor.org/rfc/rfc9232>.
[RFC9254]
Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann, C., and M. Richardson, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)", RFC 9254, DOI 10.17487/RFC9254, , <https://www.rfc-editor.org/rfc/rfc9254>.
[RFC9315]
Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, , <https://www.rfc-editor.org/rfc/rfc9315>.
[RFC9456]
Vaughn, K., Ed., "Updates to the TLS Transport Model for SNMP", RFC 9456, DOI 10.17487/RFC9456, , <https://www.rfc-editor.org/rfc/rfc9456>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Mohamed Boucadair
Orange
Luis Miguel Contreras Murillo
Telefonica
Oscar Gonzalez de Dios
Telefonica
Thomas Graf
Swisscom
Reshad Rahman
Equinix