RFC 8993

A Reference Model for Autonomic Networking ✨

okay bestie, this is RFC 8993 🎀 and it's an Informational doc, which means it's published to share knowledge and is not a standards-track spec 🌸. It came out in May 2021 and the ISSN is 2070-1721 🍓. The authors are M. Behringer (who is also the editor 💅), B. Carpenter from Univ. of Auckland, T. Eckert from Futurewei USA, L. Ciavaglia from Nokia, and J. Nobre from UFRGS. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈.

Abstract

so the abstract is giving "here's our reference model for Autonomic Networking in managed networks" ✨. It explains how an autonomic node behaves, how all the pieces in an autonomic setup work together, and how autonomic services can use the infrastructure underneath them 🧚.

Status of This Memo

this section is the official "what kind of doc is this" part 📋. This document is not an Internet Standards Track specification. It's published for informational purposes 🦋.

It is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 💜. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🤓.

If you want the current status, any errata, or a way to send feedback, go to https://www.rfc-editor.org/info/rfc8993 🔥.

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved 💅.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they were in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🫶.

Table of Contents

   1.  Introduction
   2.  Network View
   3.  Autonomic Network Element
     3.1.  Architecture
     3.2.  Adjacency Table
     3.3.  State Machine
       3.3.1.  State 1: Factory Default
       3.3.2.  State 2: Enrolled
       3.3.3.  State 3: In ACP
   4.  Autonomic Networking Infrastructure
     4.1.  Naming
     4.2.  Addressing
     4.3.  Discovery
     4.4.  Signaling between Autonomic Nodes
     4.5.  Routing
     4.6.  Autonomic Control Plane
     4.7.  Information Distribution (*)
   5.  Security and Trust Infrastructure
     5.1.  Public Key Infrastructure
     5.2.  Domain Certificate
     5.3.  MASA
     5.4.  Subdomains (*)
     5.5.  Cross-Domain Functionality (*)
   6.  Autonomic Service Agents (ASAs)
     6.1.  General Description of an ASA
     6.2.  ASA Life-Cycle Management
     6.3.  Specific ASAs for the Autonomic Networking Infrastructure
       6.3.1.  Enrollment ASAs
       6.3.2.  ACP ASA
       6.3.3.  Information Distribution ASA (*)
   7.  Management and Programmability
     7.1.  Managing a (Partially) Autonomic Network
     7.2.  Intent (*)
     7.3.  Aggregated Reporting (*)
     7.4.  Feedback Loops to NOC (*)
     7.5.  Control Loops (*)
     7.6.  APIs (*)
     7.7.  Data Model (*)
   8.  Coordination between Autonomic Functions (*)
     8.1.  Coordination Problem (*)
     8.2.  Coordination Functional Block (*)
   9.  Security Considerations
     9.1.  Protection against Outsider Attacks
     9.2.  Risk of Insider Attacks
   10. IANA Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Acknowledgements
   Contributors
   Authors' Addresses

1. Introduction ✨

okay so the first thing to know is that [RFC7575] is the big-picture explainer 📖. It covers the core concepts of Autonomic Networking, defines the terms, and gives a high-level reference model 💖. [RFC7576] is the gap analysis that compares traditional approaches with autonomic ones 👑.

this document takes that high-level model and makes it more detailed 🧚. The goal is that functional and protocol specs can be built on top of it in a way that's architecturally consistent and doesn't overlap 💅.

As [RFC7575] points out, the point isn't to only focus on fully autonomic nodes or networks 🌈. Realistically, most networks will have some autonomic functions while the rest are managed the traditional way 🦋. This reference model is built to handle that hybrid setup 🫶.

for example, an existing non-autonomic network can enroll devices the old-school way to set up a trust infrastructure with certificates 🎀. That trust infrastructure can then be used to bring up an Autonomic Control Plane (ACP) automatically, and traditional network operations can run over that secure, self-healing ACP 🔥. See [RFC8368] for this use case 💜.

the scope here is networks that are at least partly managed by skilled human operators, which people loosely call "professionally managed" networks 🍓. Unmanaged networks bring extra security and trust issues that this model doesn't cover 🙈.

this document describes the first phase of an Autonomic Networking solution that is both simple and implementable ⭐. The experience from this phase is expected to feed into updated and extended specs over time 🌸. Some topics are considered architecturally in this document but aren't reflected in the implementation specs yet 😭. Those are marked with an (*) 💅.

2. Network View 🌍

this section gives the high-level picture of the elements in a network with autonomic functions, and how they work together 🧚. The later sections dig into the detailed inside view of each Autonomic Network element, and also into the network functions (or interfaces) between those elements 💖.

Figure 1 shows the high-level view of an Autonomic Network 🎀. It's made up of a bunch of autonomic nodes that talk directly to each other 🦋. Together those nodes provide a shared set of capabilities across the network, called the "Autonomic Networking Infrastructure (ANI)" ✨. The ANI handles things like naming, addressing, negotiation, synchronization, discovery, and messaging 🫶.

Autonomic functions usually span several nodes, maybe all of them 🌈. The atomic entities of an autonomic function are called the "Autonomic Service Agents (ASAs)", and they get instantiated on nodes 👑.

+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
:            :       Autonomic Function 1        :                 :
: ASA 1      :      ASA 1      :      ASA 1      :          ASA 1  :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
             :                 :                 :
             :   +- - - - - - - - - - - - - - +  :
             :   :   Autonomic Function 2     :  :
             :   :  ASA 2      :      ASA 2   :  :
             :   +- - - - - - - - - - - - - - +  :
             :                 :                 :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
:                Autonomic Networking Infrastructure               :
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
+--------+   :    +--------+   :    +--------+   :        +--------+
| Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n |
+--------+   :    +--------+   :    +--------+   :        +--------+

          Figure 1: High-Level View of an Autonomic Network

so picture it horizontally: autonomic functions stretch across the whole network, and so does the ANI 🌸. Vertically, every node always runs the ANI, and it can also run one or several ASAs on top 🧁. ASAs can stand on their own or use other ASAs in a hierarchy 💜.

that's why the ANI is the foundation for all the autonomic functions 🏰✨.

3. Autonomic Network Element 🤖

this section explains the general architecture of an Autonomic Network element (Section 3.1) 🎀. It also covers how the element keeps track of its surroundings in an adjacency table (Section 3.2) 🦋. And then there's the state machine that defines how the network element behaves, based on that adjacency table (Section 3.3) 💅.

