< draft-carpenter-anima-asa-guidelines-06.txt   draft-carpenter-anima-asa-guidelines-07.txt >
Network Working Group B. Carpenter Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational L. Ciavaglia Intended status: Informational L. Ciavaglia
Expires: July 11, 2019 Nokia Expires: January 8, 2020 Nokia
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
P. Peloso P. Peloso
Nokia Nokia
January 7, 2019 July 7, 2019
Guidelines for Autonomic Service Agents Guidelines for Autonomic Service Agents
draft-carpenter-anima-asa-guidelines-06 draft-carpenter-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. It is based on the Autonomic Network Agents for autonomic networks. It is based on the Autonomic Network
Infrastructure outlined in the ANIMA reference model, making use of Infrastructure outlined in the ANIMA reference model, making use of
the Autonomic Control Plane and the Generic Autonomic Signaling the Autonomic Control Plane and the Generic Autonomic Signaling
Protocol. Protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 11, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Logical Structure of an Autonomic Service Agent . . . . . . . 3 2. Logical Structure of an Autonomic Service Agent . . . . . . . 3
3. Interaction with the Autonomic Networking Infrastructure . . 5 3. Interaction with the Autonomic Networking Infrastructure . . 5
3.1. Interaction with the security mechanisms . . . . . . . . 5 3.1. Interaction with the security mechanisms . . . . . . . . 5
3.2. Interaction with the Autonomic Control Plane . . . . . . 5 3.2. Interaction with the Autonomic Control Plane . . . . . . 5
3.3. Interaction with GRASP and its API . . . . . . . . . . . 6 3.3. Interaction with GRASP and its API . . . . . . . . . . . 5
3.4. Interaction with policy mechanism . . . . . . . . . . . . 7 3.4. Interaction with policy mechanism . . . . . . . . . . . . 6
4. Interaction with Non-Autonomic Components . . . . . . . . . . 7 4. Interaction with Non-Autonomic Components . . . . . . . . . . 7
5. Design of GRASP Objectives . . . . . . . . . . . . . . . . . 7 5. Design of GRASP Objectives . . . . . . . . . . . . . . . . . 7
6. Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Installation phase . . . . . . . . . . . . . . . . . . . 9 6.1. Installation phase . . . . . . . . . . . . . . . . . . . 9
6.1.1. Installation phase inputs and outputs . . . . . . . . 10 6.1.1. Installation phase inputs and outputs . . . . . . . . 10
6.2. Instantiation phase . . . . . . . . . . . . . . . . . . . 10 6.2. Instantiation phase . . . . . . . . . . . . . . . . . . . 10
6.2.1. Operator's goal . . . . . . . . . . . . . . . . . . . 11 6.2.1. Operator's goal . . . . . . . . . . . . . . . . . . . 11
6.2.2. Instantiation phase inputs and outputs . . . . . . . 11 6.2.2. Instantiation phase inputs and outputs . . . . . . . 11
6.2.3. Instantiation phase requirements . . . . . . . . . . 12 6.2.3. Instantiation phase requirements . . . . . . . . . . 12
6.3. Operation phase . . . . . . . . . . . . . . . . . . . . . 12 6.3. Operation phase . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 2, line 40 skipping to change at page 2, line 40
8. Coordination with Traditional Management Functions . . . . . 13 8. Coordination with Traditional Management Functions . . . . . 13
9. Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 18 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 18
Appendix B. Example Logic Flows . . . . . . . . . . . . . . . . 19 Appendix B. Example Logic Flows . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 ANIMA the Autonomic Network Infrastructure (ANI) outlined in the ANIMA
reference model [I-D.ietf-anima-reference-model]. This reference model [I-D.ietf-anima-reference-model]. This
infrastructure makes use of the Autonomic Control Plane (ACP) infrastructure makes use of the Autonomic Control Plane (ACP)
[I-D.ietf-anima-autonomic-control-plane] and the Generic Autonomic [I-D.ietf-anima-autonomic-control-plane] and the Generic Autonomic
Signaling Protocol (GRASP) [I-D.ietf-anima-grasp]. Signaling Protocol (GRASP) [I-D.ietf-anima-grasp].
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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 component.
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. For example, the services envisaged for themselves provide services. For example, the services envisaged for
network function virtualisation network function virtualisation [RFC8568] or for service function
[I-D.irtf-nfvrg-gaps-network-virtualization] or for service function
chaining [RFC7665] might be managed by an ASA rather than by chaining [RFC7665] might be managed by an ASA rather than by
traditional configuration tools. traditional configuration tools.
The reference model [I-D.ietf-anima-reference-model] expands this by The reference model [I-D.ietf-anima-reference-model] expands this by
adding that an ASA is "a process that makes use of the features adding that an ASA is "a process that makes use of the features
provided by the ANI to achieve its own goals, usually including provided by the ANI to achieve its own goals, usually including
interaction with other ASAs via the GRASP protocol interaction with other ASAs via the GRASP protocol
[I-D.ietf-anima-grasp] or otherwise. Of course it also interacts [I-D.ietf-anima-grasp] or otherwise. Of course it also interacts
with the specific targets of its function, using any suitable with the specific targets of its function, using any suitable
mechanism. Unless its function is very simple, the ASA will need to mechanism. Unless its function is very simple, the ASA will need to
handle overlapping asynchronous operations. It may therefore be a handle overlapping asynchronous operations. This will require either
quite complex piece of software in its own right, forming part of the a multi-threaded implementation, or a logically equivalent event loop
application layer above the ANI." structure. It may therefore be a quite complex piece of software in
its own right, forming part of the application layer above the ANI."
There will certainly be very simple ASAs that manage a single There will certainly be very simple ASAs that manage a single
objective in a straightforward way and do not asynchronous objective in a straightforward way and do not asynchronous
operations. In such a case, many aspects of the current document do operations. In such a case, many aspects of the current document do
not apply. However, in general a basic property of an ASA is that it not apply. However, in general a basic property of an ASA is that it
is a relatively complex software component that will in many cases is a relatively complex software component that will in many cases
control and monitor simpler entities in the same host or elsewhere. control and monitor simpler entities in the same host or elsewhere.
For example, a device controller that manages tens or hundreds of For example, a device controller that manages tens or hundreds of
simple devices might contain a single ASA. simple devices might contain a single ASA.
The remainder of this document offers guidance on the design of such The remainder of this document offers guidance on the design of such
ASAs. ASAs.
2. Logical Structure of an Autonomic Service Agent 2. Logical Structure of an Autonomic Service Agent
As mentioned above, all but the simplest ASAs will be multi-threaded As mentioned above, all but the simplest ASAs will need to suport
programs. asynchronous operations. Not all programming environments explicitly
support multi-threading. In that case, an 'event loop' style of
implementation should be adopted, in which case each thread would be
implemented as an event handler called in turn by the main loop. For
this, the GRASP API (Section 3.3) must provide non-blocking calls.
If necessary, the GRASP session identifier will be used to
distinguish simultaneous operations.
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:
o Obtain authorization credentials. o Obtain authorization credentials.
o Register the ASA with GRASP. o Register the ASA with GRASP.
o Acquire relevant policy parameters. o Acquire relevant policy parameters.
o Define data structures for relevant GRASP objectives. o Define data structures for relevant GRASP objectives.
o Register with GRASP those objectives that it will actively manage. o Register with GRASP those objectives that it will actively manage.
o Launch a self-monitoring thread. o Launch a self-monitoring thread.
o Enter its main loop. o 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 will be launched. Examples of such threads required, extra threads will be launched, or events added to the
include: event loop. Examples include:
o A background thread to repeatedly flood an objective to the AN, so o Repeatedly flood an objective to the AN, so that any ASA can
that any ASA can receive the objective's latest value. receive the objective's latest value.
o A thread to accept incoming synchronization requests for an o Accept incoming synchronization requests for an objective managed
objective managed by this ASA. by this ASA.
o A thread to accept incoming negotiation requests for an objective o Accept incoming negotiation requests for an objective managed by
managed by this ASA, and then to conduct the resulting negotiation this ASA, and then conduct the resulting negotiation with the
with the counterpart ASA. counterpart ASA.
o A thread to manage subsidiary non-autonomic devices directly. o Manage subsidiary non-autonomic devices directly.
These threads should all either exit after their job is done, or These threads or events should all either exit after their job is
enter a wait state for new work, to avoid blocking other threads done, or enter a wait state for new work, to avoid blocking others
unnecessarily. unnecessarily.
Not all programming environments explicitly support multi-threading.
In such cases, an 'event loop' style of implementation could be
adopted, in which case each of the above threads would be implemented
as an event handler called in turn by the main loop. In this case,
the GRASP API (Section 3.3) must provide non-blocking calls. If
necessary, the GRASP session identifier will be used to distinguish
simultaneous operations.
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 or events might be launched in multiple
particular, if negotiation sessions with other ASAs are expected to instances. In particular, if negotiation sessions with other ASAs
be long or to involve wait states, the ASA designer might allow for are expected to be long or to involve wait states, the ASA designer
multiple simultaneous negotiating threads, with appropriate use of might allow for multiple simultaneous negotiating threads, with
queues and locks to maintain consistency. appropriate use of queues and locks 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 from other ASAs. In particular, the main loop should watch resources from other ASAs. In particular, the main loop should watch
for changes in policy parameters that affect its operation. It for changes in policy parameters that affect its operation. It
should also do whatever is required to avoid unnecessary resource should also do whatever is required to avoid unnecessary resource
consumption, such as including an arbitrary wait time in each cycle consumption, such as including an arbitrary wait time in each cycle
of the main loop. of the main loop.
The self-monitoring thread is of considerable importance. Autonomic The self-monitoring thread is of considerable importance. Autonomic
skipping to change at page 14, line 4 skipping to change at page 14, line 4
necessary. This issue is considered in "Autonomic Functions necessary. This issue is considered in "Autonomic Functions
Coordination" [I-D.ciavaglia-anima-coordination]. Coordination" [I-D.ciavaglia-anima-coordination].
8. Coordination with Traditional Management Functions 8. 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 command
line interfaces, DHCP, DHCPv6, SNMP, NETCONF, RESTCONF and YANG-based line interfaces, DHCP, DHCPv6, SNMP, NETCONF, RESTCONF and YANG-based
solutions. Each ASA designer will need to consider this issue and solutions. Each ASA designer will need to consider this issue and
how to avoid clashes and inconsistencies. Some specific how to avoid clashes and inconsistencies. Some specific
considerations for interaction with OAM tools are given in considerations for interaction with OAM tools are given in [RFC8368].
[I-D.ietf-anima-stable-connectivity]. As another example, As another example, [I-D.ietf-anima-prefix-management] describes how
[I-D.ietf-anima-prefix-management] describes how autonomic management autonomic management of IPv6 prefixes can interact with prefix
of IPv6 prefixes can interact with prefix delegation via DHCPv6. The delegation via DHCPv6. The description of a GRASP objective and of
description of a GRASP objective and of an ASA using it should an ASA using it should include a discussion of any such interactions.
include a discussion of any such interactions.
A related aspect is that management functions often include a data A related aspect is that management functions often include a data
model, quite likely to be expressed in a formal notation such as model, quite likely to be expressed in a formal notation such as
YANG. This aspect should not be an afterthought in the design of an YANG. This aspect should not be an afterthought in the design of an
ASA. To the contrary, the design of the ASA and of its GRASP ASA. To the contrary, the design of the ASA and of its GRASP
objectives should match the data model; as noted above, YANG objectives should match the data model; as noted above, YANG
serialized as CBOR may be used directly as the value of a GRASP serialized as CBOR may be used directly as the value of a GRASP
objective. objective.
9. Robustness 9. Robustness
skipping to change at page 15, line 23 skipping to change at page 15, line 23
8. All other possible exceptions should be handled in an orderly 8. 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).
10. 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 [I-D.ietf-anima-autonomic-control-plane], Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane],
admission to which depends on an initial secure bootstrap process admission to which depends on an initial secure bootstrap process
[I-D.ietf-anima-bootstrapping-keyinfra]. However, this does not [I-D.ietf-anima-bootstrapping-keyinfra]. In some deployments, a
secure partition of the link layer might be used instead
[I-D.carpenter-anima-l2acp-scenarios]. However, this does not
relieve ASAs of responsibility for security. In particular, when relieve ASAs of responsibility for security. In particular, when
ASAs configure or manage network elements outside the ACP, they must ASAs configure or manage network elements outside the ACP, they must
use secure techniques and carefully validate any incoming use secure techniques and carefully validate any incoming
information. As appropriate to their specific functions, ASAs should information. As appropriate to their specific functions, ASAs should
take account of relevant privacy considerations [RFC6973]. take account of relevant privacy considerations [RFC6973].
Authorization of ASAs is a subject for future study. At present, Authorization of ASAs is a subject for future study. At present,
ASAs are trusted by virtue of being installed on a node that has ASAs are trusted by virtue of being installed on a node that has
successfully joined the ACP. successfully joined the ACP.
skipping to change at page 15, line 50 skipping to change at page 16, line 8
Useful comments were received from Toerless Eckert, Alex Galis, Bing Useful comments were received from Toerless Eckert, Alex Galis, Bing
Liu, and other members of the ANIMA WG. Liu, and other members of the ANIMA WG.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-18 (work in progress), August 2018. plane-19 (work in progress), March 2019.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-17 (work in progress), November 2018. keyinfra-22 (work in progress), June 2019.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
13.2. Informative References 13.2. Informative References
[DeMola06] [DeMola06]
De Mola, F. and R. Quitadamo, "An Agent Model for Future De Mola, F. and R. Quitadamo, "An Agent Model for Future
Autonomic Communications", Proceedings of the 7th WOA 2006 Autonomic Communications", Proceedings of the 7th WOA 2006
Workshop From Objects to Agents 51-59, September 2006. Workshop From Objects to Agents 51-59, September 2006.
[GANA13] ETSI GS AFI 002, "Autonomic network engineering for the [GANA13] "Autonomic network engineering for the self-managing
self-managing Future Internet (AFI): GANA Architectural Future Internet (AFI): GANA Architectural Reference Model
Reference Model for Autonomic Networking, Cognitive for Autonomic Networking, Cognitive Networking and Self-
Networking and Self-Management.", April 2013, Management.", April 2013,
<http://www.etsi.org/deliver/etsi_gs/ <http://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. and J. McCann, "A survey of autonomic Huebscher, M. and J. 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 DOI:
10.1145/1380584.1380585, August 2008. 10.1145/1380584.1380585, August 2008.
[I-D.carpenter-anima-l2acp-scenarios]
Carpenter, B. and B. Liu, "Scenarios and Requirements for
Layer 2 Autonomic Control Planes", draft-carpenter-anima-
l2acp-scenarios-00 (work in progress), February 2019.
[I-D.ciavaglia-anima-coordination] [I-D.ciavaglia-anima-coordination]
Ciavaglia, L. and P. Peloso, "Autonomic Functions Ciavaglia, L. and P. Peloso, "Autonomic Functions
Coordination", draft-ciavaglia-anima-coordination-01 (work Coordination", draft-ciavaglia-anima-coordination-01 (work
in progress), March 2016. in progress), March 2016.
[I-D.ietf-anima-grasp-api] [I-D.ietf-anima-grasp-api]
Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic
Autonomic Signaling Protocol Application Program Interface Autonomic Signaling Protocol Application Program Interface
(GRASP API)", draft-ietf-anima-grasp-api-02 (work in (GRASP API)", draft-ietf-anima-grasp-api-03 (work in
progress), June 2018. progress), January 2019.
[I-D.ietf-anima-prefix-management] [I-D.ietf-anima-prefix-management]
Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
IPv6 Edge Prefix Management in Large-scale Networks", IPv6 Edge Prefix Management in Large-scale Networks",
draft-ietf-anima-prefix-management-07 (work in progress), draft-ietf-anima-prefix-management-07 (work in progress),
December 2017. December 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
Networking", draft-ietf-anima-reference-model-10 (work in Networking", draft-ietf-anima-reference-model-10 (work in
progress), November 2018. progress), November 2018.
[I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-10 (work in progress), February
2018.
[I-D.ietf-core-yang-cbor] [I-D.ietf-core-yang-cbor]
Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of
Minaburo, "CBOR Encoding of Data Modeled with YANG", Data Modeled with YANG", draft-ietf-core-yang-cbor-10
draft-ietf-core-yang-cbor-07 (work in progress), September (work in progress), April 2019.
2018.
[I-D.irtf-nfvrg-gaps-network-virtualization]
Bernardos, C., Rahman, A., Zuniga, J., Contreras, L.,
Aranda, P., and P. Lynch, "Network Virtualization Research
Challenges", draft-irtf-nfvrg-gaps-network-
virtualization-10 (work in progress), September 2018.
[I-D.peloso-anima-autonomic-function] [I-D.peloso-anima-autonomic-function]
Pierre, P. and L. Ciavaglia, "A Day in the Life of an Pierre, P. and L. Ciavaglia, "A Day in the Life of an
Autonomic Function", draft-peloso-anima-autonomic- Autonomic Function", draft-peloso-anima-autonomic-
function-01 (work in progress), March 2016. function-01 (work in progress), March 2016.
[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:
skipping to change at page 18, line 16 skipping to change at page 18, line 16
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>.
[RFC8568] Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM.,
Aranda, P., and P. Lynch, "Network Virtualization Research
Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019,
<https://www.rfc-editor.org/info/rfc8568>.
Appendix A. Change log [RFC Editor: Please remove] Appendix A. Change log [RFC Editor: Please remove]
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: draft-carpenter-anima-asa-guidelines-06, 2018-01-07:
Expanded and improved example logic flow. Expanded and improved example logic flow.
Editorial corrections. Editorial corrections.
draft-carpenter-anima-asa-guidelines-05, 2018-06-30: draft-carpenter-anima-asa-guidelines-05, 2018-06-30:
Added section on relationshp with non-autonomic components. Added section on relationshp with non-autonomic components.
skipping to change at page 20, line 21 skipping to change at page 20, line 39
master's initial resource pool is unique. A realistic scenario is to master's initial resource pool is unique. A realistic scenario is to
have exactly one master and as many delegators as you like. A have exactly one master and as many delegators as you like. A
scenario with no master is useless. scenario with no master 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 a master the resources it has obtained or delegated are lost. If a master
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 receovery is not included below. storage and for crash receovery is not included below.
The description below doesn't implement GRASP's 'dry run' function. The description below does not implement GRASP's 'dry run' function.
That would mean temporarily marking any resource handed out in a dry That would require temporarily marking any resource handed out in a
run negotiation as reserved, until either the peer obtains it in a dry run negotiation as reserved, until either the peer obtains it in
live run, or a suitable timeout expires. a live run, or a suitable timeout expires.
The main data structures used in each instance of the ASA are: The main data structures used in each instance of the ASA are:
o The resource_pool, for example an ordered list of available o The resource_pool, for example an ordered list of available
resources. Depending on the nature of the resource, units of resources. 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.
o The delegated_list, where a delegator stores the resources it has o The delegated_list, where a delegator stores the resources it has
skipping to change at page 23, line 15 skipping to change at page 24, line 15
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() #sleep time depends on application scenario sleep() #sleep time depends on application scenario
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
Department 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
Nokia Nokia
Villarceaux Villarceaux
 End of changes. 30 change blocks. 
75 lines changed or deleted 84 lines changed or added

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