idnits 2.17.1 draft-carpenter-anima-asa-guidelines-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 381 has weird spacing: '...roperty allow...' == Line 384 has weird spacing: '...roperty allow...' == Line 388 has weird spacing: '...roperty allow...' -- The document date (March 3, 2018) is 2239 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-13 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-11 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-06 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-06 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational L. Ciavaglia 5 Expires: September 4, 2018 Nokia 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 P. Peloso 9 Nokia 10 March 3, 2018 12 Guidelines for Autonomic Service Agents 13 draft-carpenter-anima-asa-guidelines-04 15 Abstract 17 This document proposes guidelines for the design of Autonomic Service 18 Agents for autonomic networks. It is based on the Autonomic Network 19 Infrastructure outlined in the ANIMA reference model, making use of 20 the Autonomic Control Plane and the Generic Autonomic Signaling 21 Protocol. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 4, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Logical Structure of an Autonomic Service Agent . . . . . . . 3 59 3. Interaction with the Autonomic Networking Infrastructure . . 5 60 3.1. Interaction with the security mechanisms . . . . . . . . 5 61 3.2. Interaction with the Autonomic Control Plane . . . . . . 5 62 3.3. Interaction with GRASP and its API . . . . . . . . . . . 5 63 3.4. Interaction with Intent mechanism . . . . . . . . . . . . 6 64 4. Design of GRASP Objectives . . . . . . . . . . . . . . . . . 7 65 5. Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Installation phase . . . . . . . . . . . . . . . . . . . 8 67 5.1.1. Installation phase inputs and outputs . . . . . . . . 9 68 5.2. Instantiation phase . . . . . . . . . . . . . . . . . . . 9 69 5.2.1. Operator's goal . . . . . . . . . . . . . . . . . . . 10 70 5.2.2. Instantiation phase inputs and outputs . . . . . . . 10 71 5.2.3. Instantiation phase requirements . . . . . . . . . . 11 72 5.3. Operation phase . . . . . . . . . . . . . . . . . . . . . 12 73 6. Coordination between Autonomic Functions . . . . . . . . . . 13 74 7. Coordination with Traditional Management Functions . . . . . 13 75 8. Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 12.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 17 83 Appendix B. Example Logic Flows . . . . . . . . . . . . . . . . 18 84 B.1. Threaded Example . . . . . . . . . . . . . . . . . . . . 18 85 B.2. Event Loop Example . . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 This document proposes guidelines for the design of Autonomic Service 91 Agents (ASAs) in the context of an Autonomic Network (AN) based on 92 the Autonomic Network Infrastructure (ANI) outlined in the ANIMA 93 reference model [I-D.ietf-anima-reference-model]. This 94 infrastructure makes use of the Autonomic Control Plane (ACP) 95 [I-D.ietf-anima-autonomic-control-plane] and the Generic Autonomic 96 Signaling Protocol (GRASP) [I-D.ietf-anima-grasp]. 98 There is a considerable literature about autonomic agents with a 99 variety of proposals about how they should be characterized. Some 100 examples are [DeMola06], [Huebscher08], [Movahedi12] and [GANA13]. 101 However, for the present document, the basic definitions and goals 102 for autonomic networking given in [RFC7575] apply . According to RFC 103 7575, an Autonomic Service Agent is "An agent implemented on an 104 autonomic node that implements an autonomic function, either in part 105 (in the case of a distributed function) or whole." 107 ASAs must be distinguished from other forms of software component. 108 They are components of network or service management; they do not in 109 themselves provide services. For example, the services envisaged for 110 network function virtualisation [reference needed] or for service 111 function chaining [RFC7665] might be managed by an ASA rather than by 112 traditional configuration tools. 114 The reference model [I-D.ietf-anima-reference-model] expands this by 115 adding that an ASA is "a process that makes use of the features 116 provided by the ANI to achieve its own goals, usually including 117 interaction with other ASAs via the GRASP protocol 118 [I-D.ietf-anima-grasp] or otherwise. Of course it also interacts 119 with the specific targets of its function, using any suitable 120 mechanism. Unless its function is very simple, the ASA will need to 121 handle overlapping asynchronous operations. It may therefore be a 122 quite complex piece of software in its own right, forming part of the 123 application layer above the ANI." 125 There will certainly be very simple ASAs that manage a single 126 objective in a straightforward way and do not asynchronous 127 operations. In such a case, many aspects of the current document do 128 not apply. However, in general a basic property of an ASA is that it 129 is a relatively complex software component that will in many cases 130 control and monitor simpler entities in the same host or elsewhere. 131 For example, a device controller that manages tens or hundreds of 132 simple devices might contain a single ASA. 134 The remainder of this document offers guidance on the design of such 135 ASAs. 137 2. Logical Structure of an Autonomic Service Agent 139 As mentioned above, all but the simplest ASAs will be multi-threaded 140 programs. 142 A typical ASA will have a main thread that performs various initial 143 housekeeping actions such as: 145 o Obtain authorization credentials. 147 o Register the ASA with GRASP. 149 o Acquire relevant policy Intent. 151 o Define data structures for relevant GRASP objectives. 153 o Register with GRASP those objectives that it will actively manage. 155 o Launch a self-monitoring thread. 157 o Enter its main loop. 159 The logic of the main loop will depend on the details of the 160 autonomic function concerned. Whenever asynchronous operations are 161 required, extra threads will be launched. Examples of such threads 162 include: 164 o A background thread to repeatedly flood an objective to the AN, so 165 that any ASA can receive the objective's latest value. 167 o A thread to accept incoming synchronization requests for an 168 objective managed by this ASA. 170 o A thread to accept incoming negotiation requests for an objective 171 managed by this ASA, and then to conduct the resulting negotiation 172 with the counterpart ASA. 174 o A thread to manage subsidiary non-autonomic devices directly. 176 These threads should all either exit after their job is done, or 177 enter a wait state for new work, to avoid blocking other threads 178 unnecessarily. 180 Not all programming environments explicitly support multi-threading. 181 In such cases, an 'event loop' style of implementation could be 182 adopted, in which case each of the above threads would be implemented 183 as an event handler called in turn by the main loop. In this case, 184 the GRASP API (Section 3.3) must provide non-blocking calls. If 185 necessary, the GRASP session identifier will be used to distinguish 186 simultaneous operations. 188 According to the degree of parallelism needed by the application, 189 some of these threads might be launched in multiple instances. In 190 particular, if negotiation sessions with other ASAs are expected to 191 be long or to involve wait states, the ASA designer might allow for 192 multiple simultaneous negotiating threads, with appropriate use of 193 queues and locks to maintain consistency. 195 The main loop itself could act as the initiator of synchronization 196 requests or negotiation requests, when the ASA needs data or 197 resources from other ASAs. In particular, the main loop should watch 198 for changes in policy Intent that affect its operation. It should 199 also do whatever is required to avoid unnecessary resource 200 consumption, such as including an arbitrary wait time in each cycle 201 of the main loop. 203 The self-monitoring thread is of considerable importance. Autonomic 204 service agents must never fail. To a large extent this depends on 205 careful coding and testing, with no unhandled error returns or 206 exceptions, but if there is nevertheless some sort of failure, the 207 self-monitoring thread should detect it, fix it if possible, and in 208 the worst case restart the entire ASA. 210 Appendix B presents some example logic flows in informal pseudocode. 212 3. Interaction with the Autonomic Networking Infrastructure 214 3.1. Interaction with the security mechanisms 216 An ASA by definition runs in an autonomic node. Before any normal 217 ASAs are started, such nodes must be bootstrapped into the autonomic 218 network's secure key infrastructure in accordance with 219 [I-D.ietf-anima-bootstrapping-keyinfra]. This key infrastructure 220 will be used to secure the ACP (next section) and may be used by ASAs 221 to set up additional secure interactions with their peers, if needed. 223 Note that the secure bootstrap process itself may include special- 224 purpose ASAs that run in a constrained insecure mode. 226 3.2. Interaction with the Autonomic Control Plane 228 In a normal autonomic network, ASAs will run as clients of the ACP. 229 It will provide a fully secured network environment for all 230 communication with other ASAs, in most cases mediated by GRASP (next 231 section). 233 Note that the ACP formation process itself may include special- 234 purpose ASAs that run in a constrained insecure mode. 236 3.3. Interaction with GRASP and its API 238 GRASP [I-D.ietf-anima-grasp] is expected to run as a separate process 239 with its API [I-D.liu-anima-grasp-api] available in user space. Thus 240 ASAs may operate without special privilege, unless they need it for 241 other reasons. The ASA's view of GRASP is built around GRASP 242 objectives (Section 4), defined as data structures containing 243 administrative information such as the objective's unique name, and 244 its current value. The format and size of the value is not 245 restricted by the protocol, except that it must be possible to 246 serialise it for transmission in CBOR [RFC7049], which is no 247 restriction at all in practice. 249 The GRASP API should offer the following features: 251 o Registration functions, so that an ASA can register itself and the 252 objectives that it manages. 254 o A discovery function, by which an ASA can discover other ASAs 255 supporting a given objective. 257 o A negotiation request function, by which an ASA can start 258 negotiation of an objective with a counterpart ASA. With this, 259 there is a corresponding listening function for an ASA that wishes 260 to respond to negotiation requests, and a set of functions to 261 support negotiating steps. 263 o A synchronization function, by which an ASA can request the 264 current value of an objective from a counterpart ASA. With this, 265 there is a corresponding listening function for an ASA that wishes 266 to respond to synchronization requests. 268 o A flood function, by which an ASA can cause the current value of 269 an objective to be flooded throughout the AN so that any ASA can 270 receive it. 272 For further details and some additional housekeeping functions, see 273 [I-D.liu-anima-grasp-api]. 275 This API is intended to support the various interactions expected 276 between most ASAs, such as the interactions outlined in Section 2. 277 However, if ASAs require additional communication between themselves, 278 they can do so using any desired protocol. One option is to use 279 GRASP discovery and synchronization as a rendez-vous mechanism 280 between two ASAs, passing communication parameters such as a TCP port 281 number via GRASP. As noted above, either the ACP or in special cases 282 the autonomic key infrastructure will be used to secure such 283 communications. 285 3.4. Interaction with Intent mechanism 287 At the time of writing, the Intent mechanism for the ANI is 288 undefined. It is expected to operate by an information distribution 289 mechanism that can reach all autonomic nodes, and therefore every 290 ASA. However, each ASA must be capable of operating "out of the box" 291 in the absence of locally defined Intent, so every ASA implementation 292 must include carefully chosen default values and settings for all 293 parameters and choices that might depend on Intent. 295 4. Design of GRASP Objectives 297 The general rules for the format of GRASP Objective options, their 298 names, and IANA registration are given in [I-D.ietf-anima-grasp]. 299 Additionally that document discusses various general considerations 300 for the design of objectives, which are not repeated here. However, 301 we emphasize that the GRASP protocol does not provide transactional 302 integrity. In other words, if an ASA is capable of overlapping 303 several negotiations for a given objective, then the ASA itself must 304 use suitable locking techniques to avoid interference between these 305 negotiations. For example, if an ASA is allocating part of a shared 306 resource to other ASAs, it needs to ensure that the same part of the 307 resource is not allocated twice. This might impact the design of the 308 objective as well as the logic flow of the ASA. 310 In particular, if 'dry run' mode is defined for the objective, its 311 specification, and every implementation, must consider what state 312 needs to be saved following a dry run negotiation, such that a 313 subsequent live negotiation can be expected to succeed. It must be 314 clear how long this state is kept, and what happens if the live 315 negotiation occurs after this state is deleted. An ASA that requests 316 a dry run negotiation must take account of the possibility that a 317 successful dry run is followed by a failed live negotiation. Because 318 of these complexities, the dry run mechanism should only be supported 319 by objectives and ASAs where there is a significant benefit from it. 321 The actual value field of an objective is limited by the GRASP 322 protocol definition to any data structure that can be expressed in 323 Concise Binary Object Representation (CBOR) [RFC7049]. For some 324 objectives, a single data item will suffice; for example an integer, 325 a floating point number or a UTF-8 string. For more complex cases, a 326 simple tuple structure such as [item1, item2, item3] could be used. 327 Nothing prevents using other formats such as JSON, but this requires 328 the ASA to be capable of parsing and generating JSON. The formats 329 acceptable by the GRASP API will limit the options in practice. A 330 fallback solution is for the API to accept and deliver the value 331 field in raw CBOR, with the ASA itself encoding and decoding it via a 332 CBOR library. 334 Note that a mapping from YANG to CBOR is defined by 335 [I-D.ietf-core-yang-cbor]. Subject to the size limit defined for 336 GRASP messages, nothing prevents objectives using YANG in this way. 338 5. Life Cycle 340 Autonomic functions could be permanent, in the sense that ASAs are 341 shipped as part of a product and persist throughout the product's 342 life. However, a more likely situation is that ASAs need to be 343 installed or updated dynamically, because of new requirements or 344 bugs. Because continuity of service is fundamental to autonomic 345 networking, the process of seamlessly replacing a running instance of 346 an ASA with a new version needs to be part of the ASA's design. 348 The implication of service continuity on the design of ASAs can be 349 illustrated along the three main phases of the ASA life-cycle, namely 350 Installation, Instantiation and Operation. 352 +--------------+ 353 Undeployed ------>| |------> Undeployed 354 | Installed | 355 +-->| |---+ 356 Mandate | +--------------+ | Receives a 357 is revoked | +--------------+ | Mandate 358 +---| |<--+ 359 | Instantiated | 360 +-->| |---+ 361 set | +--------------+ | set 362 down | +--------------+ | up 363 +---| |<--+ 364 | Operational | 365 | | 366 +--------------+ 368 Figure 1: Life cycle of an Autonomic Service Agent 370 5.1. Installation phase 372 Before being able to instantiate and run ASAs, the operator must 373 first provision the infrastructure with the sets of ASA software 374 corresponding to its needs and objectives. The provisioning of the 375 infrastructure is realized in the installation phase and consists in 376 installing (or checking the availability of) the pieces of software 377 of the different ASA classes in a set of Installation Hosts. 379 There are 3 properties applicable to the installation of ASAs: 381 The dynamic installation property allows installing an ASA on 382 demand, on any hosts compatible with the ASA. 384 The decoupling property allows controlling resources of a NE from a 385 remote ASA, i.e. an ASA installed on a host machine different from 386 the resources' NE. 388 The multiplicity property allows controlling multiple sets of 389 resources from a single ASA. 391 These three properties are very important in the context of the 392 installation phase as their variations condition how the ASA class 393 could be installed on the infrastructure. 395 5.1.1. Installation phase inputs and outputs 397 Inputs are: 399 [ASA class of type_x] that specifies which classes ASAs to install, 401 [Installation_target_Infrastructure] that specifies the candidate 402 Installation Hosts, 404 [ASA class placement function, e.g. under which criteria/constraints 405 as defined by the operator] 406 that specifies how the installation phase shall meet the 407 operator's needs and objectives for the provision of the 408 infrastructure. In the coupled mode, the placement function is 409 not necessary, whereas in the decoupled mode, the placement 410 function is mandatory, even though it can be as simple as an 411 explicit list of Installation hosts. 413 The main output of the installation phase is an up-to-date directory 414 of installed ASAs which corresponds to [list of ASA classes] 415 installed on [list of installation Hosts]. This output is also 416 useful for the coordination function and corresponds to the static 417 interaction map (see next section). 419 The condition to validate in order to pass to next phase is to ensure 420 that [list of ASA classes] are well installed on [list of 421 installation Hosts]. The state of the ASA at the end of the 422 installation phase is: installed. (not instantiated). The following 423 commands or messages are foreseen: install(list of ASA classes, 424 Installation_target_Infrastructure, ASA class placement function), 425 and un-install (list of ASA classes). 427 5.2. Instantiation phase 429 Once the ASAs are installed on the appropriate hosts in the network, 430 these ASA may start to operate. From the operator viewpoint, an 431 operating ASA means the ASA manages the network resources as per the 432 objectives given. At the ASA local level, operating means executing 433 their control loop/algorithm. 435 But right before that, there are two things to take into 436 consideration. First, there is a difference between 1. having a 437 piece of code available to run on a host and 2. having an agent based 438 on this piece of code running inside the host. Second, in a coupled 439 case, determining which resources are controlled by an ASA is 440 straightforward (the determination is embedded), in a decoupled mode 441 determining this is a bit more complex (hence a starting agent will 442 have to either discover or be taught it). 444 The instantiation phase of an ASA covers both these aspects: starting 445 the agent piece of code (when this does not start automatically) and 446 determining which resources have to be controlled (when this is not 447 obvious). 449 5.2.1. Operator's goal 451 Through this phase, the operator wants to control its autonomic 452 network in two things: 454 1 determine the scope of autonomic functions by instructing which of 455 the network resources have to be managed by which autonomic 456 function (and more precisely which class e.g. 1. version X or 457 version Y or 2. provider A or provider B), 459 2 determine how the autonomic functions are organized by instructing 460 which ASAs have to interact with which other ASAs (or more 461 precisely which set of network resources have to be handled as an 462 autonomous group by their managing ASAs). 464 Additionally in this phase, the operator may want to set objectives 465 to autonomic functions, by configuring the ASAs technical objectives. 467 The operator's goal can be summarized in an instruction to the ANIMA 468 ecosystem matching the following pattern: 470 [ASA of type_x instances] ready to control 471 [Instantiation_target_Infrastructure] with 472 [Instantiation_target_parameters] 474 5.2.2. Instantiation phase inputs and outputs 476 Inputs are: 478 [ASA of type_x instances] that specifies which are the ASAs to be 479 targeted (and more precisely which class e.g. 1. version X or 480 version Y or 2. provider A or provider B), 482 [Instantiation_target_Infrastructure] that specifies which are the 483 resources to be managed by the autonomic function, this can be the 484 whole network or a subset of it like a domain a technology segment 485 or even a specific list of resources, 487 [Instantiation_target_parameters] that specifies which are the 488 technical objectives to be set to ASAs (e.g. an optimization 489 target) 491 Outputs are: 493 [Set of ASAs - Resources relations] describing which resources are 494 managed by which ASA instances, this is not a formal message, but 495 a resulting configuration of a set of ASAs, 497 5.2.3. Instantiation phase requirements 499 The instructions described in section 4.2 could be either: 501 sent to a targeted ASA In which case, the receiving Agent will have 502 to manage the specified list of 503 [Instantiation_target_Infrastructure], with the 504 [Instantiation_target_parameters]. 506 broadcast to all ASAs In which case, the ASAs would collectively 507 determine from the list which Agent(s) would handle which 508 [Instantiation_target_Infrastructure], with the 509 [Instantiation_target_parameters]. 511 This set of instructions can be materialized through a message that 512 is named an Instance Mandate (description TBD). 514 The conclusion of this instantiation phase is a ready to operate ASA 515 (or interacting set of ASAs), then this (or those) ASA(s) can 516 describe themselves by depicting which are the resources they manage 517 and what this means in terms of metrics being monitored and in terms 518 of actions that can be executed (like modifying the parameters 519 values). A message conveying such a self description is named an 520 Instance Manifest (description TBD). 522 Though the operator may well use such a self-description "per se", 523 the final goal of such a description is to be shared with other ANIMA 524 entities like: 526 o the coordination entities (see [I-D.ciavaglia-anima-coordination] 527 - Autonomic Functions Coordination) 529 o collaborative entities in the purpose of establishing knowledge 530 exchanges (some ASAs may produce knowledge or even monitor metrics 531 that other ASAs cannot make by themselves why those would be 532 useful for their execution) 534 5.3. Operation phase 536 Note: This section is to be further developed in future revisions of 537 the document, especially the implications on the design of ASAs. 539 During the Operation phase, the operator can: 541 Activate/Deactivate ASA: meaning enabling those to execute their 542 autonomic loop or not. 544 Modify ASAs targets: meaning setting them different objectives. 546 Modify ASAs managed resources: by updating the instance mandate 547 which would specify different set of resources to manage (only 548 applicable to decouples ASAs). 550 During the Operation phase, running ASAs can interact the one with 551 the other: 553 in order to exchange knowledge (e.g. an ASA providing traffic 554 predictions to load balancing ASA) 556 in order to collaboratively reach an objective (e.g. ASAs 557 pertaining to the same autonomic function targeted to manage a 558 network domain, these ASA will collaborate - in the case of a load 559 balancing one, by modifying the links metrics according to the 560 neighboring resources loads) 562 During the Operation phase, running ASAs are expected to apply 563 coordination schemes 565 then execute their control loop under coordination supervision/ 566 instructions 568 The ASA life-cycle is discussed in more detail in "A Day in the Life 569 of an Autonomic Function" [I-D.peloso-anima-autonomic-function]. 571 6. Coordination between Autonomic Functions 573 Some autonomic functions will be completely independent of each 574 other. However, others are at risk of interfering with each other - 575 for example, two different optimization functions might both attempt 576 to modify the same underlying parameter in different ways. In a 577 complete system, a method is needed of identifying ASAs that might 578 interfere with each other and coordinating their actions when 579 necessary. This issue is considered in "Autonomic Functions 580 Coordination" [I-D.ciavaglia-anima-coordination]. 582 7. Coordination with Traditional Management Functions 584 Some ASAs will have functions that overlap with existing 585 configuration tools and network management mechanisms such as command 586 line interfaces, DHCP, DHCPv6, SNMP, NETCONF, RESTCONF and YANG-based 587 solutions. Each ASA designer will need to consider this issue and 588 how to avoid clashes and inconsistencies. Some specific 589 considerations for interaction with OAM tools are given in 590 [I-D.ietf-anima-stable-connectivity]. As another example, 591 [I-D.ietf-anima-prefix-management] describes how autonomic management 592 of IPv6 prefixes can interact with prefix delegation via DHCPv6. The 593 description of a GRASP objective and of an ASA using it should 594 include a discussion of any such interactions. 596 A related aspect is that management functions often include a data 597 model, quite likely to be expressed in a formal notation such as 598 YANG. This aspect should not be an afterthought in the design of an 599 ASA. To the contrary, the design of the ASA and of its GRASP 600 objectives should match the data model; as noted above, YANG 601 serialized as CBOR may be used directly as the value of a GRASP 602 objective. 604 8. Robustness 606 It is of great importance that all components of an autonomic system 607 are highly robust. In principle they must never fail. This section 608 lists various aspects of robustness that ASA designers should 609 consider. 611 1. If despite all precautions, an ASA does encounter a fatal error, 612 it should in any case restart automatically and try again. To 613 mitigate a hard loop in case of persistent failure, a suitable 614 pause should be inserted before such a restart. The length of 615 the pause depends on the use case. 617 2. If a newly received or calculated value for a parameter falls out 618 of bounds, the corresponding parameter should be either left 619 unchanged or restored to a safe value. 621 3. If a GRASP synchronization or negotiation session fails for any 622 reason, it may be repeated after a suitable pause. The length of 623 the pause depends on the use case. 625 4. If a session fails repeatedly, the ASA should consider that its 626 peer has failed, and cause GRASP to flush its discovery cache and 627 repeat peer discovery. 629 5. Any received GRASP message should be checked. If it is wrongly 630 formatted, it should be ignored. Within a unicast session, an 631 Invalid message (M_INVALID) may be sent. This function may be 632 provided by the GRASP implementation itself. 634 6. Any received GRASP objective should be checked. If it is wrongly 635 formatted, it should be ignored. Within a negotiation session, a 636 Negotiation End message (M_END) with a Decline option (O_DECLINE) 637 should be sent. An ASA may log such events for diagnostic 638 purposes. 640 7. If an ASA receives either an Invalid message (M_INVALID) or a 641 Negotiation End message (M_END) with a Decline option 642 (O_DECLINE), one possible reason is that the peer ASA does not 643 support a new feature of either GRASP or of the objective in 644 question. In such a case the ASA may choose to repeat the 645 operation concerned without using that new feature. 647 8. All other possible exceptions should be handled in an orderly 648 way. There should be no such thing as an unhandled exception 649 (but see point 1 above). 651 9. Security Considerations 653 ASAs are intended to run in an environment that is protected by the 654 Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], 655 admission to which depends on an initial secure bootstrap process 656 [I-D.ietf-anima-bootstrapping-keyinfra]. However, this does not 657 relieve ASAs of responsibility for security. In particular, when 658 ASAs configure or manage network elements outside the ACP, they must 659 use secure techniques and carefully validate any incoming 660 information. As appropriate to their specific functions, ASAs should 661 take account of relevant privacy considerations [RFC6973]. 663 Authorization of ASAs is a subject for future study. At present, 664 ASAs are trusted by virtue of being installed on a node that has 665 successfully joined the ACP. 667 10. IANA Considerations 669 This document makes no request of the IANA. 671 11. Acknowledgements 673 Useful comments were received from Toerless Eckert, Bing Liu, and 674 other members of the ANIMA WG. 676 12. References 678 12.1. Normative References 680 [I-D.ietf-anima-autonomic-control-plane] 681 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 682 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 683 plane-13 (work in progress), December 2017. 685 [I-D.ietf-anima-bootstrapping-keyinfra] 686 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 687 S., and K. Watsen, "Bootstrapping Remote Secure Key 688 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 689 keyinfra-11 (work in progress), February 2018. 691 [I-D.ietf-anima-grasp] 692 Bormann, C., Carpenter, B., and B. Liu, "A Generic 693 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 694 grasp-15 (work in progress), July 2017. 696 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 697 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 698 October 2013, . 700 12.2. Informative References 702 [DeMola06] 703 De Mola, F. and R. Quitadamo, "An Agent Model for Future 704 Autonomic Communications", Proceedings of the 7th WOA 2006 705 Workshop From Objects to Agents 51-59, September 2006. 707 [GANA13] ETSI GS AFI 002, "Autonomic network engineering for the 708 self-managing Future Internet (AFI): GANA Architectural 709 Reference Model for Autonomic Networking, Cognitive 710 Networking and Self-Management.", April 2013, 711 . 714 [Huebscher08] 715 Huebscher, M. and J. McCann, "A survey of autonomic 716 computing--degrees, models, and applications", ACM 717 Computing Surveys (CSUR) Volume 40 Issue 3 DOI: 718 10.1145/1380584.1380585, August 2008. 720 [I-D.ciavaglia-anima-coordination] 721 Ciavaglia, L. and P. Peloso, "Autonomic Functions 722 Coordination", draft-ciavaglia-anima-coordination-01 (work 723 in progress), March 2016. 725 [I-D.ietf-anima-prefix-management] 726 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 727 IPv6 Edge Prefix Management in Large-scale Networks", 728 draft-ietf-anima-prefix-management-07 (work in progress), 729 December 2017. 731 [I-D.ietf-anima-reference-model] 732 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 733 and J. Nobre, "A Reference Model for Autonomic 734 Networking", draft-ietf-anima-reference-model-06 (work in 735 progress), February 2018. 737 [I-D.ietf-anima-stable-connectivity] 738 Eckert, T. and M. Behringer, "Using Autonomic Control 739 Plane for Stable Connectivity of Network OAM", draft-ietf- 740 anima-stable-connectivity-10 (work in progress), February 741 2018. 743 [I-D.ietf-core-yang-cbor] 744 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 745 Minaburo, "CBOR Encoding of Data Modeled with YANG", 746 draft-ietf-core-yang-cbor-06 (work in progress), February 747 2018. 749 [I-D.liu-anima-grasp-api] 750 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 751 Autonomic Signaling Protocol Application Program Interface 752 (GRASP API)", draft-liu-anima-grasp-api-06 (work in 753 progress), November 2017. 755 [I-D.peloso-anima-autonomic-function] 756 Pierre, P. and L. Ciavaglia, "A Day in the Life of an 757 Autonomic Function", draft-peloso-anima-autonomic- 758 function-01 (work in progress), March 2016. 760 [Movahedi12] 761 Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A 762 Survey of Autonomic Network Architectures and Evaluation 763 Criteria", IEEE Communications Surveys & Tutorials Volume: 764 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 765 Page(s): 464 - 490, 2012. 767 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 768 Morris, J., Hansen, M., and R. Smith, "Privacy 769 Considerations for Internet Protocols", RFC 6973, 770 DOI 10.17487/RFC6973, July 2013, 771 . 773 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 774 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 775 Networking: Definitions and Design Goals", RFC 7575, 776 DOI 10.17487/RFC7575, June 2015, 777 . 779 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 780 Chaining (SFC) Architecture", RFC 7665, 781 DOI 10.17487/RFC7665, October 2015, 782 . 784 Appendix A. Change log [RFC Editor: Please remove] 786 draft-carpenter-anima-asa-guidelines-04, 2018-03-03: 788 Added note about simple ASAs. 790 Added note about NFV/SFC services. 792 Improved text about threading v event loop model 794 Added section about coordination with traditional tools. 796 Added appendix with example logic flow. 798 draft-carpenter-anima-asa-guidelines-03, 2017-10-25: 800 Added details on life cycle. 802 Added details on robustness. 804 Added co-authors. 806 draft-carpenter-anima-asa-guidelines-02, 2017-07-01: 808 Expanded description of event-loop case. 810 Added note about 'dry run' mode. 812 draft-carpenter-anima-asa-guidelines-01, 2017-01-06: 814 More sections filled in 816 draft-carpenter-anima-asa-guidelines-00, 2016-09-30: 818 Initial version 820 Appendix B. Example Logic Flows 822 This appendix outlines logic flows for a general purpose resource 823 management ASA. It is assumed that all ASA instances managing this 824 resource use the same logic. However, one instance acts as a master, 825 initialised with a resource pool and a set of policy parameters. The 826 ASA uses a notional objective EX1 and an associated policy parameters 827 objective EX1.Params. 829 B.1. Threaded Example 831 MAIN Thread: 833 Create empty resource pool 834 Decide whether to act as master 835 if master: 836 Obtain initial resources from NOC and add to pool 837 Obtain EX1.Params values from NOC, or use default values 838 Register ASA with GRASP 839 Register objectives EX1 and EX1.Params 840 if master: 841 Start FLOODER thread to flood EX1.Params 842 Start SYNCHRONIZER listener thread for EX1.Params 843 Start MAIN_NEGOTIATOR and GARBAGE_COLLECTOR threads 844 if not master: 845 Obtain value of EX1.Params (from flood cache or via M_SYN message) 846 Start ASSIGN thread 847 while True: 848 if resource pool is low: 849 Calculate needed amount of resource 850 Discover peers (M_DISCOVER / M_RESPONSE) 851 Choose a peer (prefer good_peer if available) 852 Send M_REQ_NEG("EX1", peer) 853 Wait for response (M_NEGOTIATE, M_END or M_WAIT) 854 if OK: 855 if offered resource is sufficient: 856 Negotiation succeeded: Send M_END + O_ACCEPT 857 Add resource to pool 858 good_peer = peer 859 else: 860 Fail negotiation: Send M_END + O_DECLINE 861 sleep(10s) 863 MAIN_NEGOTIATOR Thread : 865 while True: 866 Wait for M_REQ_NEG for EX1 867 start a separate new NEGOTIATOR thread 868 (allows simultaneous negotiations) 870 NEGOTIATOR Thread: 872 Fetch available resource from pool 873 if OK: 874 Offer resource to peer: Send M_NEGOTIATE for EX1 objective 875 if OK: 876 Received M_END + O_ACCEPT 877 Negotiation succeeded 878 else: 879 Received M_END + O_DECLINE or other error 880 Return resource to pool 881 else: 882 Fail negotiation: Send M_END + O_DECLINE 884 ASSIGN Thread: 886 while True: 887 wait for resource request from managed entity 888 get resource from pool 889 if OK: 890 assign resource to managed entity 891 else: 892 signal main thread that pool is low 894 GARBAGE_COLLECTOR Thread: 896 while True: 897 return unused resources to pool 898 sleep(5s) 900 SYNCHRONIZER Thread: 902 while True: 903 wait for M_REQ_SYN message for EX1.Params 904 reply with M_SYNCH message for EX1.Params 906 FLOODER Thread: 908 while True: 909 send M_FLOOD message for EX1.Params 910 sleep(60s) 912 B.2. Event Loop Example 914 TBD 916 Authors' Addresses 918 Brian Carpenter 919 Department of Computer Science 920 University of Auckland 921 PB 92019 922 Auckland 1142 923 New Zealand 925 Email: brian.e.carpenter@gmail.com 927 Laurent Ciavaglia 928 Nokia 929 Villarceaux 930 Nozay 91460 931 FR 933 Email: laurent.ciavaglia@nokia.com 935 Sheng Jiang 936 Huawei Technologies Co., Ltd 937 Q14, Huawei Campus, No.156 Beiqing Road 938 Hai-Dian District, Beijing, 100095 939 P.R. China 941 Email: jiangsheng@huawei.com 942 Pierre Peloso 943 Nokia 944 Villarceaux 945 Nozay 91460 946 FR 948 Email: pierre.peloso@nokia.com