more to come next part, bestie! 🫶🌷

3.1. Architecture 🏗️✨

okay so this section is about what an Autonomic Network element looks like on the inside, and it's giving layers 💅. The reference model in [RFC7575] shows where an ASA (Autonomic Service Agent) can get its info from: self-knowledge, network knowledge (through discovery), Intent (see Section 7.2), and feedback loops 🧠. Inside an autonomic node there are two levels: the ASAs on top, and the ANI underneath, with the ASAs using the ANI's services. Figure 2 shows the whole vibe 👇

+------------------------------------------------------------+
|                                                            |
| +-----------+        +------------+        +------------+  |
| | Autonomic |        | Autonomic  |        | Autonomic  |  |
| | Service   |        | Service    |        | Service    |  |
| | Agent 1   |        | Agent 2    |        | Agent 3    |  |
| +-----------+        +------------+        +------------+  |
|       ^                    ^                     ^         |
| -  -  | -  - API level -  -| -  -  -  -  -  -  - |-  -  -  |
|       V                    V                     V         |
|------------------------------------------------------------|
| Autonomic Networking Infrastructure                        |
|    - Data structures (ex: certificates, peer information)  |
|    - Generalized Autonomic Control Plane (GACP)            |
|    - Autonomic node addressing and naming                  |
|    - Discovery, negotiation and synchronization functions  |
|    - Distribution of Intent and other information          |
|    - Aggregated reporting and feedback loops               |
|    - Routing                                               |
|------------------------------------------------------------|
|             Basic Operating System Functions               |
+------------------------------------------------------------+

Figure 2: Model of an Autonomic Node

The ANI (the bottom part of Figure 2) holds node-specific data structures, like trust info about itself and its peers 🔐, plus a generic set of functions that don't care what they're being used for. This infrastructure should be generic and support a variety of ASAs (the top part of Figure 2) 🌈. It covers addressing and naming of autonomic nodes, discovery, negotiation and synchronization functions, distribution of information, reporting, feedback loops, and routing inside the ACP 🦋.

The GACP is basically the summary of every interaction the ANI has with other nodes and services 💜. One specific implementation of the GACP is called the ACP, and that's described in [RFC8994] 🫶.

The "Autonomics" use cases (like self-management, self-optimization, and so on) are implemented as ASAs. They lean on the services and data structures of the ANI underneath, which should be self-managing 🤖✨.

The Basic Operating System Functions (the bottom part of Figure 2) are just the normal OS stuff, like the network stack and security functions 💻.

Full Autonomic Network (AN) nodes have the full ANI, with all the functionality described in this document 👑. Later on, the ANIMA Working Group may define a scope for constrained nodes with a reduced ANI and well-defined minimal functionality. Those are currently out of scope 🙈.

3.2. Adjacency Table 🗂️

Autonomic Networking is built on direct interactions between devices in a domain 🤝. The ACP is normally built hop by hop, so tons of interactions in the ANI are based on the ANI adjacency table. Some interactions feed info into the adjacency table, and others use the info already sitting in it 💅.

The ANI adjacency table has, at a minimum, info about adjacent autonomic nodes: Node-ID, IP address in data plane, IP address in ACP, domain, and certificate 📇. An autonomic node keeps this table up to date ⏰. It only tracks nodes that can do Autonomic Networking, so non-autonomic nodes are normally not tracked here 🙅‍♀️. The info is tracked no matter what the status of the peer nodes is. Specifically, the adjacency table holds info about non-enrolled nodes from the same domain and from other domains too 👀. The adjacency table may also contain info about the validity and trust level of the adjacent autonomic nodes 🔍.

Here's what feeds the adjacency table:

• Link-local discovery: This happens in the data plane, using IPv6 link-local addressing only, because that addressing type is itself autonomic 🌟. That way the node learns about all the autonomic nodes around it. The related Standards Track documents ([RFC8990], [RFC8995], and [RFC8994]) explain in detail how link-local discovery is used 📚.
• Vendor redirect: A new device may get info on where its home network is through a vendor-based Manufacturer Authorized Signing Authority (MASA) (see Section 5.3) redirect. This is typically a routable address 🗺️.
• Non-autonomic input: A node may be configured manually with an autonomic peer. It could also learn about autonomic nodes through DHCP options, DNS, and other non-autonomic mechanisms 🧩. Generally, these non-autonomic mechanisms need some administrator intervention 🧑‍💻. The key purpose is to bypass a non-autonomic device or network. Since this is about new devices, it's covered in Appendices A and B of [RFC8995] 🎀.

The adjacency table also defines how an autonomic node behaves 🦋:

• If the node hasn't bootstrapped into a domain (meaning it doesn't have a domain certificate), it rotates through all the nodes in the adjacency table that claim to have a domain. It tries bootstrapping through them one by one 🔄. One possible response is a redirect via a vendor MASA, which gets entered into the adjacency table (see the second bullet above). See [RFC8995] for details 📖.
• If the adjacent node has the same domain, the node authenticates that adjacent node and, if that works, establishes the ACP. See [RFC8994] 🔐.
• Once the node is part of the ACP of a domain, it uses GRASP [RFC8990] to find the registrar(s) of its domain and potentially other services 🔎.
• If the node is part of an ACP and has discovered at least one registrar in its domain via GRASP, it starts the join proxy ASA and acts as a join proxy for neighboring nodes that need to be bootstrapped. See Section 6.3.1.2 for details 🙌.
• Other behaviors are possible, like establishing the ACP with devices of a subdomain or other domains. These will likely be controlled by Intent and are outside the scope of this document 🌸. Note that Intent is distributed through the ACP, so a node can only adapt Intent-driven behavior once it has joined the ACP ⚠️. For now, the ANIMA Working Group doesn't consider providing Intent outside the ACP, but that can be considered later 🕰️.

Once a node has joined the ACP, it also learns the ACP addresses of its adjacent nodes and adds them to the adjacency table so they can talk inside the ACP 💬. Further autonomic domain interactions now happen inside the ACP. At this moment, only negotiation and synchronization via GRASP [RFC8990] are defined 🧃. (Note that GRASP runs in the data plane, as an input for building the adjacency table, and also inside the ACP 💡.)

