rfc9222.original   rfc9222.txt 
Network Working Group B. E. Carpenter Internet Engineering Task Force (IETF) B. Carpenter
Internet-Draft Univ. of Auckland Request for Comments: 9222 Univ. of Auckland
Intended status: Informational L. Ciavaglia Category: Informational L. Ciavaglia
Expires: 5 August 2022 Rakuten Mobile ISSN: 2070-1721 Rakuten Mobile
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
P. Peloso P. Peloso
Nokia Nokia
1 February 2022 March 2022
Guidelines for Autonomic Service Agents Guidelines for Autonomic Service Agents
draft-ietf-anima-asa-guidelines-07
Abstract Abstract
This document proposes guidelines for the design of Autonomic Service This document proposes guidelines for the design of Autonomic Service
Agents for autonomic networks. Autonomic Service Agents, together Agents for autonomic networks. Autonomic Service Agents, together
with the Autonomic Network Infrastructure, the Autonomic Control with the Autonomic Network Infrastructure, the Autonomic Control
Plane and the Generic Autonomic Signaling Protocol constitute base Plane, and the GeneRic Autonomic Signaling Protocol, constitute base
elements of an autonomic networking ecosystem. elements of an autonomic networking ecosystem.
Discussion Venue
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the ANIMA mailing list
(anima@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/anima/
(https://mailarchive.ietf.org/arch/browse/anima/).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 5 August 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9222.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Logical Structure of an Autonomic Service Agent . . . . . . . 5 2. Terminology
3. Interaction with the Autonomic Networking Infrastructure . . 6 3. Logical Structure of an Autonomic Service Agent
3.1. Interaction with the security mechanisms . . . . . . . . 6 4. Interaction with the Autonomic Networking Infrastructure
3.2. Interaction with the Autonomic Control Plane . . . . . . 6 4.1. Interaction with the Security Mechanisms
3.3. Interaction with GRASP and its API . . . . . . . . . . . 7 4.2. Interaction with the Autonomic Control Plane
3.4. Interaction with policy mechanisms . . . . . . . . . . . 8 4.3. Interaction with GRASP and its API
4. Interaction with Non-Autonomic Components and Systems . . . . 9 4.4. Interaction with Policy Mechanisms
5. Design of GRASP Objectives . . . . . . . . . . . . . . . . . 9 5. Interaction with Non-autonomic Components and Systems
6. Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Design of GRASP Objectives
6.1. Installation phase . . . . . . . . . . . . . . . . . . . 11 7. Life Cycle
6.1.1. Installation phase inputs and outputs . . . . . . . . 12 7.1. Installation Phase
6.2. Instantiation phase . . . . . . . . . . . . . . . . . . . 13 7.1.1. Installation Phase Inputs and Outputs
6.2.1. Operator's goal . . . . . . . . . . . . . . . . . . . 13 7.2. Instantiation Phase
6.2.2. Instantiation phase inputs and outputs . . . . . . . 14 7.2.1. Operator's Goal
6.2.3. Instantiation phase requirements . . . . . . . . . . 14 7.2.2. Instantiation Phase Inputs and Outputs
6.3. Operation phase . . . . . . . . . . . . . . . . . . . . . 15 7.2.3. Instantiation Phase Requirements
6.4. Removal phase . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Operation Phase
7. Coordination and Data Models . . . . . . . . . . . . . . . . 16 7.4. Removal Phase
7.1. Coordination between Autonomic Functions . . . . . . . . 16 8. Coordination and Data Models
7.2. Coordination with Traditional Management Functions . . . 16 8.1. Coordination between Autonomic Functions
7.3. Data Models . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Coordination with Traditional Management Functions
8. Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.3. Data Models
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Robustness
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Example Logic Flows
Appendix B. Terminology . . . . . . . . . . . . . . . . . . . . 25 Acknowledgements
Appendix C. Example Logic Flows . . . . . . . . . . . . . . . . 25 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This document proposes guidelines for the design of Autonomic Service This document proposes guidelines for the design of Autonomic Service
Agents (ASAs) in the context of an Autonomic Network (AN) based on Agents (ASAs) in the context of an Autonomic Network (AN) based on
the Autonomic Network Infrastructure (ANI) outlined in the autonomic the Autonomic Network Infrastructure (ANI) outlined in the autonomic
networking reference model [RFC8993]. This infrastructure makes use networking reference model [RFC8993]. This infrastructure makes use
of the Autonomic Control Plane (ACP) [RFC8994] and the Generic of the Autonomic Control Plane (ACP) [RFC8994] and the GeneRic
Autonomic Signaling Protocol (GRASP) [RFC8990]. A general Autonomic Signaling Protocol (GRASP) [RFC8990]. A general
introduction to this environment may be found at [IPJ], which also introduction to this environment may be found at [IPJ], which also
includes explanatory diagrams, and a summary of terminology is in includes explanatory diagrams, and a summary of terminology is in
Appendix B. Section 2.
This document is a contribution to the description of an autonomic This document is a contribution to the description of an autonomic
networking ecosystem, recognizing that a deployable autonomic network networking ecosystem, recognizing that a deployable autonomic network
needs more than just ACP and GRASP implementations. Such an needs more than just ACP and GRASP implementations. Such an
autonomic network must achieve management tasks that a Network autonomic network must achieve management tasks that a Network
Operations Center (NOC) cannot readily achieve manually, such as Operations Center (NOC) cannot readily achieve manually, such as
continuous resource optimization or automated fault detection and continuous resource optimization or automated fault detection and
repair. These tasks, and other management automation goals, are repair. These tasks, and other management automation goals, are
described at length in [RFC7575]. The net result should be described at length in [RFC7575]. The net result should be
significant operational improvement. To achieve this, the autonomic significant operational improvement. To achieve this, the autonomic
skipping to change at page 3, line 38 skipping to change at line 120
corresponding GRASP technical objective definitions. A GRASP corresponding GRASP technical objective definitions. A GRASP
objective [RFC8990] is a data structure whose main contents are a objective [RFC8990] is a data structure whose main contents are a
name and a value. The value consists of a single configurable name and a value. The value consists of a single configurable
parameter or a set of parameters of some kind. parameter or a set of parameters of some kind.
There must also be tools to deploy and oversee ASAs, and integration There must also be tools to deploy and oversee ASAs, and integration
with existing operational mechanisms [RFC8368]. However, this with existing operational mechanisms [RFC8368]. However, this
document focuses on the design of ASAs, with some reference to document focuses on the design of ASAs, with some reference to
implementation and operational aspects. implementation and operational aspects.
There is a considerable literature about autonomic agents with a There is considerable literature about autonomic agents with a
variety of proposals about how they should be characterized. Some variety of proposals about how they should be characterized. Some
examples are [DeMola06], [Huebscher08], [Movahedi12] and [GANA13]. examples are [DEMOLA06], [HUEBSCHER08], [MOVAHEDI12], and [GANA13].
However, for the present document, the basic definitions and goals However, for the present document, the basic definitions and goals
for autonomic networking given in [RFC7575] apply. According to RFC for autonomic networking given in [RFC7575] apply. According to RFC
7575, an Autonomic Service Agent is "An agent implemented on an 7575, an Autonomic Service Agent is "An agent implemented on an
autonomic node that implements an autonomic function, either in part autonomic node that implements an autonomic function, either in part
(in the case of a distributed function) or whole." (in the case of a distributed function) or whole."
ASAs must be distinguished from other forms of software component.
ASAs must be distinguished from other forms of software components.
They are components of network or service management; they do not in They are components of network or service management; they do not in
themselves provide services to end users. They do however provide themselves provide services to end users. They do, however, provide
management services to network operators and administrators. For management services to network operators and administrators. For
example, the services envisaged for network function virtualisation example, the services envisaged for network function virtualization
[NFV] or for service function chaining [RFC7665] might be managed by (NFV) [NFV] or for service function chaining (SFC) [RFC7665] might be
an ASA rather than by traditional configuration tools. managed by an ASA rather than by traditional configuration tools.
Another example is that an existing script running within a router to Another example is that an existing script running within a router to
locally monitor or configure functions or services could be upgraded locally monitor or configure functions or services could be upgraded
to an ASA that could communicate with peer scripts on neighboring or to an ASA that could communicate with peer scripts on neighboring or
remote routers. A high-level API will allow such upgraded scripts to remote routers. A high-level API will allow such upgraded scripts to
take full advantage of the secure ACP and the discovery, negotiation take full advantage of the secure ACP and the discovery, negotiation,
and synchronization features of GRASP. Familiar tasks such as and synchronization features of GRASP. Familiar tasks such as
configuring an Interior Gateway Protocol (IGP) on neighboring routers configuring an Interior Gateway Protocol (IGP) on neighboring routers
or even exchanging IGP security keys could be performed securely in or even exchanging IGP security keys could be performed securely in
this way. This document mainly addresses issues affecting quite this way. This document mainly addresses issues affecting quite
complex ASAs, but initially the most useful ASAs may in fact be complex ASAs, but initially, the most useful ASAs may in fact be
rather simple evolutions of existing scripts. rather simple evolutions of existing scripts.
The reference model [RFC8993] for autonomic networks explains further The reference model [RFC8993] for autonomic networks explains further
the functionality of ASAs by adding "[An ASA is] a process that makes the functionality of ASAs by adding the following:
use of the features provided by the ANI to achieve its own goals,
usually including interaction with other ASAs via the GRASP protocol | [An ASA is] a process that makes use of the features provided by
[RFC8990] or otherwise. Of course, it also interacts with the | the ANI to achieve its own goals, usually including interaction
specific targets of its function, using any suitable mechanism. | with other ASAs via GRASP [RFC8990] or otherwise. Of course, it
Unless its function is very simple, the ASA will need to handle | also interacts with the specific targets of its function, using
overlapping asynchronous operations. It may therefore be a quite | any suitable mechanism. Unless its function is very simple, the
complex piece of software in its own right, forming part of the | ASA will need to handle overlapping asynchronous operations. It
application layer above the ANI." | may therefore be a quite complex piece of software in its own
| right, forming part of the application layer above the ANI.
As mentioned, there will certainly be simple ASAs that manage a As mentioned, there will certainly be simple ASAs that manage a
single objective in a straightforward way and do not need single objective in a straightforward way and do not need
asynchronous operations. In nodes where computing power and memory asynchronous operations. In nodes where computing power and memory
space are limited, ASAs should run at a much lower frequency than the space are limited, ASAs should run at a much lower frequency than the
primary workload, so CPU load should not be a big issue, but memory primary workload, so CPU load should not be a big issue, but memory
footprint in a constrained node is certainly a concern. ASAs footprint in a constrained node is certainly a concern. ASAs
installed in constrained devices will have limited functionality. In installed in constrained devices will have limited functionality. In
such cases, many aspects of the current document do not apply. such cases, many aspects of the current document do not apply.
However, in the general case, an ASA may be a relatively complex However, in the general case, an ASA may be a relatively complex
software component that will in many cases control and monitor software component that will in many cases control and monitor
simpler entities in the same or remote host(s). For example, a simpler entities in the same or remote host(s). For example, a
device controller that manages tens or hundreds of simple devices device controller that manages tens or hundreds of simple devices
might contain a single ASA. might contain a single ASA.
The remainder of this document offers guidance on the design of The remainder of this document offers guidance on the design of
complex ASAs. Some of the material may be familiar to those complex ASAs. Some of the material may be familiar to those
experienced in distributed fault-tolerant and real-time control experienced in distributed fault-tolerant and real-time control
systems. Robustness and security are of particular importance in systems. Robustness and security are of particular importance in
autonomic networks and are discussed in Section 8 and Section 9. autonomic networks and are discussed in Sections 9 and 10.
2. Logical Structure of an Autonomic Service Agent 2. Terminology
This section summarizes various acronyms and terminology used in the
document. Where no other reference is given, please consult
[RFC8993] or [RFC7575].
Autonomic: self-managing (self-configuring, self-protecting, self-
healing, self-optimizing), but allowing high-level guidance by a
central entity such as a NOC
Autonomic Function: a function that adapts on its own to a changing
environment
Autonomic Node: a node that employs autonomic functions
ACP: Autonomic Control Plane [RFC8994]
AN: Autonomic Network; a network of autonomic nodes, which interact
directly with each other
ANI: Autonomic Network Infrastructure
ASA: Autonomic Service Agent; an agent installed on an autonomic
node that implements an autonomic function, either partially (in
the case of a distributed function) or completely
BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995]
CBOR: Concise Binary Object Representation[RFC8949]
GRASP: GeneRric Autonomic Signaling Protocol [RFC8990]
GRASP API: GRASP Application Programming Interface [RFC8991]
NOC: Network Operations Center [RFC8368]
Objective: A GRASP technical objective is a data structure whose
main contents are a name and a value. The value consists of a
single configurable parameter or a set of parameters of some kind
[RFC8990].
3. Logical Structure of an Autonomic Service Agent
As mentioned above, all but the simplest ASAs will need to support As mentioned above, all but the simplest ASAs will need to support
asynchronous operations. Different programming environments support asynchronous operations. Different programming environments support
asynchronicity in different ways. In this document, we use an asynchronicity in different ways. In this document, we use an
explicit multi-threading model to describe operations. This is explicit multi-threading model to describe operations. This is
illustrative, and alternatives to multi-threading are discussed in illustrative, and alternatives to multi-threading are discussed in
detail in connection with the GRASP API (see Section 3.3). detail in connection with the GRASP API (see Section 4.3).
A typical ASA will have a main thread that performs various initial A typical ASA will have a main thread that performs various initial
housekeeping actions such as: housekeeping actions such as:
* Obtain authorization credentials, if needed. * obtain authorization credentials, if needed
* Register the ASA with GRASP. * register the ASA with GRASP
* Acquire relevant policy parameters. * acquire relevant policy parameters
* Declare data structures for relevant GRASP objectives. * declare data structures for relevant GRASP objectives
* Register with GRASP those objectives that it will actively manage. * register with GRASP those objectives that it will actively manage
* Launch a self-monitoring thread. * launch a self-monitoring thread
* Enter its main loop. * enter its main loop
The logic of the main loop will depend on the details of the The logic of the main loop will depend on the details of the
autonomic function concerned. Whenever asynchronous operations are autonomic function concerned. Whenever asynchronous operations are
required, extra threads may be launched. Examples of such threads required, extra threads may be launched. Examples of such threads
include: include:
* Repeatedly flood an objective to the AN, so that any ASA can * repeatedly flood an objective to the AN so that any ASA can
receive the objective's latest value. receive the objective's latest value
* Accept incoming synchronization requests for an objective managed * accept incoming synchronization requests for an objective managed
by this ASA. by this ASA
* Accept incoming negotiation requests for an objective managed by * accept incoming negotiation requests for an objective managed by
this ASA, and then conduct the resulting negotiation with the this ASA, and then conduct the resulting negotiation with the
counterpart ASA. counterpart ASA
* Manage subsidiary non-autonomic devices directly. * manage subsidiary non-autonomic devices directly
These threads should all either exit after their job is done, or These threads should all either exit after their job is done or enter
enter a wait state for new work, to avoid wasting system resources. a wait state for new work to avoid wasting system resources.
According to the degree of parallelism needed by the application, According to the degree of parallelism needed by the application,
some of these threads might be launched in multiple instances. In some of these threads might be launched in multiple instances. In
particular, if negotiation sessions with other ASAs are expected to particular, if negotiation sessions with other ASAs are expected to
be long or to involve wait states, the ASA designer might allow for be long or to involve wait states, the ASA designer might allow for
multiple simultaneous negotiating threads, with appropriate use of multiple simultaneous negotiating threads, with appropriate use of
queues and synchronization primitives to maintain consistency. queues and synchronization primitives to maintain consistency.
The main loop itself could act as the initiator of synchronization The main loop itself could act as the initiator of synchronization
requests or negotiation requests, when the ASA needs data or requests or negotiation requests when the ASA needs data or resources
resources from other ASAs. In particular, the main loop should watch from other ASAs. In particular, the main loop should watch for
for changes in policy parameters that affect its operation, and if changes in policy parameters that affect its operation and, if
appropriate, occasionally refresh authorization credentials. It appropriate, occasionally refresh authorization credentials. It
should also do whatever is required to avoid unnecessary resource should also do whatever is required to avoid unnecessary resource
consumption, for example by limiting its frequency of execution. consumption, for example, by limiting its frequency of execution.
The self-monitoring thread is of considerable importance. Failure of The self-monitoring thread is of considerable importance. Failure of
autonomic service agents is highly undesirable. To a large extent autonomic service agents is highly undesirable. To a large extent,
this depends on careful coding and testing, with no unhandled error this depends on careful coding and testing, with no unhandled error
returns or exceptions, but if there is nevertheless some sort of returns or exceptions, but if there is nevertheless some sort of
failure, the self-monitoring thread should detect it, fix it if failure, the self-monitoring thread should detect it, fix it if
possible, and in the worst case restart the entire ASA. possible, and, in the worst case, restart the entire ASA.
Appendix C presents some example logic flows in informal pseudocode. Appendix A presents some example logic flows in informal pseudocode.
3. Interaction with the Autonomic Networking Infrastructure 4. Interaction with the Autonomic Networking Infrastructure
3.1. Interaction with the security mechanisms 4.1. Interaction with the Security Mechanisms
An ASA by definition runs in an autonomic node. Before any normal An ASA by definition runs in an autonomic node. Before any normal
ASAs are started, such nodes must be bootstrapped into the autonomic ASAs are started, such nodes must be bootstrapped into the autonomic
network's secure key infrastructure, typically in accordance with network's secure key infrastructure, typically in accordance with
[RFC8995]. This key infrastructure will be used to secure the ACP [RFC8995]. This key infrastructure will be used to secure the ACP
(next section) and may be used by ASAs to set up additional secure (next section) and may be used by ASAs to set up additional secure
interactions with their peers, if needed. interactions with their peers, if needed.
Note that the secure bootstrap process itself incorporates simple Note that the secure bootstrap process itself incorporates simple
special-purpose ASAs that use a restricted mode of GRASP (Section 4 special-purpose ASAs that use a restricted mode of GRASP (Section 4
of [RFC8995]). of [RFC8995]).
3.2. Interaction with the Autonomic Control Plane 4.2. Interaction with the Autonomic Control Plane
In a normal autonomic network, ASAs will run as clients of the ACP, In a normal autonomic network, ASAs will run as clients of the ACP,
which will provide a fully secured network environment for all which will provide a fully secured network environment for all
communication with other ASAs, in most cases mediated by GRASP (next communication with other ASAs, in most cases mediated by GRASP (next
section). section).
Note that the ACP formation process itself incorporates simple Note that the ACP formation process itself incorporates simple
special-purpose ASAs that use a restricted mode of GRASP (Section 6.4 special-purpose ASAs that use a restricted mode of GRASP (Section 6.4
of [RFC8994]). of [RFC8994]).
3.3. Interaction with GRASP and its API 4.3. Interaction with GRASP and its API
In a node where a significant number of ASAs are installed, GRASP In a node where a significant number of ASAs are installed, GRASP
[RFC8990] is likely to run as a separate process with its API [RFC8990] is likely to run as a separate process with its API
[RFC8991] available in user space. Thus, ASAs may operate without [RFC8991] available in user space. Thus, ASAs may operate without
special privilege, unless they need it for other reasons. The ASA's special privilege, unless they need it for other reasons. The ASA's
view of GRASP is built around GRASP objectives (Section 5), defined view of GRASP is built around GRASP objectives (Section 6), defined
as data structures containing administrative information such as the as data structures containing administrative information such as the
objective's unique name, and its current value. The format and size objective's unique name, and its current value. The format and size
of the value is not restricted by the protocol, except that it must of the value is not restricted by the protocol, except that it must
be possible to serialise it for transmission in Concise Binary Object be possible to serialize it for transmission in Concise Binary Object
Representation (CBOR) [RFC8949], subject only to GRASP's maximum Representation (CBOR) [RFC8949], subject only to GRASP's maximum
message size as discussed in Section 5. message size as discussed in Section 6.
As discussed in Section 2, GRASP is an asynchronous protocol, and As discussed in Section 3, GRASP is an asynchronous protocol, and
this document uses a multi-threading model to describe operations. this document uses a multi-threading model to describe operations.
In many programming environments, an 'event loop' model is used In many programming environments, an "event loop" model is used
instead, in which case each thread would be implemented as an event instead, in which case each thread would be implemented as an event
handler called in turn by the main loop. For this case, the GRASP handler called in turn by the main loop. For this case, the GRASP
API must provide non-blocking calls and possibly support callbacks. API must provide non-blocking calls and possibly support callbacks.
This topic is discussed in more detail in [RFC8991], and other This topic is discussed in more detail in [RFC8991], and other
asynchronicity models are also possible. Whenever necessary, the asynchronicity models are also possible. Whenever necessary, the
GRASP session identifier will be used to distinguish simultaneous GRASP session identifier will be used to distinguish simultaneous
operations. operations.
The GRASP API should offer the following features: The GRASP API should offer the following features:
* Registration functions, so that an ASA can register itself and the * Registration functions, so that an ASA can register itself and the
objectives that it manages. objectives that it manages.
* A discovery function, by which an ASA can discover other ASAs * A discovery function, by which an ASA can discover other ASAs
supporting a given objective. supporting a given objective.
* A negotiation request function, by which an ASA can start * A negotiation request function, by which an ASA can start
negotiation of an objective with a counterpart ASA. With this, negotiation of an objective with a counterpart ASA. With this,
there is a corresponding listening function for an ASA that wishes there is a corresponding listening function for an ASA that wishes
to respond to negotiation requests, and a set of functions to to respond to negotiation requests and a set of functions to
support negotiating steps. Once a negotiation starts, it is a support negotiating steps. Once a negotiation starts, it is a
symmetric process with both sides sending successive objective symmetric process with both sides sending successive objective
values to each other until agreement is reached (or the values to each other until agreement is reached (or the
negotiation fails). negotiation fails).
* A synchronization function, by which an ASA can request the * A synchronization function, by which an ASA can request the
current value of an objective from a counterpart ASA. With this, current value of an objective from a counterpart ASA. With this,
there is a corresponding listening function for an ASA that wishes there is a corresponding listening function for an ASA that wishes
to respond to synchronization requests. Unlike negotiation, to respond to synchronization requests. Unlike negotiation,
synchronization is an asymmetric process in which the listener synchronization is an asymmetric process in which the listener
skipping to change at page 8, line 21 skipping to change at line 376
* A flood function, by which an ASA can cause the current value of * A flood function, by which an ASA can cause the current value of
an objective to be flooded throughout the AN so that any ASA can an objective to be flooded throughout the AN so that any ASA can
receive it. receive it.
For further details and some additional housekeeping functions, see For further details and some additional housekeeping functions, see
[RFC8991]. [RFC8991].
The GRASP API is intended to support the various interactions The GRASP API is intended to support the various interactions
expected between most ASAs, such as the interactions outlined in expected between most ASAs, such as the interactions outlined in
Section 2. However, if ASAs require additional communication between Section 3. However, if ASAs require additional communication between
themselves, they can do so directly over the ACP to benefit from its themselves, they can do so directly over the ACP to benefit from its
security. One option is to use GRASP discovery and synchronization security. One option is to use GRASP discovery and synchronization
as a rendez-vous mechanism between two ASAs, passing communication as a rendezvous mechanism between two ASAs, passing communication
parameters such as a TCP port number via GRASP. The use of TLS over parameters such as a TCP port number via GRASP. The use of TLS over
the ACP for such communications is advisable, as described in the ACP for such communications is advisable, as described in
Section 6.9.2 of [RFC8994]. Section 6.9.2 of [RFC8994].
3.4. Interaction with policy mechanisms 4.4. Interaction with Policy Mechanisms
At the time of writing, the policy mechanisms for the ANI are At the time of writing, the policy mechanisms for the ANI are
undefined. In particular, the use of declarative policies (aka undefined. In particular, the use of declarative policies (aka
Intents) for the definition and management of ASA's behaviors remains Intents) for the definition and management of an ASA's behaviors
a research topic [I-D.irtf-nmrg-ibn-concepts-definitions]. remains a research topic [IBN-CONCEPTS].
In the cases where ASAs are defined as closed control loops, the In the cases where ASAs are defined as closed control loops, the
specifications defined in [ZSM009-1] regarding imperative and specifications defined in [ZSM009-1] regarding imperative and
declarative goal statements may be applicable. declarative goal statements may be applicable.
In the ANI, policy dissemination is expected to operate by an In the ANI, policy dissemination is expected to operate by an
information distribution mechanism (e.g. via GRASP [RFC8990]) that information distribution mechanism (e.g., via GRASP [RFC8990]) that
can reach all autonomic nodes, and therefore every ASA. However, can reach all autonomic nodes and therefore every ASA. However, each
each ASA must be capable of operating "out of the box" in the absence ASA must be capable of operating "out of the box" in the absence of
of locally defined policy, so every ASA implementation must include locally defined policy, so every ASA implementation must include
carefully chosen default values and settings for all policy carefully chosen default values and settings for all policy
parameters. parameters.
4. Interaction with Non-Autonomic Components and Systems 5. Interaction with Non-autonomic Components and Systems
An ASA, to have any external effects, must also interact with non- To have any external effects, an ASA must also interact with non-
autonomic components of the node where it is installed. For example, autonomic components of the node where it is installed. For example,
an ASA whose purpose is to manage a resource must interact with that an ASA whose purpose is to manage a resource must interact with that
resource. An ASA managing an entity that is also managed by local resource. An ASA managing an entity that is also managed by local
software must interact with that software. For example, if such software must interact with that software. For example, if such
management is performed by NETCONF [RFC6241], the ASA must interact management is performed by NETCONF [RFC6241], the ASA must interact
with the NETCONF server as an independent NETCONF client in the same with the NETCONF server as an independent NETCONF client in the same
node to avoid any inconsistency between configuration changes node to avoid any inconsistency between configuration changes
delivered via NETCONF and configuration changes made by the ASA. delivered via NETCONF and configuration changes made by the ASA.
In an environment where systems are virtualized and specialized using In an environment where systems are virtualized and specialized using
techniques such as network function virtualization or network techniques such as network function virtualization or network
slicing, there will be a design choice whether ASAs are deployed once slicing, there will be a design choice whether ASAs are deployed once
per physical node or once per virtual context. A related issue is per physical node or once per virtual context. A related issue is
whether the ANI as a whole is deployed once on a physical network, or whether the ANI as a whole is deployed once on a physical network or
whether several virtual ANIs are deployed. This aspect needs to be whether several virtual ANIs are deployed. This aspect needs to be
considered by the ASA designer. considered by the ASA designer.
5. Design of GRASP Objectives 6. Design of GRASP Objectives
The design of an ASA will often require the design of a new GRASP The design of an ASA will often require the design of a new GRASP
objective. The general rules for the format of GRASP objectives, objective. The general rules for the format of GRASP objectives,
their names, and IANA registration are given in [RFC8990]. their names, and IANA registration are given in [RFC8990].
Additionally, that document discusses various general considerations Additionally, that document discusses various general considerations
for the design of objectives, which are not repeated here. However, for the design of objectives, which are not repeated here. However,
note that the GRASP protocol, like HTTP, does not provide note that GRASP, like HTTP, does not provide transactional integrity.
transactional integrity. In particular, steps in a GRASP negotiation In particular, steps in a GRASP negotiation are not idempotent. The
are not idempotent. The design of a GRASP objective and the logic design of a GRASP objective and the logic flow of the ASA should take
flow of the ASA should take this into account. One approach, which this into account. One approach, which should be used when possible,
should be used when possible, is to design objectives with idempotent is to design objectives with idempotent semantics. If this is not
semantics. If this is not possible, typically if an ASA is possible, typically if an ASA is allocating part of a shared resource
allocating part of a shared resource to other ASAs, it needs to to other ASAs, it needs to ensure that the same part of the resource
ensure that the same part of the resource is not allocated twice. is not allocated twice. The easiest way is to run only one
The easiest way is to run only one negotiation at a time. If an ASA negotiation at a time. If an ASA is capable of overlapping several
is capable of overlapping several negotiations, it must avoid negotiations, it must avoid interference between these negotiations.
interference between these negotiations.
Negotiations will always end, normally because one end or the other Negotiations will always end, normally because one end or the other
declares success or failure. If this does not happen, either a declares success or failure. If this does not happen, either a
timeout or exhaustion of the loop count will occur. The definition timeout or exhaustion of the loop count will occur. The definition
of a GRASP objective should describe a specific negotiation policy if of a GRASP objective should describe a specific negotiation policy if
it is not self-evident. it is not self-evident.
GRASP allows a 'dry run' mode of negotiation, where a negotiation GRASP allows a "dry run" mode of negotiation, where a negotiation
session follows its normal course but is not committed at either end session follows its normal course but is not committed at either end
until a subsequent live negotiation session. If 'dry run' mode is until a subsequent live negotiation session. If dry run mode is
defined for the objective, its specification, and every defined for the objective, its specification, and every
implementation, must consider what state needs to be saved following implementation, must consider what state needs to be saved following
a dry run negotiation, such that a subsequent live negotiation can be a dry run negotiation, such that a subsequent live negotiation can be
expected to succeed. It must be clear how long this state is kept, expected to succeed. It must be clear how long this state is kept
and what happens if the live negotiation occurs after this state is and what happens if the live negotiation occurs after this state is
deleted. An ASA that requests a dry run negotiation must take deleted. An ASA that requests a dry run negotiation must take
account of the possibility that a successful dry run is followed by a account of the possibility that a successful dry run is followed by a
failed live negotiation. Because of these complexities, the dry run failed live negotiation. Because of these complexities, the dry run
mechanism should only be supported by objectives and ASAs where there mechanism should only be supported by objectives and ASAs where there
is a significant benefit from it. is a significant benefit from it.
The actual value field of an objective is limited by the GRASP The actual value field of an objective is limited by the GRASP
protocol definition to any data structure that can be expressed in protocol definition to any data structure that can be expressed in
Concise Binary Object Representation (CBOR) [RFC8949]. For some Concise Binary Object Representation (CBOR) [RFC8949]. For some
objectives, a single data item will suffice; for example an integer, objectives, a single data item will suffice, for example, an integer,
a floating point number, a UTF-8 string or an arbitrary byte string. a floating point number, a UTF-8 string, or an arbitrary byte string.
For more complex cases, a simple tuple structure such as [item1, For more complex cases, a simple tuple structure such as [item1,
item2, item3] could be used. Since CBOR is closely linked to JSON, item2, item3] could be used. Since CBOR is closely linked to JSON,
it is also rather easy to define an objective whose value is a JSON it is also rather easy to define an objective whose value is a JSON
structure. The formats acceptable by the GRASP API will limit the structure. The formats acceptable by the GRASP API will limit the
options in practice. A generic solution is for the API to accept and options in practice. A generic solution is for the API to accept and
deliver the value field in raw CBOR, with the ASA itself encoding and deliver the value field in raw CBOR, with the ASA itself encoding and
decoding it via a CBOR library (section 2.3.2.4 of [RFC8991]). decoding it via a CBOR library (Section 2.3.2.4 of [RFC8991]).
The maximum size of the value field of an objective is limited by the The maximum size of the value field of an objective is limited by the
GRASP maximum message size. If the default maximum size specified as GRASP maximum message size. If the default maximum size specified as
GRASP_DEF_MAX_SIZE by [RFC8990] is not enough, the specification of GRASP_DEF_MAX_SIZE by [RFC8990] is not enough, the specification of
the objective must indicate the required maximum message size, both the objective must indicate the required maximum message size for
for unicast and multicast messages. both unicast and multicast messages.
A mapping from YANG to CBOR is defined by [I-D.ietf-core-yang-cbor]. A mapping from YANG to CBOR is defined by [CBOR-YANG]. Subject to
Subject to the size limit defined for GRASP messages, nothing the size limit defined for GRASP messages, nothing prevents
prevents objectives transporting YANG in this way. objectives transporting YANG in this way.
The flexibility of CBOR implies that the value field of many The flexibility of CBOR implies that the value field of many
objectives can be extended in service, to add additional information objectives can be extended in service, to add additional information
or alternative content, especially if JSON-like structures are used. or alternative content, especially if JSON-like structures are used.
This has consequences for the robustness of ASAs, as discussed in This has consequences for the robustness of ASAs, as discussed in
Section 8. Section 9.
6. Life Cycle 7. Life Cycle
The ASA life cycle was discussed in The ASA life cycle is discussed in [AUTONOMIC-FUNCTION], from which
[I-D.peloso-anima-autonomic-function], from which the following text the following text was derived. It does not cover all details, and
was derived. It does not cover all details, and some of the terms some of the terms used would require precise definitions in a given
used would require precise definitions in a given implementation. implementation.
In simple cases, Autonomic functions could be permanent, in the sense In simple cases, autonomic functions could be permanent, in the sense
that ASAs are shipped as part of a product and persist throughout the that ASAs are shipped as part of a product and persist throughout the
product's life. However, in complex cases, a more likely situation product's life. However, in complex cases, a more likely situation
is that ASAs need to be installed or updated dynamically, because of is that ASAs need to be installed or updated dynamically because of
new requirements or bugs. This section describes one approach to the new requirements or bugs. This section describes one approach to the
resulting life cycle of individual ASAs. It does not consider wider resulting life cycle of individual ASAs. It does not consider wider
issues such as updates of shared libraries. issues such as updates of shared libraries.
Because continuity of service is fundamental to autonomic networking, Because continuity of service is fundamental to autonomic networking,
the process of seamlessly replacing a running instance of an ASA with the process of seamlessly replacing a running instance of an ASA with
a new version needs to be part of the ASA's design. The implication a new version needs to be part of the ASA's design. The implication
of service continuity on the design of ASAs can be illustrated along of service continuity on the design of ASAs can be illustrated along
the three main phases of the ASA life cycle, namely Installation, the three main phases of the ASA life cycle, namely installation,
Instantiation and Operation. instantiation, and operation.
+--------------+ +--------------+
Undeployed ------>| |------> Undeployed Undeployed ------>| |------> Undeployed
| Installed | | Installed |
+-->| |---+ +-->| |---+
Mandate | +--------------+ | Receives a Mandate | +--------------+ | Receives a
is revoked | +--------------+ | Mandate is revoked | +--------------+ | Mandate
+---| |<--+ +---| |<--+
| Instantiated | | Instantiated |
+-->| |---+ +-->| |---+
set | +--------------+ | set set | +--------------+ | set
down | +--------------+ | up down | +--------------+ | up
+---| |<--+ +---| |<--+
| Operational | | Operational |
| | | |
+--------------+ +--------------+
Figure 1: Life Cycle of an Autonomic Service Agent Figure 1: Life Cycle of an Autonomic Service Agent
6.1. Installation phase 7.1. Installation Phase
We define "installation" to mean that a piece of software is loaded We define "installation" to mean that a piece of software is loaded
into a device, along with any necessary libraries, but is not yet into a device, along with any necessary libraries, but is not yet
activated. activated.
Before being able to instantiate and run ASAs, the operator will Before being able to instantiate and run ASAs, the operator will
first provision the infrastructure with the sets of ASA software first provision the infrastructure with the sets of ASA software
corresponding to its needs and objectives. Such software must be corresponding to its needs and objectives. Such software must be
checked for integrity and authenticity before installation. The checked for integrity and authenticity before installation. The
provisioning of the infrastructure is realized in the installation provisioning of the infrastructure is realized in the installation
phase and consists of installing (or checking the availability of) phase and consists of installing (or checking the availability of)
the pieces of software of the different ASAs in a set of Installation the pieces of software of the different ASAs in a set of Installation
Hosts within the autonomic network. Hosts within the autonomic network.
There are 3 properties applicable to the installation of ASAs: There are three properties applicable to the installation of ASAs:
* The dynamic installation property allows installing an ASA on * The dynamic installation property allows installing an ASA on
demand, on any hosts compatible with the ASA. demand, on any hosts compatible with the ASA.
* The decoupling property allows an ASA on one machine to control * The decoupling property allows an ASA on one machine to control
resources in another machine (known as "decoupled mode"). resources in another machine (known as "decoupled mode").
* The multiplicity property allows controlling multiple sets of * The multiplicity property allows controlling multiple sets of
resources from a single ASA. resources from a single ASA.
These three properties are very important in the context of the These three properties are very important in the context of the
installation phase as their variations condition how the ASA could be installation phase as their variations condition how the ASA could be
installed on the infrastructure. installed on the infrastructure.
6.1.1. Installation phase inputs and outputs 7.1.1. Installation Phase Inputs and Outputs
Inputs are: Inputs are:
* [ASA_type] specifies which ASA to install. * [ASA_type]: specifies which ASA to install.
* [Installation_target_infrastructure] specifies the candidate * [Installation_target_infrastructure]: specifies the candidate
installation Hosts. installation Hosts.
* [ASA_placement_function] specifies how the installation phase will * [ASA_placement_function]: specifies how the installation phase
meet the operator's needs and objectives for the provision of the will meet the operator's needs and objectives for the provision of
infrastructure. This function is only useful in the decoupled the infrastructure. This function is only useful in the decoupled
mode. It can be as simple as an explicit list of hosts on which mode. It can be as simple as an explicit list of hosts on which
the ASAs are to be installed, or it could consist of operator- the ASAs are to be installed, or it could consist of operator-
defined criteria and constraints. defined criteria and constraints.
The main output of the installation phase is a [List_of_ASAs] The main output of the installation phase is a [List_of_ASAs]
installed on [List_of_hosts]. This output is also useful for the installed on [List_of_hosts]. This output is also useful for the
coordination function where it acts as a static interaction map (see coordination function where it acts as a static interaction map (see
Section 7.1). Section 8.1).
The condition to validate in order to pass to next phase is to ensure The condition to validate in order to pass to next phase is to ensure
that [List_of_ASAs] are correctly installed on [List_of_hosts]. A that [List_of_ASAs] are correctly installed on [List_of_hosts]. A
minimum set of primitives to support the installation of ASAs could minimum set of primitives to support the installation of ASAs could
be: install(List_of_ASAs, Installation_target_infrastructure, be the following: install (List_of_ASAs,
ASA_placement_function), and uninstall (List_of_ASAs). Installation_target_infrastructure, ASA_placement_function) and
uninstall (List_of_ASAs).
6.2. Instantiation phase 7.2. Instantiation Phase
We define "instantiation" as the operation of creating a single ASA We define "instantiation" as the operation of creating a single ASA
instance from the corresponding piece of installed software. instance from the corresponding piece of installed software.
Once the ASAs are installed on the appropriate hosts in the network, Once the ASAs are installed on the appropriate hosts in the network,
these ASAs may start to operate. From the operator viewpoint, an these ASAs may start to operate. From the operator viewpoint, an
operating ASA means the ASA manages the network resources as per the operating ASA means the ASA manages the network resources as per the
objectives given. At the ASA local level, operating means executing objectives given. At the ASA local level, operating means executing
their control loop algorithm. their control loop algorithm.
There are two apsects to take into consideration. First, having a There are two aspects to take into consideration. First, having a
piece of code installed and available to run on a host is not the piece of code installed and available to run on a host is not the
same as having an agent based on this piece of code running inside same as having an agent based on this piece of code running inside
the host. Second, in a coupled case, determining which resources are the host. Second, in a coupled case, determining which resources are
controlled by an ASA is straightforward (the ASA runs on the same controlled by an ASA is straightforward (the ASA runs on the same
autonomic node as the resources it is controlling); in a decoupled autonomic node as the resources it is controlling). In a decoupled
mode determining this is a bit more complex: a starting agent will mode, determining this is a bit more complex: a starting agent will
have to either discover the set of resources it ought to control, or have to either discover the set of resources it ought to control, or
such information has to be communicated to the ASA. such information has to be communicated to the ASA.
The instantiation phase of an ASA covers both these aspects: starting The instantiation phase of an ASA covers both these aspects: starting
the agent code (when this does not start automatically) and the agent code (when this does not start automatically) and
determining which resources have to be controlled (when this is not determining which resources have to be controlled (when this is not
straightforward). straightforward).
6.2.1. Operator's goal 7.2.1. Operator's Goal
Through this phase, the operator wants to control its autonomic Through this phase, the operator wants to control its autonomic
network regarding at least two aspects: network regarding at least two aspects:
1 determine the scope of autonomic functions by instructing which 1. determine the scope of autonomic functions by instructing which
network resources have to be managed by which autonomic function network resources have to be managed by which autonomic function
(and more precisely by which release of the ASA software code, (and more precisely by which release of the ASA software code,
e.g., version number or provider), e.g., version number or provider).
2 determine how the autonomic functions are organized by 2. determine how the autonomic functions are organized by
instantiating a set of ASAs across one or more autonomic nodes and instantiating a set of ASAs across one or more autonomic nodes
instructing them accordingly about the other ASAs in the set as and instructing them accordingly about the other ASAs in the set
necessary. as necessary.
In this phase, the operator may also want to set goals for autonomic In this phase, the operator may also want to set goals for autonomic
functions, e.g., by configuring GRASP objectives. functions, e.g., by configuring GRASP objectives.
The operator's goal can be summarized in an instruction to the The operator's goal can be summarized in an instruction to the
autonomic ecosystem matching the following format, explained in autonomic ecosystem matching the following format, explained in
detail in the next sub-section: detail in the next sub-section:
[Instances_of_ASA_type] ready to control [Instances_of_ASA_type] ready to control
[Instantiation_target_infrastructure] with [Instantiation_target_infrastructure] with
[Instantiation_target_parameters] [Instantiation_target_parameters]
6.2.2. Instantiation phase inputs and outputs 7.2.2. Instantiation Phase Inputs and Outputs
Inputs are: Inputs are:
* [Instances_of_ASA_type] that specifies which ASAs to instantiate * [Instances_of_ASA_type]: specifies which ASAs to instantiate
* [Instantiation_target_infrastructure] that specifies which are the * [Instantiation_target_infrastructure]: specifies which resources
resources to be managed by the autonomic function; this can be the are to be managed by the autonomic function; this can be the whole
whole network or a subset of it like a domain, a physical segment network or a subset of it like a domain, a physical segment, or
or even a specific list of resources, even a specific list of resources.
* [Instantiation_target_parameters] that specifies which are the * [Instantiation_target_parameters]: specifies which GRASP
GRASP objectives to be sent to ASAs (e.g., an optimization target) objectives are to be sent to ASAs (e.g., an optimization target)
Outputs are: Outputs are:
* [Set_of_ASA_resources_relations] describing which resources are * [Set_of_ASA_resources_relations]: describes which resources are
managed by which ASA instances; this is not a formal message, but managed by which ASA instances; this is not a formal message but a
a resulting configuration log for a set of ASAs. resulting configuration log for a set of ASAs.
6.2.3. Instantiation phase requirements 7.2.3. Instantiation Phase Requirements
The instructions described in Section 6.2 could be either: The instructions described in Section 7.2 could be either of the
following:
* Sent to a targeted ASA. In the case, the receiving Agent will * Sent to a targeted ASA. In this case, the receiving Agent will
have to manage the specified list of have to manage the specified list of
[Instantiation_target_infrastructure], with the [Instantiation_target_infrastructure], with the
[Instantiation_target_parameters]. [Instantiation_target_parameters].
* Broadcast to all ASAs. In this case, the ASAs would determine * Broadcast to all ASAs. In this case, the ASAs would determine
from the list which ASAs would handle which from the list which ASAs would handle which
[Instantiation_target_infrastructure], with the [Instantiation_target_infrastructure], with the
[Instantiation_target_parameters]. [Instantiation_target_parameters].
These instructions may be grouped as a specific data structure, These instructions may be grouped as a specific data structure
referred to as an ASA Instance Mandate. The specification of such an referred to as an ASA Instance Mandate. The specification of such an
ASA Instance Mandate is beyond the scope of this document. ASA Instance Mandate is beyond the scope of this document.
The conclusion of this instantiation phase is a set of ASA instances The conclusion of this instantiation phase is a set of ASA instances
ready to operate. These ASA instances are characterized by the ready to operate. These ASA instances are characterized by the
resources they manage, the metrics being monitored and the actions resources they manage, the metrics being monitored, and the actions
that can be executed (like modifying certain parameters values). The that can be executed (like modifying certain parameter values). The
description of the ASA instance may be defined in an ASA Instance description of the ASA instance may be defined in an ASA Instance
Manifest data structure. The specification of such an ASA Instance Manifest data structure. The specification of such an ASA Instance
Manifest is beyond the scope of this document. Manifest is beyond the scope of this document.
The ASA Instance Manifest does not only serve informational purposes The ASA Instance Manifest does not only serve informational purposes
such as acknowledgement of successful instantiation to the operator, such as acknowledgement of successful instantiation to the operator
but is also necessary for further autonomic operations with: but is also necessary for further autonomic operations with:
* coordinated entities (see Section 7.1) * coordinated entities (see Section 8.1)
* collaborative entities with purposes such as to establish * collaborative entities with purposes such as to establish
knowledge exchange (some ASAs may produce knowledge or monitor knowledge exchange (some ASAs may produce knowledge or monitor
metrics that would be useful for other ASAs) metrics that would be useful for other ASAs)
6.3. Operation phase 7.3. Operation Phase
During the Operation phase, the operator can: During the operation phase, the operator can:
* Activate/Deactivate ASAs: enable/disable their autonomic loops. * activate/deactivate ASAs: enable/disable their autonomic loops
* Modify ASAs targets: set different technical objectives. * modify ASA targets: set different technical objectives
* Modify ASAs managed resources: update the instance mandate to * modify ASAs managed resources: update the Instance Mandate to
specify a different set of resources to manage (only applicable to specify a different set of resources to manage (only applicable to
decoupled ASAs). decoupled ASAs)
During the Operation phase, running ASAs can interact with other During the operation phase, running ASAs can interact with other
ASAs: ASAs:
* in order to exchange knowledge (e.g. an ASA providing traffic * in order to exchange knowledge (e.g., an ASA providing traffic
predictions to a load balancing ASA) predictions to a load balancing ASA)
* in order to collaboratively reach an objective (e.g. ASAs * in order to collaboratively reach an objective (e.g., ASAs
pertaining to the same autonomic function will collaborate, e.g., pertaining to the same autonomic function will collaborate, e.g.,
in the case of a load balancing function, by modifying link in the case of a load balancing function, by modifying link
metrics according to neighboring resource loads) metrics according to neighboring resource loads)
During the Operation phase, running ASAs are expected to apply During the operation phase, running ASAs are expected to apply
coordination schemes as per Section 7.1. coordination schemes as per Section 8.1.
6.4. Removal phase 7.4. Removal Phase
When an ASA is removed from service and uninstalled, the above steps When an ASA is removed from service and uninstalled, the above steps
are reversed. It is important that its data, especially any security are reversed. It is important that its data, especially any security
key material, is purged. key material, is purged.
7. Coordination and Data Models 8. Coordination and Data Models
7.1. Coordination between Autonomic Functions 8.1. Coordination between Autonomic Functions
Some autonomic functions will be completely independent of each Some autonomic functions will be completely independent of each
other. However, others are at risk of interfering with each other - other. However, others are at risk of interfering with each other;
for example, two different optimization functions might both attempt for example, two different optimization functions might both attempt
to modify the same underlying parameter in different ways. In a to modify the same underlying parameter in different ways. In a
complete system, a method is needed of identifying ASAs that might complete system, a method is needed for identifying ASAs that might
interfere with each other and coordinating their actions when interfere with each other and coordinating their actions when
necessary. necessary.
7.2. Coordination with Traditional Management Functions 8.2. Coordination with Traditional Management Functions
Some ASAs will have functions that overlap with existing Some ASAs will have functions that overlap with existing
configuration tools and network management mechanisms such as command configuration tools and network management mechanisms such as
line interfaces, DHCP, DHCPv6, SNMP, NETCONF, and RESTCONF. This is command-line interfaces, DHCP, DHCPv6, SNMP, NETCONF, and RESTCONF.
of course an existing problem whenever multiple configuration tools This is, of course, an existing problem whenever multiple
are in use by the NOC. Each ASA designer will need to consider this configuration tools are in use by the NOC. Each ASA designer will
issue and how to avoid clashes and inconsistencies in various need to consider this issue and how to avoid clashes and
deployment scenarios. Some specific considerations for interaction inconsistencies in various deployment scenarios. Some specific
with OAM tools are given in [RFC8368]. As another example, [RFC8992] considerations for interaction with OAM tools are given in [RFC8368].
describes how autonomic management of IPv6 prefixes can interact with As another example, [RFC8992] describes how autonomic management of
prefix delegation via DHCPv6. The description of a GRASP objective IPv6 prefixes can interact with prefix delegation via DHCPv6. The
and of an ASA using it should include a discussion of any such description of a GRASP objective and of an ASA using it should
interactions. include a discussion of any such interactions.
7.3. Data Models 8.3. Data Models
Management functions often include a shared data model, quite likely Management functions often include a shared data model, quite likely
to be expressed in a formal notation such as YANG. This aspect to be expressed in a formal notation such as YANG. This aspect
should not be an afterthought in the design of an ASA. To the should not be an afterthought in the design of an ASA. To the
contrary, the design of the ASA and of its GRASP objectives should contrary, the design of the ASA and of its GRASP objectives should
match the data model; as noted in Section 5, YANG serialized as CBOR match the data model; as noted in Section 6, YANG serialized as CBOR
may be used directly as the value of a GRASP objective. may be used directly as the value of a GRASP objective.
8. Robustness 9. Robustness
It is of great importance that all components of an autonomic system It is of great importance that all components of an autonomic system
are highly robust. Although ASA designers should aim for their are highly robust. Although ASA designers should aim for their
component to never fail, it is more important to design the ASA to component to never fail, it is more important to design the ASA to
assume that failures will happen and to gracefully recover from those assume that failures will happen and to gracefully recover from those
failures when they occur. Hence, this section lists various aspects failures when they occur. Hence, this section lists various aspects
of robustness that ASA designers should consider: of robustness that ASA designers should consider:
1. If despite all precautions, an ASA does encounter a fatal error, 1. If despite all precautions, an ASA does encounter a fatal error,
it should in any case restart automatically and try again. To it should in any case restart automatically and try again. To
skipping to change at page 17, line 32 skipping to change at line 792
out of bounds, the corresponding parameter should be either left out of bounds, the corresponding parameter should be either left
unchanged or restored to a value known to be safe in all unchanged or restored to a value known to be safe in all
configurations. configurations.
3. If a GRASP synchronization or negotiation session fails for any 3. If a GRASP synchronization or negotiation session fails for any
reason, it may be repeated after a suitable pause. The length reason, it may be repeated after a suitable pause. The length
of the pause depends on the use case; randomization and of the pause depends on the use case; randomization and
exponential backoff should be considered. exponential backoff should be considered.
4. If a session fails repeatedly, the ASA should consider that its 4. If a session fails repeatedly, the ASA should consider that its
peer has failed, and cause GRASP to flush its discovery cache peer has failed, and it should cause GRASP to flush its
and repeat peer discovery. discovery cache and repeat peer discovery.
5. In any case, it may be prudent to repeat discovery periodically, 5. In any case, it may be prudent to repeat discovery periodically,
depending on the use case. depending on the use case.
6. Any received GRASP message should be checked. If it is wrongly 6. Any received GRASP message should be checked. If it is wrongly
formatted, it should be ignored. Within a unicast session, an formatted, it should be ignored. Within a unicast session, an
Invalid message (M_INVALID) may be sent. This function may be Invalid message (M_INVALID) may be sent. This function may be
provided by the GRASP implementation itself. provided by the GRASP implementation itself.
7. Any received GRASP objective should be checked. Basic 7. Any received GRASP objective should be checked. Basic
skipping to change at page 18, line 15 skipping to change at line 822
8. On the other hand, the definitions of GRASP objectives are very 8. On the other hand, the definitions of GRASP objectives are very
likely to be extended, using the flexibility of CBOR or JSON. likely to be extended, using the flexibility of CBOR or JSON.
Therefore, ASAs should be able to deal gracefully with unknown Therefore, ASAs should be able to deal gracefully with unknown
components within the values of objectives. The specification components within the values of objectives. The specification
of an objective should describe how unknown components are to be of an objective should describe how unknown components are to be
handled (ignored, logged and ignored, or rejected as an error). handled (ignored, logged and ignored, or rejected as an error).
9. If an ASA receives either an Invalid message (M_INVALID) or a 9. If an ASA receives either an Invalid message (M_INVALID) or a
Negotiation End message (M_END) with a Decline option Negotiation End message (M_END) with a Decline option
(O_DECLINE), one possible reason is that the peer ASA does not (O_DECLINE), one possible reason is that the peer ASA does not
support a new feature of either GRASP or of the objective in support a new feature of either GRASP or the objective in
question. In such a case the ASA may choose to repeat the question. In such a case, the ASA may choose to repeat the
operation concerned without using that new feature. operation concerned without using that new feature.
10. All other possible exceptions should be handled in an orderly 10. All other possible exceptions should be handled in an orderly
way. There should be no such thing as an unhandled exception way. There should be no such thing as an unhandled exception
(but see point 1 above). (but see point 1 above).
At a slightly more general level, ASAs are not services in At a slightly more general level, ASAs are not services in
themselves, but they automate services. This has a fundamental themselves, but they automate services. This has a fundamental
impact on how to design robust ASAs. In general, when an ASA impact on how to design robust ASAs. In general, when an ASA
observes a particular state (1) of operations of the services/ observes a particular state (1) of operations of the services/
resources it controls, it typically aims to improve this state to a resources it controls, it typically aims to improve this state to a
better state, say (2). Ideally, the ASA is built so that it can better state, say (2). Ideally, the ASA is built so that it can
ensure that any error encountered can still lead to returning to (1) ensure that any error encountered can still lead to returning to (1)
instead of a state (3) which is worse than (1). One example instance instead of a state (3), which is worse than (1). One example
of this principle is "make-before-break" used in reconfiguration of instance of this principle is "make-before-break" used in
routing protocols in manual operations. This principle of operations reconfiguration of routing protocols in manual operations. This
can accordingly be coded into the operation of an ASA. The GRASP dry principle of operations can accordingly be coded into the operation
run option mentioned in Section 5 is another tool helpful for this of an ASA. The GRASP dry run option mentioned in Section 6 is
ASA design goal of "test-before-make". another tool helpful for this ASA design goal of "test-before-make".
9. Security Considerations 10. Security Considerations
ASAs are intended to run in an environment that is protected by the ASAs are intended to run in an environment that is protected by the
Autonomic Control Plane [RFC8994], admission to which depends on an Autonomic Control Plane [RFC8994], admission to which depends on an
initial secure bootstrap process such as BRSKI [RFC8995]. Those initial secure bootstrap process such as BRSKI [RFC8995]. Those
documents describe security considerations relating to the use of and documents describe security considerations relating to the use of and
properties provided by the ACP and BRSKI, respectively. Such an ACP properties provided by the ACP and BRSKI, respectively. Such an ACP
can provide keying material for mutual authentication between ASAs as can provide keying material for mutual authentication between ASAs as
well as confidential communication channels for messages between well as confidential communication channels for messages between
ASAs. In some deployments, a secure partition of the link layer ASAs. In some deployments, a secure partition of the link layer
might be used instead. GRASP itself has significant security might be used instead. GRASP itself has significant security
considerations [RFC8990]. However, this does not relieve ASAs of considerations [RFC8990]. However, this does not relieve ASAs of
responsibility for security. When ASAs configure or manage network responsibility for security. When ASAs configure or manage network
elements outside the ACP, potentially in a different physical node, elements outside the ACP, potentially in a different physical node,
they must interact with other non-autonomic software components to they must interact with other non-autonomic software components to
perform their management functions. The details are specific to each perform their management functions. The details are specific to each
case, but this has an important security implication. An ASA might case, but this has an important security implication. An ASA might
act as a loophole by which the managed entity could penetrate the act as a loophole by which the managed entity could penetrate the
security boundary of the ANI. Thus, ASAs must be designed to avoid security boundary of the ANI. Thus, ASAs must be designed to avoid
loopholes such as passing on executable code or proxying unverified loopholes such as passing on executable code or proxying unverified
commands, and should if possible operate in an unprivileged mode. In commands and should, if possible, operate in an unprivileged mode.
particular, they must use secure coding practices, e.g., carefully In particular, they must use secure coding practices, e.g., carefully
validate all incoming information and avoid unnecessary elevation of validate all incoming information and avoid unnecessary elevation of
privilege. This will apply in particular when an ASA interacts with privilege. This will apply in particular when an ASA interacts with
a management component such as a NETCONF server. a management component such as a NETCONF server.
A similar situation will arise if an ASA acts as a gateway between A similar situation will arise if an ASA acts as a gateway between
two separate autonomic networks, i.e. it has access to two separate two separate autonomic networks, i.e., it has access to two separate
ACPs. Such an ASA must also be designed to avoid loopholes and to ACPs. Such an ASA must also be designed to avoid loopholes and to
validate incoming information from both sides. validate incoming information from both sides.
As a reminder, GRASP does not intrinsically provide transactional As a reminder, GRASP does not intrinsically provide transactional
integrity (Section 5). integrity (Section 6).
As appropriate to their specific functions, ASAs should take account As appropriate to their specific functions, ASAs should take account
of relevant privacy considerations [RFC6973]. of relevant privacy considerations [RFC6973].
The initial version of the autonomic infrastructure assumes that all The initial version of the autonomic infrastructure assumes that all
autonomic nodes are trusted by virtue of their admission to the ACP. autonomic nodes are trusted by virtue of their admission to the ACP.
ASAs are therefore trusted to manipulate any GRASP objective, simply ASAs are therefore trusted to manipulate any GRASP objective simply
because they are installed on a node that has successfully joined the because they are installed on a node that has successfully joined the
ACP. In the general case, a node may have multiple roles and a role ACP. In the general case, a node may have multiple roles, and a role
may use multiple ASAs, each using multiple GRASP objectives. may use multiple ASAs, each using multiple GRASP objectives.
Additional mechanisms for the fine-grained authorization of nodes and Additional mechanisms for the fine-grained authorization of nodes and
ASAs to manipulate specific GRASP objectives could be designed. ASAs to manipulate specific GRASP objectives could be designed.
Meanwhile, we repeat that ASAs should run without special privilege Meanwhile, we repeat that ASAs should run without special privilege
if possible. Independently of this, interfaces between ASAs and the if possible. Independently of this, interfaces between ASAs and the
router configuration and monitoring services of the node can be router configuration and monitoring services of the node can be
subject to authentication that provides more fine-grained subject to authentication that provides more fine-grained
authorization for specific services. These additional authentication authorization for specific services. These additional authentication
parameters could be passed to an ASA during its instantiation phase. parameters could be passed to an ASA during its instantiation phase.
10. IANA Considerations 11. IANA Considerations
This document makes no request of the IANA.
11. Acknowledgements
Valuable comments were received from Michael Behringer, Menachem This document has no IANA actions.
Dodge, Martin Dürst, Toerless Eckert, Thomas Fossati, Alex Galis,
Bing Liu, Benno Overeinder, Michael Richardson, Rob Wilton and other
IESG members.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
skipping to change at page 20, line 31 skipping to change at line 926
DOI 10.17487/RFC8994, May 2021, DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>. <https://www.rfc-editor.org/info/rfc8994>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>. May 2021, <https://www.rfc-editor.org/info/rfc8995>.
12.2. Informative References 12.2. Informative References
[DeMola06] De Mola, F. and R. Quitadamo, "Towards an Agent Model for [AUTONOMIC-FUNCTION]
Pierre, P. and L. Ciavaglia, "A Day in the Life of an
Autonomic Function", Work in Progress, Internet-Draft,
draft-peloso-anima-autonomic-function-01, 21 March 2016,
<https://datatracker.ietf.org/doc/html/draft-peloso-anima-
autonomic-function-01>.
[CBOR-YANG]
Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
C., and M. Richardson, "CBOR Encoding of Data Modeled with
YANG", Work in Progress, Internet-Draft, draft-ietf-core-
yang-cbor-18, December 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
yang-cbor-18>.
[DEMOLA06] De Mola, F. and R. Quitadamo, "Towards an Agent Model for
Future Autonomic Communications", Proceedings of the 7th Future Autonomic Communications", Proceedings of the 7th
WOA 2006 Workshop From Objects to Agents 51-59, September WOA 2006 Workshop From Objects to Agents 51-59, September
2006. 2006.
[GANA13] "Autonomic network engineering for the self-managing [GANA13] ETSI, "Autonomic network engineering for the self-managing
Future Internet (AFI): GANA Architectural Reference Model Future Internet (AFI); Generic Autonomic Network
for Autonomic Networking, Cognitive Networking and Self- Architecture (An Architectural Reference Model for
Management.", April 2013, Autonomic Networking, Cognitive Networking and Self-
<http://www.etsi.org/deliver/etsi_gs/ Management)", GS AFI 002, V1.1.1, April 2013,
<https://www.etsi.org/deliver/etsi_gs/
AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>. AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.
[Huebscher08] [HUEBSCHER08]
Huebscher, M. C. and J. A. McCann, "A survey of autonomic Huebscher, M. C. and J. A. McCann, "A survey of autonomic
computing - degrees, models, and applications", ACM computing - degrees, models, and applications", ACM
Computing Surveys (CSUR) Volume 40 Issue 3 DOI: Computing Surveys (CSUR), Volume 40, Issue 3,
10.1145/1380584.1380585, August 2008. DOI 10.1145/1380584.1380585, August 2008,
<https://doi.org/10.1145/1380584.1380585>.
[I-D.ietf-core-yang-cbor]
Veillette, M., Petrov, I., Pelov, A., Bormann, C., and M.
Richardson, "CBOR Encoding of Data Modeled with YANG",
Work in Progress, Internet-Draft, draft-ietf-core-yang-
cbor-18, 19 December 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
yang-cbor-18>.
[I-D.irtf-nmrg-ibn-concepts-definitions] [IBN-CONCEPTS]
Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
Tantsura, "Intent-Based Networking - Concepts and Tantsura, "Intent-Based Networking - Concepts and
Definitions", Work in Progress, Internet-Draft, draft- Definitions", Work in Progress, Internet-Draft, draft-
irtf-nmrg-ibn-concepts-definitions-06, 15 December 2021, irtf-nmrg-ibn-concepts-definitions-06, 15 December 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg- <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
ibn-concepts-definitions-06>. ibn-concepts-definitions-06>.
[I-D.peloso-anima-autonomic-function]
Pierre, P. and L. Ciavaglia, "A Day in the Life of an
Autonomic Function", Work in Progress, Internet-Draft,
draft-peloso-anima-autonomic-function-01, 21 March 2016,
<https://datatracker.ietf.org/doc/html/draft-peloso-anima-
autonomic-function-01>.
[IPJ] Behringer, M., Bormann, C., Carpenter, B. E., Eckert, T., [IPJ] Behringer, M., Bormann, C., Carpenter, B. E., Eckert, T.,
Campos Nobre, J., Jiang, S., Li, Y., and M. C. Richardson, Campos Nobre, J., Jiang, S., Li, Y., and M. C. Richardson,
"Autonomic Networking Gets Serious", The Internet Protocol "Autonomic Networking Gets Serious", The Internet Protocol
Journal Volume: 24 , Issue: 3, ISSN 1944-1134, Page(s): 2 Journal, Volume 24, Issue 3, Page(s) 2 - 18, ISSN
- 18, October 2021, <https://ipj.dreamhosters.com/wp- 1944-1134, October 2021, <https://ipj.dreamhosters.com/wp-
content/uploads/2021/10/243-ipj.pdf>. content/uploads/2021/10/243-ipj.pdf>.
[Movahedi12] [MOVAHEDI12]
Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A
Survey of Autonomic Network Architectures and Evaluation Survey of Autonomic Network Architectures and Evaluation
Criteria", IEEE Communications Surveys & Tutorials Volume: Criteria", IEEE Communications Surveys & Tutorials, Volume
14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 14, Issue 2, Pages 464 - 490,
Page(s): 464 - 490, 2012. DOI 10.1109/SURV.2011.042711.00078, 2012,
<https://doi.org/10.1109/SURV.2011.042711.00078>.
[NFV] "Network Functions Virtualisation - Introductory White [NFV] ETSI, "Network Functions Virtualisation", SDN and OpenFlow
Paper", SDN and OpenFlow World Congress, Darmstadt, World Congress, October 2012,
Germany 1-16, October 2012, <https://portal.etsi.org/NFV/NFV_White_Paper.pdf>.
<http://portal.etsi.org/NFV/NFV_White_Paper.pdf>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
skipping to change at page 22, line 37 skipping to change at line 1031
[RFC8992] Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun, [RFC8992] Jiang, S., Ed., Du, Z., Carpenter, B., and Q. Sun,
"Autonomic IPv6 Edge Prefix Management in Large-Scale "Autonomic IPv6 Edge Prefix Management in Large-Scale
Networks", RFC 8992, DOI 10.17487/RFC8992, May 2021, Networks", RFC 8992, DOI 10.17487/RFC8992, May 2021,
<https://www.rfc-editor.org/info/rfc8992>. <https://www.rfc-editor.org/info/rfc8992>.
[RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
L., and J. Nobre, "A Reference Model for Autonomic L., and J. Nobre, "A Reference Model for Autonomic
Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
<https://www.rfc-editor.org/info/rfc8993>. <https://www.rfc-editor.org/info/rfc8993>.
[ZSM009-1] "Zero-touch network and Service Management (ZSM); Closed- [ZSM009-1] ETSI, "Zero-touch network and Service Management (ZSM);
Loop Automation; Part 1: Enablers", June 2021, Closed-Loop Automation; Part 1: Enablers", GS ZSM 009-1,
Version 1.1.1, June 2021,
<https://www.etsi.org/deliver/etsi_gs/ <https://www.etsi.org/deliver/etsi_gs/
ZSM/001_099/00901/01.01.01_60/gs_ZSM00901v010101p.pdf>. ZSM/001_099/00901/01.01.01_60/gs_ZSM00901v010101p.pdf>.
Appendix A. Change log Appendix A. Example Logic Flows
This section is to be removed before publishing as an RFC.
draft-ietf-anima-asa-guidelines-07, 2022-02-01:
* Editorial
draft-ietf-anima-asa-guidelines-06, 2022-01-27:
* Clarified two sentences about special-purpose ASAs (Section 3.1,
Section 3.2).
* Fixed indentation bug and added one statement to MAIN PROGRAM
pseudocode.
* Removed mention of software image servers in section 6.1, which
confused the reader.
* Other improvements from IESG reviews.
draft-ietf-anima-asa-guidelines-05, 2021-12-20:
* Clarified NETCONF wording.
* Removed <CODE BEGINS> on advice from IETF Trust
* Noted resource limits in constrained nodes
* Strengthened text on data integrity in resource management example
* Strengthen discussion of extensibility of GRASP objectives.
* Other editorial improvements from IETF Last Call reviews
draft-ietf-anima-asa-guidelines-04, 2021-11-20:
* Added terminology appendix
* Further clarified discussion of asynch operations
* Other editorial improvements from AD review
draft-ietf-anima-asa-guidelines-03, 2021-11-07:
* Added security consideration for gateway ASAs
* Cite IPJ article
draft-ietf-anima-asa-guidelines-02, 2021-09-13:
* Added note on maximum message size.
* Editorial fixes
draft-ietf-anima-asa-guidelines-01, 2021-06-27:
* Incorporated shepherd's review comments
* Editorial fixes
draft-ietf-anima-asa-guidelines-00, 2020-11-14:
* Adopted by WG
* Editorial fixes
draft-carpenter-anima-asa-guidelines-09, 2020-07-25:
* Additional text on future authorization.
* Editorial fixes
draft-carpenter-anima-asa-guidelines-08, 2020-01-10:
* Introduced notion of autonomic ecosystem.
* Minor technical clarifications.
* Converted to v3 format.
draft-carpenter-anima-asa-guidelines-07, 2019-07-17:
* Improved explanation of threading vs event-loop
* Other editorial improvements.
draft-carpenter-anima-asa-guidelines-06, 2018-01-07:
* Expanded and improved example logic flow.
* Editorial corrections.
draft-carpenter-anima-asa-guidelines-05, 2018-06-30:
* Added section on relationshp with non-autonomic components.
* Editorial corrections.
draft-carpenter-anima-asa-guidelines-04, 2018-03-03:
* Added note about simple ASAs.
* Added note about NFV/SFC services.
* Improved text about threading v event loop model
* Added section about coordination with traditional tools.
* Added appendix with example logic flow.
draft-carpenter-anima-asa-guidelines-03, 2017-10-25:
* Added details on life cycle.
* Added details on robustness.
* Added co-authors.
draft-carpenter-anima-asa-guidelines-02, 2017-07-01:
* Expanded description of event-loop case.
* Added note about 'dry run' mode.
draft-carpenter-anima-asa-guidelines-01, 2017-01-06:
* More sections filled in.
draft-carpenter-anima-asa-guidelines-00, 2016-09-30:
* Initial version
Appendix B. Terminology
This appendix summarises various acronyms and terminology used in the
document. Where no other reference is given, please consult
[RFC8993] or [RFC7575].
* Autonomic: Self-managing (self-configuring, self-protecting, self-
healing, self-optimizing), but allowing high-level guidance by a
central entity such as a NOC.
* Autonomic Function: A function that adapts on its own to a
changing environment.
* Autonomic Node: A node that employs autonomic functions.
* ACP: Autonomic Control Plane [RFC8994].
* AN: Autonomic Network: A network of autonomic nodes, which
interact directly with each other.
* ANI: Autonomic Network Infrastructure.
* ASA: Autonomic Service Agent. An agent installed on an autonomic
node that implements an autonomic function, either partially (in
the case of a distributed function) or completely.
* BRSKI: Bootstrapping Remote Secure Key Infrastructure [RFC8995].
* CBOR: Concise Binary Object Representation [RFC8949].
* GRASP: Generic Autonomic Signaling Protocol [RFC8990].
* GRASP API: GRASP Application Programming Interface [RFC8991].
* NOC: Network Operations Center [RFC8368].
* Objective: A GRASP technical objective is a data structure whose
main contents are a name and a value. The value consists of a
single configurable parameter or a set of parameters of some kind.
[RFC8990].
Appendix C. Example Logic Flows
This appendix describes generic logic flows that combine to act as an This appendix describes generic logic flows that combine to act as an
Autonomic Service Agent (ASA) for resource management. Note that Autonomic Service Agent (ASA) for resource management. Note that
these are illustrative examples, and in no sense requirements. As these are illustrative examples and are in no sense requirements. As
long as the rules of GRASP are followed, a real implementation could long as the rules of GRASP are followed, a real implementation could
be different. The reader is assumed to be familiar with GRASP be different. The reader is assumed to be familiar with GRASP
[RFC8990] and its conceptual API [RFC8991]. [RFC8990] and its conceptual API [RFC8991].
A complete autonomic function for a distributed resource will consist A complete autonomic function for a distributed resource will consist
of a number of instances of the ASA placed at relevant points in a of a number of instances of the ASA placed at relevant points in a
network. Specific details will of course depend on the resource network. Specific details will, of course, depend on the resource
concerned. One example is IP address prefix management, as specified concerned. One example is IP address prefix management, as specified
in [RFC8992]. In this case, an instance of the ASA will exist in in [RFC8992]. In this case, an instance of the ASA will exist in
each delegating router. each delegating router.
An underlying assumption is that there is an initial source of the An underlying assumption is that there is an initial source of the
resource in question, referred to here as an origin ASA. The other resource in question, referred to here as an origin ASA. The other
ASAs, known as delegators, obtain supplies of the resource from the ASAs, known as delegators, obtain supplies of the resource from the
origin, and then delegate quantities of the resource to consumers origin, delegate quantities of the resource to consumers that request
that request it, and recover it when no longer needed. it, and recover it when no longer needed.
Another assumption is there is a set of network wide policy Another assumption is there is a set of network-wide policy
parameters, which the origin will provide to the delegators. These parameters, which the origin will provide to the delegators. These
parameters will control how the delegators decide how much resource parameters will control how the delegators decide how much resource
to provide to consumers. Thus, the ASA logic has two operating to provide to consumers. Thus, the ASA logic has two operating
modes: origin and delegator. When running as an origin, it starts by modes: origin and delegator. When running as an origin, it starts by
obtaining a quantity of the resource from the NOC, and it acts as a obtaining a quantity of the resource from the NOC, and it acts as a
source of policy parameters, via both GRASP flooding and GRASP source of policy parameters, via both GRASP flooding and GRASP
synchronization. (In some scenarios, flooding or synchronization synchronization. (In some scenarios, flooding or synchronization
alone might be sufficient, but this example includes both.) alone might be sufficient, but this example includes both.)
When running as a delegator, it starts with an empty resource pool, When running as a delegator, it starts with an empty resource pool,
it acquires the policy parameters by GRASP synchronization, and it acquires the policy parameters by GRASP synchronization, and
delegates quantities of the resource to consumers that request it. delegates quantities of the resource to consumers that request it.
Both as an origin and as a delegator, when its pool is low it seeks Both as an origin and as a delegator, when its pool is low, it seeks
quantities of the resource by requesting GRASP negotiation with peer quantities of the resource by requesting GRASP negotiation with peer
ASAs. When its pool is sufficient, it hands out resource to peer ASAs. When its pool is sufficient, it hands out resource to peer
ASAs in response to negotiation requests. Thus, over time, the ASAs in response to negotiation requests. Thus, over time, the
initial resource pool held by the origin will be shared among all the initial resource pool held by the origin will be shared among all the
delegators according to demand. delegators according to demand.
In theory a network could include any number of origins and any In theory, a network could include any number of origins and any
number of delegators, with the only condition being that each number of delegators, with the only condition being that each
origin's initial resource pool is unique. A realistic scenario is to origin's initial resource pool is unique. A realistic scenario is to
have exactly one origin and as many delegators as you like. A have exactly one origin and as many delegators as you like. A
scenario with no origin is useless. scenario with no origin is useless.
An implementation requirement is that resource pools are kept in An implementation requirement is that resource pools are kept in
stable storage. Otherwise, if a delegator exits for any reason, all stable storage. Otherwise, if a delegator exits for any reason, all
the resources it has obtained or delegated are lost. If an origin the resources it has obtained or delegated are lost. If an origin
exits, its entire spare pool is lost. The logic for using stable exits, its entire spare pool is lost. The logic for using stable
storage and for crash recovery is not included in the pseudocode storage and for crash recovery is not included in the pseudocode
below, which focuses on communication between ASAs. Since GRASP below, which focuses on communication between ASAs. Since GRASP
operations are not intrinsically idempotent, data integrity during operations are not intrinsically idempotent, data integrity during
failure scenarios is the responsibility of the ASA designer. This is failure scenarios is the responsibility of the ASA designer. This is
a complex topic in its own right that is not discussed in the present a complex topic in its own right that is not discussed in the present
document. document.
The description below does not implement GRASP's 'dry run' function. The description below does not implement GRASP's dry run function.
That would require temporarily marking any resource handed out in a That would require temporarily marking any resource handed out in a
dry run negotiation as reserved, until either the peer obtains it in dry run negotiation as reserved, until either the peer obtains it in
a live run, or a suitable timeout occurs. a live run, or a suitable timeout occurs.
The main data structures used in each instance of the ASA are: The main data structures used in each instance of the ASA are:
* The resource_pool, for example an ordered list of available * resource_pool: an ordered list of available resources, for
resources. Depending on the nature of the resource, units of example. Depending on the nature of the resource, units of
resource are split when appropriate, and a background garbage resource are split when appropriate, and a background garbage
collector recombines split resources if they are returned to the collector recombines split resources if they are returned to the
pool. pool.
* The delegated_list, where a delegator stores the resources it has * delegated_list: where a delegator stores the resources it has
given to subsidiary devices. given to subsidiary devices.
Possible main logic flows are below, using a threaded implementation Possible main logic flows are below, using a threaded implementation
model. As noted above, alternative approaches to asynchronous model. As noted above, alternative approaches to asynchronous
operations are possible. The transformation to an event loop model operations are possible. The transformation to an event loop model
should be apparent - each thread would correspond to one event in the should be apparent; each thread would correspond to one event in the
event loop. event loop.
The GRASP objectives are as follows: The GRASP objectives are as follows:
* ["EX1.Resource", flags, loop_count, value] where the value depends * ["EX1.Resource", flags, loop_count, value], where the value
on the resource concerned, but will typically include its size and depends on the resource concerned but will typically include its
identification. size and identification.
* ["EX1.Params", flags, loop_count, value] where the value will be, * ["EX1.Params", flags, loop_count, value], where the value will be,
for example, a JSON object defining the applicable parameters. for example, a JSON object defining the applicable parameters.
In the outline logic flows below, these objectives are represented In the outline logic flows below, these objectives are represented
simply by their names. simply by their names.
MAIN PROGRAM: MAIN PROGRAM:
Create empty resource_pool (and an associated lock) Create empty resource_pool (and an associated lock)
Create empty delegated_list Create empty delegated_list
Determine whether to act as origin Determine whether to act as origin
skipping to change at page 30, line 12 skipping to change at line 1230
Send M_FLOOD message for EX1.Params Send M_FLOOD message for EX1.Params
sleep() #periodic timer suitable for application scenario sleep() #periodic timer suitable for application scenario
GARBAGE_COLLECTOR thread: GARBAGE_COLLECTOR thread:
do forever: do forever:
Search resource_pool for adjacent resources Search resource_pool for adjacent resources
Merge adjacent resources Merge adjacent resources
sleep() #periodic timer suitable for application scenario sleep() #periodic timer suitable for application scenario
Acknowledgements
Valuable comments were received from Michael Behringer, Menachem
Dodge, Martin Dürst, Toerless Eckert, Thomas Fossati, Alex Galis,
Bing Liu, Benno Overeinder, Michael Richardson, Rob Wilton, and other
IESG members.
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
School of Computer Science School of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
Laurent Ciavaglia Laurent Ciavaglia
Rakuten Mobile Rakuten Mobile
Paris Paris
France France
Email: laurent.ciavaglia@rakuten.com Email: laurent.ciavaglia@rakuten.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14 Huawei Campus Q14 Huawei Campus
156 Beiqing Road 156 Beiqing Road
Hai-Dian District Hai-Dian District
Beijing Beijing
100095 100095
China China
 End of changes. 159 change blocks. 
460 lines changed or deleted 360 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/