Autonomic functions are made of ASAs. They run logically above the ANI and may use the adjacency table, the ACP, negotiation and synchronization through GRASP in the ACP, Intent, and other ANI functions 🧁. Since the ANI only provides autonomic interactions within a domain, autonomic functions can also use any other context on a node, specifically the global data plane 🌍✨.

3.3. State Machine 🔄

Autonomic Networking applies during the full life cycle of a node 🌈. This section describes a state machine for an autonomic node throughout its life 💖.

A device is normally expected to store its domain-specific identity, the Local Device Identifier (LDevID) (see Section 5.2), in persistent storage so it's still there after a power cycle 🔋. For device types that can't store the LDevID in persistent storage, a power-cycle event is effectively the same as a factory reset 😭.

3.3.1. State 1: Factory Default 🏭

An autonomic node leaves the factory in this state 🎁. Here, the node has no domain-specific configuration, specifically no LDevID, and it could be used in any target network 🌐. It does have a vendor/manufacturer-specific ID, though: the Initial Device Identifier (IDevID) [IDevID] 🪪. Nodes without an IDevID can't be autonomically and securely enrolled into a domain. They need manual pre-staging, and in that case the pre-staging takes them directly to state 2 🛠️.

Transitions:

• Bootstrap event: The device enrolls into a domain, and as part of that it receives a domain identity (LDevID). If enrollment works, the next state is state 2. See [RFC8995] for details on enrollment 🎉.
• Power-cycle event: The device loses all its state tables and stays in state 1 🔌.

3.3.2. State 2: Enrolled 🎓

An autonomic node is in the "enrolled" state if it has a domain identity (LDevID) and currently has no ACP channel up 🌙. It may still have further configuration or state, for example if it was in state 3 before but lost all its ACP channels 🧳. The LDevID can only be removed from a device through a factory reset, and that also wipes all other state from the device 🧹. This makes sure a device has no stale domain-specific state when it enters the "enrolled" state from state 1 ✨.

Transitions:

• Joining ACP: The device establishes an ACP channel to an adjacent device. See [RFC8994] for details. Next state: 3 🤝.
• Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1 🔁.
• Power-cycle event: The device loses all its state tables, but keeps its domain identity (LDevID). It stays in state 2 🔋.

3.3.3. State 3: In ACP 🚀

In this state, the autonomic node has at least one ACP channel to another device 💜. The node can now take part in more autonomic transactions, like starting ASAs (for example, it must now enable the join proxy ASA so it can help other devices join the domain 🙌). Other conditions may apply to these interactions. For example, to serve as a join proxy, the device must first discover a bootstrap registrar 🔍.

Transitions:

• Leaving ACP: The device drops the last (or only) ACP channel to an adjacent device. Next state: 2 👋.
• Factory reset: A factory reset removes all configuration and the domain identity (LDevID) from the device. Next state: 1 🔁.
• Power-cycle event: The device loses all its state tables but keeps its domain identity (LDevID). Next state: 2 🔋.

---

4. Autonomic Networking Infrastructure 🏗️💖

The ANI gives you a layer of common functionality across an Autonomic Network 🌸. It provides the elementary functions and services, plus extensions 🧩. An autonomic function, made of ASAs on nodes, uses the functions described in this section 💅✨.

4. Autonomic Networking Infrastructure ✨

4.1. Naming 🏷️

okay so inside a domain, each autonomic device should get its own unique name, bestie 💖. The naming scheme should be consistent within a domain, no mix-and-match chaos 🙅‍♀️. Names are typically assigned by a registrar at bootstrap time and stay persistent over the lifetime of the device. All registrars in a domain must follow the same naming scheme.

In the absence of a domain-specific naming scheme, a default naming scheme should use the same logic as the addressing scheme discussed in [RFC8994]. The device name is then composed of a Registrar-ID (for example, taking a Media Access Control (MAC) address of the registrar) and a device number. An example name would then look like this:

0123-4567-89ab-0001

The first three fields are the MAC address, and the fourth field is the sequential number for the device. 🎀

4.2. Addressing 🏡

ASAs need to communicate with each other, using the autonomic addressing of the ANI of the node they reside on. This section describes the addressing approach of the ANI used by ASAs. It's giving organized 💅

Addressing approaches for the data plane of the network are outside the scope of this document. These addressing approaches may be configured and managed in the traditional way or negotiated as a service of an ASA. One use case for such an autonomic function is described in [RFC8992] 🦋

Autonomic addressing is a function of the ANI (lower part of Figure 2), specifically the ACP. ASAs do not have their own addresses. They may use either API calls or the autonomic addressing scheme of the ANI. Main character energy, but make it infrastructure 👑

An autonomic addressing scheme has the following requirements:

• Zero-touch for simple networks: Simple networks should have complete self-management of addressing and not require any central address management, tools, or address planning. 🌸
• Low-touch for complex networks: If complex networks require operator input for autonomic address management, it should be limited to high-level guidance only, expressed in Intent. 🧚
• Flexibility: The addressing scheme must be flexible enough for nodes to be able to move around and for the network to grow, split, and merge. 🦋
• Robustness: It should be as hard as possible for an administrator to negatively affect addressing (and thus connectivity) in the autonomic context. 🛡️
• Stability: The addressing scheme should be as stable as possible. However, implementations need to be able to recover from unexpected address changes. 🫶
• Support for virtualization: Autonomic functions can exist either at the level of the physical network and physical devices or at the level of virtual machines, containers, and networks. In particular, autonomic nodes may support ASAs in virtual entities. The infrastructure, including the addressing scheme, should be able to support this architecture. 🌈
• Simplicity: The addressing scheme should be simple to make engineering easier and to give the human administrator an easy way to troubleshoot autonomic functions. 💜
• Scale: The proposed scheme should work in any network of any size. 🌍
• Upgradability: The scheme must be able to support different addressing concepts in the future. 🔮

The proposed addressing scheme is described in the document "An Autonomic Control Plane (ACP)" [RFC8994]. 📄

4.3. Discovery 🔍

Traditionally, most of the information a node requires is provided through configuration or northbound interfaces. An autonomic function should rely on such northbound interfaces minimally or not at all, so it needs to discover peers and other resources in the network. This section describes various discovery functions in an Autonomic Network. Self-sufficient era 🙌

First, discovering nodes and their properties and capabilities is a core function to establish an autonomic domain. This is the mutual discovery of autonomic nodes, primarily adjacent nodes and secondarily off-link peers. This may, in principle, either leverage existing discovery mechanisms or use new mechanisms tailored to the autonomic context. An important point is that discovery must work in a network with no predefined topology, ideally no manual configuration of any kind, and with nodes starting up from factory condition or after any form of failure or sudden topology change. Honestly so important 😭

Second, network services such as Authentication, Authorization, and Accounting (AAA) should also be discovered and not configured. Service discovery is required for such tasks. An Autonomic Network can leverage existing service discovery functions, use a new approach, or use a mixture. 🧩

Thus, the discovery mechanism could either be fully integrated with autonomic signaling (next section) or use an independent discovery mechanism such as DNS-based Service Discovery or the Service Location Protocol. This choice could be made independently for each ASA, although the infrastructure might require some minimal lowest common denominator (e.g., for discovering the security bootstrap mechanism or the source of information distribution (Section 4.7)). 🗺️

Phase 1 of Autonomic Networking uses GRASP [RFC8990] for discovery. 💅

4.4. Signaling between Autonomic Nodes 📡

Autonomic nodes must communicate with each other, for example, to negotiate and/or synchronize technical objectives (i.e., network parameters) of any kind and complexity. This requires some form of signaling between autonomic nodes. Autonomic nodes implementing a specific use case might choose their own signaling protocol, as long as it fits the overall security model. However, in the general case, any pair of autonomic nodes might need to communicate, so there needs to be a generic protocol for this. A prerequisite for this is that autonomic nodes can discover each other without any preconfiguration, as mentioned above. To be generic, discovery and signaling must be able to handle any sort of technical objective, including ones that require complex data structures. 🧠

The document "GeneRic Autonomic Signaling Protocol (GRASP)" [RFC8990] describes more detailed requirements for discovery, negotiation, and synchronization in an Autonomic Network. It also defines a protocol, called GRASP, for this purpose. GRASP includes an integrated but optional discovery process. 🎁

GRASP is normally expected to run inside the ACP (see Section 4.6) and to depend on the ACP for security. It may run insecurely for a short time during bootstrapping. 🥹

An autonomic node will normally run a single instance of GRASP, used by multiple ASAs. However, scenarios where multiple instances of GRASP run in a single node, perhaps with different security properties, are not excluded. 🤷‍♀️

4.5. Routing 🛣️

All autonomic nodes in a domain must be able to communicate with each other, and in later phases, they must also be able to communicate with autonomic nodes outside their own domain. Therefore, an ACP relies on a routing function. For Autonomic Networks to be interoperable, they must all support one common routing protocol. 🤝

The routing protocol is defined in the ACP document [RFC8994]. 📘

4.6. Autonomic Control Plane 🌐

The ACP carries the control protocols in an Autonomic Network. In the architecture described in this document, it is implemented as an overlay network. The document "An Autonomic Control Plane (ACP)" [RFC8994] describes the implementation details suggested in this document. This document uses the term "overlay" to mean a set of point-to-point adjacencies congruent with the underlying interconnection topology. The terminology may not be aligned with a common usage of the term "overlay" in the routing context. See [RFC8368] for uses cases for the ACP. 🧵

4.7. Information Distribution (*) 📬

Certain forms of information require distribution across an autonomic domain. The distribution of information runs inside the ACP. For example, Intent is distributed across an autonomic domain, as explained in [RFC7575]. 📣

Intent is the policy language of an Autonomic Network (see also Section 7.2). It is a high-level policy and should change only infrequently (order of days). Therefore, information such as Intent should be simply flooded to all nodes in an autonomic domain, and there is currently no perceived need to have more targeted distribution methods. Intent is also expected to be monolithic and flooded as a whole. One possible method for distributing Intent, as well as other forms of data, is discussed in [GRASP-DISTRIB]. Intent and information distribution are not part of the ANIMA Working Group charter. 🌊

---

5. Security and Trust Infrastructure 🔐

An Autonomic Network is self-protecting. All protocols are secure by default, without the requirement for the administrator to explicitly configure security, with the exception of setting up a PKI infrastructure. Security that just handles itself, iconic 😤

Autonomic nodes have direct interactions between themselves, which must be secured. Since an Autonomic Network does not rely on configuration, it is not an option to configure, for example, pre-shared keys. A trust infrastructure such as a PKI infrastructure must be in place. This section describes the principles of this trust infrastructure. In this first phase of Autonomic Networking, a device is either 1) within the trust domain and fully trusted or 2) outside the trust domain and fully untrusted. It's either in or out, no in-between 🚪

The default method to automatically bring up a trust infrastructure is defined in the document "Bootstrapping Remote Secure Key Infrastructure (BRSKI)" [RFC8995]. The ASAs required for this enrollment process are described in Section 6.3. An autonomic node must implement the enrollment and join proxy ASAs. The registrar ASA may be implemented only on a subset of nodes. 🎟️

5.1. Public Key Infrastructure 🗝️

An autonomic domain uses a PKI model. The root of trust is a Certification Authority (CA). A registrar acts as a Registration Authority (RA). 👑

A minimum implementation of an autonomic domain contains one CA, one registrar, and network elements. 🧱

5.2. Domain Certificate 📜

Each device in an autonomic domain uses a domain certificate (LDevID) to prove its identity. A new device uses its manufacturer-provided certificate (IDevID) during bootstrap to obtain a domain certificate. [RFC8995] describes how a new device receives a domain certificate and defines the certificate format. 🪪

5.3. MASA 🏭

The Manufacturer Authorized Signing Authority (MASA) is a trusted service for bootstrapping devices. The purpose of the MASA is to provide ownership tracking of devices in a domain. The MASA provides audit, authorization, and ownership tokens to the registrar during the bootstrap process to assist in the authentication of devices attempting to join an autonomic domain and to allow a joining device to validate whether it is joining the correct domain. The details for MASA service, security, and usage are defined in [RFC8995]. 🕵️‍♀️

5.4. Subdomains (*) 🫧

By default, subdomains are treated as different domains. This implies no trust between a domain and its subdomains and no trust between subdomains of the same domain. Specifically, no ACP is built, and Intent is valid only for the domain it is defined for explicitly. Boundaries, babe 🚧

In the ANIMA Working Group charter, alternative trust models should be defined, for example, to allow full or limited trust between domain and subdomain. 🦋

5.5. Cross-Domain Functionality (*) 🌉

By default, different domains do not interoperate, no ACP is built, and no trust is implied between them. 🙅‍♀️

In the future, models can be established where other domains can be trusted in full or for limited operations between the domains. The future is bright, and the trust is earned ✨

6. Autonomic Service Agents (ASAs) ✨

okay bestie, this section is about how autonomic services actually run on top of the ANI 🦋

6.1. General Description of an ASA

okay so an ASA is defined in [RFC7575] as "An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function) or whole" 💅 basically it's a process that uses the features the ANI gives it to get its own goals done, usually by chatting with other ASAs over GRASP [RFC8990] or some other way. ofc it also talks to the specific targets of its function using whatever mechanism works 🫶 unless its function is super simple, the ASA will have to handle overlapping asynchronous operations, so it can end up being a pretty complex piece of software in its own right, living in the application layer above the ANI 🧚 design guidelines for ASAs are in [ASA-GUIDELINES] 📚

so we can spot at least three classes of ASAs 🍓

• Simple ASAs with a small footprint that could run anywhere. 🌸
• Complex, possibly multi-threaded ASAs that have a significant resource requirement and will only run on selected nodes. 👑
• A few 'infrastructure ASAs' that use basic ANI features in support of the ANI itself, which must run in all autonomic nodes. These are outlined in the following sections. 🫧

autonomic nodes, and therefore their ASAs, know their own capabilities and restrictions, which come from hardware, firmware, or pre-installed software. they are "self-aware" 🪞✨

the role of an autonomic node depends on Intent and on the surrounding network behaviors, which may include forwarding behaviors, aggregation properties, topology location, bandwidth, tunnel or translation properties, etc. for example, a node may decide to act as a backup node for a neighbor, if its capabilities allow it to do so 🦋

after an initial discovery phase, the node's properties and those of its neighbors are the foundation of how a specific node behaves. a node and its ASAs have no pre-configuration for the particular network they get installed in, so they have to figure it out 🔍💖

since all ASAs will interact with the ANI, they will depend on appropriate application programming interfaces (APIs). it's desirable that ASAs are portable between operating systems, so these APIs need to be universal 🌈 an API for GRASP is described in [RFC8991].

ASAs will, in general, be designed and coded by experts in a particular technology and use case, not by experts in the ANI and its components 🧑‍💻 also, they may be coded in a variety of programming languages, in particular, languages that support object constructs as well as traditional variables and structures. the APIs should be designed with these factors in mind 💜

it must be possible to run ASAs as non-privileged (user space) processes, except for those (such as the infrastructure ASAs) that necessarily require kernel privilege. also, it is highly desirable that ASAs can be dynamically loaded on a running node ⭐

since autonomic systems must be self-repairing, it is of great importance that ASAs are coded using robust programming techniques 🛠️ all runtime error conditions must be caught, leading to suitable minimally disruptive recovery actions, but a complete restart of the ASA must also be considered. conditions such as discovery failures or negotiation failures must be treated as routine, with the ASA retrying the failed operation, preferably with an exponential back-off in the case of persistent errors. when multiple threads are started within an ASA, these threads must be monitored for failures and hangups, and appropriate action taken. attention must be given to garbage collection, so that ASAs never run out of resources. there is assumed to be no human operator; again, in the worst case, every ASA must be capable of restarting itself 😭🔥

ASAs automatically benefit from the security provided by the ANI, specifically by the ACP and by GRASP. however, beyond that, they are responsible for their own security, especially when communicating with the specific targets of their function. therefore, the design of an ASA must include a security analysis beyond 'use ANI security'. 💀🔐

6.2. ASA Life-Cycle Management

ASAs operating on a given ANI may come from different providers and pursue different objectives 🎀 management of ASAs and their interactions with the ANI should follow the same operating principles and thus comply to a generic life-cycle management model 🫶

the ASA life cycle provides standard processes to:

• install ASA: copy the ASA code onto the node and start it. 📦
• deploy ASA: associate the ASA instance with a (some) managed network device(s) (or network function). 🚀
• control ASA execution: when and how an ASA executes its control loop. 🎛️

this life cycle will also define which interactions ASAs have with the ANI in between the different states. the noticeable interactions are:

• Self-description of ASA instances at the end of deployment: its format needs to define the information required for the management of ASAs by ANI entities. 🪪
• Control of the ASA control loop during the operation: signaling has to carry formatted messages to control ASA execution (at least starting and stopping the control loop). 🔁

6.3. Specific ASAs for the Autonomic Networking Infrastructure

the following functions provide essential, required functionality in an Autonomic Network and are therefore mandatory to implement on unconstrained autonomic nodes 🏗️ they are described here as ASAs that include the underlying infrastructure components, but implementation details might vary.

the first three (pledge, join proxy, join registrar) support together the trust enrollment process described in Section 5. for details see [RFC8995] 🎟️

6.3.1. Enrollment ASAs

6.3.1.1. The Pledge ASA

this ASA includes the function of an autonomic node that bootstraps into the domain with the help of a join proxy ASA (see below). such a node is known as a pledge during the enrollment process 🐣 this ASA must be installed by default on all nodes that require an autonomic zero-touch bootstrap.

6.3.1.2. The Join Proxy ASA

this ASA includes the function of an autonomic node that helps non-enrolled, adjacent devices to enroll into the domain 🤝 this ASA must be installed on all nodes, although only one join proxy needs to be active on a given LAN. see also [RFC8995].

6.3.1.3. The Join Registrar ASA

this ASA includes the Join Registrar function in an Autonomic Network 📝 this ASA does not need to be installed on all nodes, but only on nodes that implement the Join Registrar function.

6.3.2. ACP ASA

this ASA includes the ACP function in an Autonomic Network 🌐 in particular, it acts to discover other potential ACP nodes and to support the establishment and teardown of ACP channels. this ASA must be installed on all nodes. for details, see Section 4.6 and [RFC8994] 🔗

6.3.3. Information Distribution ASA (*)

this ASA is currently out of scope in the ANIMA Working Group charter and is provided here only as background information 🙈

this ASA includes the information distribution function in an Autonomic Network 📢 in particular, it acts to announce the availability of Intent and other information to all other autonomic nodes. this ASA does not need to be installed on all nodes, but only on nodes that implement the information distribution function. for details, see Section 4.7.

note that information distribution can be implemented as a function in any ASA. see [GRASP-DISTRIB] for more details on how information is suggested to be distributed 🧠

---

7. Management and Programmability ✨

this section describes how an Autonomic Network is managed and programmed 🎛️

7.1. Managing a (Partially) Autonomic Network

autonomic management usually coexists with traditional management methods in most networks 🫂 thus, autonomic behavior will be defined for individual functions in most environments. examples of overlap are:

• Autonomic functions can use traditional methods and protocols (e.g., SNMP and the Network Configuration Protocol (NETCONF)) to perform management tasks, inside and outside the ACP. 🛰️
• Autonomic functions can conflict with behavior enforced by the same traditional methods and protocols. ⚡
• Traditional functions can use the ACP, for example, if reachability on the data plane is not (yet) established. 🛟

the autonomic Intent is defined at a high level of abstraction. however, since it is necessary to address individual managed elements, autonomic management needs to communicate in lower-level interactions (e.g., commands and requests). for example, it is expected that the configuration of such elements be performed using NETCONF and YANG modules, as well as the monitoring be executed through SNMP and MIBs 📊

conflict can occur between autonomic default behavior, autonomic Intent, and traditional management methods. conflict resolution is achieved in autonomic management through prioritization [RFC7575]. the rationale is that manual and node-based management have a higher priority than autonomic management 👑 thus, the autonomic default behavior has the lowest priority, then comes the autonomic Intent (medium priority), and, finally, the highest priority is taken by node-specific network management methods, such as the use of command-line interfaces 💅

7.2. Intent (*)

okay so Intent is not covered in the current implementation specifications 🧪 this section discusses a topic for further research.

this section gives an overview of Intent and how it is managed. Intent and Policy-Based Network Management (PBNM) is already described inside the IETF (e.g., Policy Core Information Model (PCIM)) and in other Standards Development Organizations (SDOs) (e.g., the Distributed Management Task Force (DMTF)) 📚

Intent can be described as an abstract, declarative, high-level policy used to operate an autonomic domain, such as an enterprise network [RFC7575]. Intent should be limited to high-level guidance only, so it does not directly define a policy for every network element separately 🎯

Intent can be refined to lower-level policies using different approaches. this is expected in order to adapt the Intent to the capabilities of managed devices. Intent may contain role or function information, which can be translated to specific nodes [RFC7575]. one of the possible refinements of the Intent is using Event-Condition-Action (ECA) rules 🧩

different parameters may be configured for Intent. these parameters are usually provided by the human operator. some of these parameters can influence the behavior of specific autonomic functions, as well as the way the Intent is used to manage the autonomic domain 🎀

Intent is discussed in more detail in [ANIMA-INTENT]. Intent, as well as other types of information, is distributed via GRASP; see [GRASP-DISTRIB] 💖

7.3. Aggregated Reporting (*) ✨

Okay so aggregated reporting isn't covered in the current implementation specs, which means this part is a topic for further research 🧐 still a fun thing to think about tho.

An Autonomic Network should minimize the need for human intervention 💅. How the network behaves is handled through an autonomic Intent that the human admin provides. In a similar way, the reports about the network's operational status should combine info from all the different network elements, so you can see how well the autonomic Intent is actually being enforced 📊. So reporting in an Autonomic Network should happen on a network-wide basis [RFC7575] 🌐.

Multiple events can happen at the same time in an Autonomic Network, just like in a traditional one 🌀. But when it's reporting to a human admin, those events should be aggregated so the admin doesn't get a notification about every single managed element 🙈. Algorithms may be used to decide what gets reported (like filtering 🧹), how it gets reported, and how different events relate to each other 🔗. Also, an event in one element can be compensated for by changes in other elements, so the network-wide target described in the autonomic Intent stays on track 🎯.

Reporting in an Autonomic Network may be at the same abstraction level as Intent 🧠. The aggregated view of the network's current operational status can then be used to switch to different management modes 🔀. Even though autonomic management should minimize the need for user intervention, some events may still need to be handled by the actions of a human admin 🫶.

7.4. Feedback Loops to NOC (*) 🔁

Okay so feedback loops are required in an Autonomic Network so a human admin or central control systems can step in, while the network keeps its default behavior 🎀. With a feedback loop, an administrator must be prompted with a default action, and they have the option to acknowledge it or override the proposed default action ✅.

Unidirectional notifications to the Network Operations Center (NOC) that don't propose any default action and don't allow an override as part of the transaction are considered like traditional notification services, such as syslog 📜. They're expected to coexist with autonomic methods, but they aren't covered in this document 🫠.

7.5. Control Loops (*) 🔄

Control loops aren't covered in the current implementation specs either, so this is another topic for further research 🔬.

Control loops are used in Autonomic Networking to give the autonomic system a generic mechanism to adapt on its own to different factors that can change the goals the Autonomic Network is trying to achieve, or how it achieves them 🦋. For example, as user needs, business goals, and the ANI itself change, self-adaptation lets the ANI change the services and resources it makes available so it can keep up 💖.

Control loops keep observing and collecting data so the autonomic management system can understand changes in how the managed system behaves. Then they take actions to move the state of the managed system toward a common goal 🎯. Self-adaptive systems move decision making away from static, pre-defined commands and toward dynamic processes computed at runtime ⚡.

Most autonomic systems use a closed control loop with feedback 🔁. Such control loops should be able to be dynamically changed at runtime, so they can adapt to changing user needs, business goals, and changes in the ANI 🌈.

7.6. APIs (*) 🔌

[RFC8991] defines a conceptual outline for an API for the GeneRic Autonomic Signaling Protocol (GRASP) 🧚. This conceptual API is designed for ASAs to talk to other ASAs through GRASP. Full Standards Track API specifications aren't covered in the current implementation specs, so that's still a work in progress 🛠️.

Most APIs are static, which means they're pre-defined and represent an invariant mechanism for working with data 🧱. An Autonomic Network should be able to use dynamic APIs in addition to static APIs ✨.

A dynamic API retrieves data using a generic mechanism, then lets the client navigate that data and operate on it 🗺️. These APIs typically use introspection and/or reflection. Introspection lets software examine the type and properties of an object at runtime 🔍. Reflection lets a program manipulate the attributes, methods, and/or metadata of an object 🪞.

APIs must be able to express and preserve the semantics of data models 💅. For example, software contracts [Meyer97] are based on the idea that a software-intensive system, like an Autonomic Network, is a set of communicating components. Their interaction depends on precisely defined specifications of the mutual obligations that the interacting components must respect 🤝. This typically includes specifying:

• pre-conditions that must be satisfied before the method can start execution
• post-conditions that must be satisfied when the method has finished execution
• invariant attributes that must not change during the execution of the method

7.7. Data Model (*) 📚

Data models aren't covered in the current implementation specs, so this section is another topic for further research 🧪.

The following definitions of "data model" and "information model" are adapted from [SUPA-DATA] 📖.

An information model is a representation of concepts of interest to an environment, in a form that's independent of the data repository, data definition language, query language, implementation language, and protocol 🫧. A data model, in contrast, is a representation of those same kinds of concepts, but in a form that depends on the data repository, data definition language, query language, implementation language, and protocol 💜.

The point of an information model is to define objects and their relationships in a technology-neutral way 🌸. That forms a consensual vocabulary the ANI and ASAs can use. A data model is then a technology-specific mapping of all or part of the information model, to be used by all or part of the system 🧩.

A system may have multiple data models. Operational Support Systems, for example, typically have multiple types of repositories, such as SQL and NoSQL, to take advantage of the different properties of each 🗄️. If an autonomic system needs multiple data models, then an information model should be used so the concepts of each data model can be related to each other without technological bias ⚖️.

A data model is essential for certain types of functions, such as a Model-Reference Adaptive Control Loop (MRACL) 👑. More generally, a data model can define the objects, attributes, methods, and relationships of a software system, like the ANI, an autonomic node, or an ASA 🎀. It can also help design an API, as well as any language used to interface with the Autonomic Network 💅.

8. Coordination between Autonomic Functions (*) 🤝

Coordination between autonomic functions isn't covered in the current implementation specs, so this is a topic for further research 🔭.

8.1. Coordination Problem (*) ⚔️

Okay so different autonomic functions may conflict when setting certain parameters 😬. For example, an energy efficiency function may want to shut down a redundant link, while a load-balancing function wouldn't want that to happen 🔌. The administrator must be able to understand and resolve such interactions, so they can steer Autonomic Network performance to a given (intended) operational point 🎯.

Several interaction types may exist among autonomic functions, for example:

• Cooperation: An autonomic function can improve the behavior or performance of another autonomic function, such as a traffic forecasting function used by a traffic allocation function 🫶.
• Dependency: An autonomic function cannot work without another one being present or accessible in the Autonomic Network 🔗.
• Conflict: A metric value conflict is a conflict where one metric is influenced by parameters of different autonomic functions. A parameter value conflict is a conflict where one parameter is modified by different autonomic functions 💥.

Solving the coordination problem beyond one-by-one cases can quickly become intractable for large networks 🥵. Specifying a common functional block on coordination is a first step toward addressing the problem in a systemic way 🧠. The coordination life cycle consists of three states:

• At build-time, a "static interaction map" can be constructed on the relationship of functions and attributes. This map can be used to (pre-)define policies and priorities for identified conflicts 🏗️.
• At deploy-time, autonomic functions are not yet active or acting on the network. A "dynamic interaction map" is created for each instance of each autonomic function on a per-resource basis, including the actions performed and their relationships. This map is the basis for identifying conflicts that will happen at runtime, categorizing them, and planning the appropriate coordination strategies and mechanisms 🚀.
• At runtime, when conflicts happen, arbitration is driven by the coordination strategies. Also, new dependencies can be observed and inferred, which results in an update of the dynamic interaction map and an adaptation of the coordination strategies and mechanisms 🔄.

Multiple coordination strategies and mechanisms exist and can be devised 🌈. The set ranges from basic approaches (such as a random process or a token-based process), to approaches based on time separation and hierarchical optimization, to more complex approaches (such as multi-objective optimization and other control theory approaches and algorithm families) 🧮.

8.2. Coordination Functional Block (*) 🧩

A common coordination functional block is a desirable component of the ANIMA reference model 👑. It gives us a means to ensure network properties and predictable performance or behavior, such as stability and convergence, even when several autonomic functions are interacting 💖.

A common coordination function requires:

• A common description of autonomic functions, their attributes, and life cycle.
• A common representation of information and knowledge (e.g., interaction maps).
• A common "control/command" interface between the coordination "agent" and the autonomic functions.

Guidelines, recommendations, or BCPs can also be provided for aspects pertaining to the coordination strategies and mechanisms 📋.

9. Security Considerations 🔒

Okay, this part is serious, bestie 💀. In this section, we distinguish outsider and insider attacks. In an outsider attack, all network elements and protocols are securely managed and operating, and an outside attacker can sniff packets in transit, inject packets, and replay packets 🕵️. In an insider attack, the attacker has access to an autonomic node, or some other means (e.g., remote code execution in the node by exploiting ACP-independent vulnerabilities in the node platform), to produce arbitrary payloads on the protected ACP channels 😱.

If a system has vulnerabilities in its implementation or operation (configuration), an outside attacker can exploit those vulnerabilities to become an insider attacker 🚨.

9.1. Protection against Outsider Attacks

okay so, we're assuming every system in an Autonomic Network is locked down and run by the best current practices 🔒✨ That covers the classic stuff (solid code security, strong randomization, strong passwords, the works) plus the AN-specific stuff, like a secured MASA service 🎀

Traditional security for implementation and operation is outside the scope of this doc, so we're not going there 🙈

AN-specific protocols and methods still have to follow the traditional security rules 💅 Any packet that an outside attacker can sniff or inject has to be:

• protected against modification
• authenticated
• protected against replay attacks
• confidentiality protected (encrypted)

The AN protocols should also be robust against packet drops and man-in-the-middle attacks 🫶 The how is covered in the AN Standards Track documents that define the methods, specifically [RFC8990], [RFC8994], and [RFC8995] 🦋

Most AN messages run inside the cryptographically protected ACP 🔐 The unprotected AN messages outside the ACP are limited to one simple discovery method, which is in Section 2.5.2 of [RFC8990]: the Discovery Unsolicited Link-Local (DULL) message 📡 There are detailed rules on how to use it, so check those out 💜

⚠️ Warning, bestie: if a third party can observe AN messages, they might reveal valuable info about network configuration, the security precautions in use, individual users, and their traffic patterns 😭 Even if the messages are encrypted, they might still leak some info through traffic analysis 💀

9.2. Risk of Insider Attacks

okay this part is kinda intense, so buckle up 🎢 An Autonomic Network is made of autonomic devices that form a distributed self-managing system 🌸 Devices inside a domain have credentials issued from a common trust anchor and can use them to create mutual trust 🤝 The tea is that any device inside a trust domain can, by default, use all the distributed functions across the entire autonomic domain in a malicious way 😱

An inside attacker, or an outsider when there are protocol vulnerabilities or insecure operation, has these generic ways to take control of an Autonomic Network 👑

• Introducing a fake device into the trust domain by subverting the authentication methods. This depends on the AN protocols being specified, implemented, and operated correctly 🙅‍♀️
• Subverting a device that's already part of a trust domain and modifying its behavior. This threat isn't specific to the solution in this document, it applies to all network solutions 🫠
• Exploiting potentially yet unknown protocol vulnerabilities in the AN or other protocols. This is also a generic threat that applies to all network solutions 🕵️‍♀️

These threats are, in principle, comparable to other solutions 💖 With design, implementation, or operational errors, security is no longer guaranteed. BUT (and this is the scary part 😭) the distributed nature of AN, specifically the ACP, increases the threat surface significantly. For example, a compromised device may have full IP reachability to all other devices inside the ACP and can use all AN methods and protocols 🚨

So for the next phase of the ANIMA Working Group, it is recommended to introduce a subdomain security model 🧱 That reduces the attack surface and means a full domain isn't exposed to a potential intruder ✨ Also, additional security mechanisms on the ASA level should be considered for high-risk autonomic functions 🛡️

---

10. IANA Considerations

Good news, bestie: this document has no IANA actions 🎀

11. References

11.1. Normative References

[IDevID]   IEEE, "IEEE Standard for Local and metropolitan area
           networks - Secure Device Identity", IEEE 802.1AR,
           <https://1.ieee802.org/security/802-1ar>.

[RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
           Autonomic Signaling Protocol (GRASP)", RFC 8990,
           DOI 10.17487/RFC8990, May 2021,
           <https://www.rfc-editor.org/info/rfc8990>.

[RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
           Autonomic Control Plane (ACP)", RFC 8994,
           DOI 10.17487/RFC8994, May 2021,
           <https://www.rfc-editor.org/info/rfc8994>.

[RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
           and K. Watsen, "Bootstrapping Remote Secure Key
           Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
           May 2021, <https://www.rfc-editor.org/info/rfc8995>.

11.2. Informative References

[ANIMA-INTENT]
           Du, Z., Jiang, S., Nobre, J. C., Ciavaglia, L., and M.
           Behringer, "ANIMA Intent Policy and Format", Work in
           Progress, Internet-Draft, draft-du-anima-an-intent-05, 14
           February 2017,
           <https://tools.ietf.org/html/draft-du-anima-an-intent-05>.

[ASA-GUIDELINES]
           Carpenter, B., Ciavaglia, L., Jiang, S., and P. Peloso,
           "Guidelines for Autonomic Service Agents", Work in
           Progress, Internet-Draft, draft-ietf-anima-asa-guidelines-
           00, 14 November 2020, <https://tools.ietf.org/html/draft-
           ietf-anima-asa-guidelines-00>.

[GRASP-DISTRIB]
           Liu, B., Ed., Xiao, X., Ed., Hecker, A., Jiang, S.,
           Despotovic, Z., and B. Carpenter, "Information
           Distribution over GRASP", Work in Progress, Internet-
           Draft, draft-ietf-anima-grasp-distribution-02, 8 March
           2021, <https://tools.ietf.org/html/draft-ietf-anima-grasp-
           distribution-02>.

[Meyer97]  Meyer, B., "Object-Oriented Software Construction (2nd
           edition)", Prentice Hall, ISBN 978-0136291558, 1997.

[RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
           Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
           Networking: Definitions and Design Goals", RFC 7575,
           DOI 10.17487/RFC7575, June 2015,
           <https://www.rfc-editor.org/info/rfc7575>.

[RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
           Analysis for Autonomic Networking", RFC 7576,
           DOI 10.17487/RFC7576, June 2015,
           <https://www.rfc-editor.org/info/rfc7576>.

[RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
           Control Plane for Stable Connectivity of Network
           Operations, Administration, and Maintenance (OAM)",
           RFC 8368, DOI 10.17487/RFC8368, May 2018,
           <https://www.rfc-editor.org/info/rfc8368>.

[RFC8991]  Carpenter, B., Liu, B., Ed., Wang, W., and X. Gong,
           "GeneRic Autonomic Signaling Protocol Application Program
           Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991,
           May 2021, <https://www.rfc-editor.org/info/rfc8991>.

[RFC8992]  Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun,
           "Autonomic IPv6 Edge Prefix Management in Large-Scale
           Networks", RFC 8992, DOI 10.17487/RFC8992, May 2021,
           <https://www.rfc-editor.org/info/rfc8992>.

[SUPA-DATA]
           Halpern, J. and J. Strassner, "Generic Policy Data Model
           for Simplified Use of Policy Abstractions (SUPA)", Work in
           Progress, Internet-Draft, draft-ietf-supa-generic-policy-
           data-model-04, 18 June 2017, <https://tools.ietf.org/html/
           draft-ietf-supa-generic-policy-data-model-04>.

Acknowledgements

Huge thanks to everyone who gave feedback and input on this doc 🫶: Sheng Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, and Artur Hecker. Useful reviews came from Joel Halpern, Radia Perlman, Tianran Zhou, and Christian Hopps 💜

Contributors

Significant contributions to this document were made by John Strassner (Huawei), Bing Liu (Huawei), and Pierre Peloso (Nokia) 🌈

Authors' Addresses

Michael H. Behringer (editor)

Email: Michael.H.Behringer@gmail.com


Brian Carpenter
School of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand

Email: brian.e.carpenter@gmail.com


Toerless Eckert
Futurewei USA
2330 Central Expy
Santa Clara, CA 95050
United States of America

Email: tte+ietf@cs.fau.de


Laurent Ciavaglia
Nokia
Villarceaux
91460 Nozay
France

Email: laurent.ciavaglia@nokia.com


Jéferson Campos Nobre
Federal University of Rio Grande do Sul (UFRGS)
Av. Bento Gonçalves, 9500
Porto Alegre-RS
91501-970
Brazil

Email: jcnobre@inf.ufrgs.br