idnits 2.17.1 draft-carpenter-anima-asa-guidelines-03.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 -- The document date (October 25, 2017) is 2367 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-12 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-08 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-05 == Outdated reference: A later version (-06) exists of draft-liu-anima-grasp-api-05 Summary: 1 error (**), 0 flaws (~~), 5 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: April 28, 2018 Nokia 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 P. Peloso 9 Nokia 10 October 25, 2017 12 Guidelines for Autonomic Service Agents 13 draft-carpenter-anima-asa-guidelines-03 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 April 28, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . 6 65 5. Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 11 73 6. Coordination . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 11.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 This document proposes guidelines for the design of Autonomic Service 87 Agents (ASAs) in the context of an Autonomic Network (AN) based on 88 the Autonomic Network Infrastructure (ANI) outlined in the ANIMA 89 reference model [I-D.ietf-anima-reference-model]. This 90 infrastructure makes use of the Autonomic Control Plane (ACP) 91 [I-D.ietf-anima-autonomic-control-plane] and the Generic Autonomic 92 Signaling Protocol (GRASP) [I-D.ietf-anima-grasp]. 94 There is a considerable literature about autonomic agents with a 95 variety of proposals about how they should be characterized. Some 96 examples are [DeMola06], [Huebscher08], [Movahedi12] and [GANA13]. 98 However, for the present document, the basic definitions and goals 99 for autonomic networking given in [RFC7575] apply . According to RFC 100 7575, an Autonomic Service Agent is "An agent implemented on an 101 autonomic node that implements an autonomic function, either in part 102 (in the case of a distributed function) or whole." 104 The reference model [I-D.ietf-anima-reference-model] expands this by 105 adding that an ASA is "a process that makes use of the features 106 provided by the ANI to achieve its own goals, usually including 107 interaction with other ASAs via the GRASP protocol 108 [I-D.ietf-anima-grasp] or otherwise. Of course it also interacts 109 with the specific targets of its function, using any suitable 110 mechanism. Unless its function is very simple, the ASA will need to 111 be multi-threaded so that it can handle overlapping asynchronous 112 operations. It may therefore be a quite complex piece of software in 113 its own right, forming part of the application layer above the ANI." 115 A basic property of an ASA is that it is a relatively complex 116 software component that will in many cases control and monitor 117 simpler entities in the same host or elsewhere. For example, a 118 device controller that manages tens or hundreds of simple devices 119 might contain a single ASA. 121 The remainder of this document offers guidance on the design of ASAs. 123 2. Logical Structure of an Autonomic Service Agent 125 As mentioned above, all but the simplest ASAs will be multi-threaded 126 programs. 128 A typical ASA will have a main thread that performs various initial 129 housekeeping actions such as: 131 o Obtain authorization credentials. 133 o Register the ASA with GRASP. 135 o Acquire relevant policy Intent. 137 o Define data structures for relevant GRASP objectives. 139 o Register with GRASP those objectives that it will actively manage. 141 o Launch a self-monitoring thread. 143 o Enter its main loop. 145 The logic of the main loop will depend on the details of the 146 autonomic function concerned. Whenever asynchronous operations are 147 required, extra threads will be launched. Examples of such threads 148 include: 150 o A background thread to repeatedly flood an objective to the AN, so 151 that any ASA can receive the objective's latest value. 153 o A thread to accept incoming synchronization requests for an 154 objective managed by this ASA. 156 o A thread to accept incoming negotiation requests for an objective 157 managed by this ASA, and then to conduct the resulting negotiation 158 with the counterpart ASA. 160 o A thread to manage subsidiary non-autonomic devices directly. 162 These threads should all either exit after their job is done, or 163 enter a wait state for new work, to avoid blocking other threads 164 unnecessarily. 166 Note: If the programming environment does not support multi- 167 threading, an 'event loop' style of implementation could be adopted, 168 in which case each of the above threads would be implemented as an 169 event handler called in turn by the main loop. In this case, the 170 GRASP API (Section 3.3) must provide non-blocking calls. If 171 necessary, the GRASP session identifier will be used to distinguish 172 simultaneous negotiations. 174 According to the degree of parallelism needed by the application, 175 some of these threads might be launched in multiple instances. In 176 particular, if negotiation sessions with other ASAs are expected to 177 be long or to involve wait states, the ASA designer might allow for 178 multiple simultaneous negotiating threads, with appropriate use of 179 queues and locks to maintain consistency. 181 The main loop itself could act as the initiator of synchronization 182 requests or negotiation requests, when the ASA needs data or 183 resources from other ASAs. In particular, the main loop should watch 184 for changes in policy Intent that affect its operation. It should 185 also do whatever is required to avoid unnecessary resource 186 consumption, such as including an arbitrary wait time in each cycle 187 of the main loop. 189 The self-monitoring thread is of considerable importance. Autonomic 190 service agents must never fail. To a large extent this depends on 191 careful coding and testing, with no unhandled error returns or 192 exceptions, but if there is nevertheless some sort of failure, the 193 self-monitoring thread should detect it, fix it if possible, and in 194 the worst case restart the entire ASA. 196 3. Interaction with the Autonomic Networking Infrastructure 198 3.1. Interaction with the security mechanisms 200 An ASA by definition runs in an autonomic node. Before any normal 201 ASAs are started, such nodes must be bootstrapped into the autonomic 202 network's secure key infrastructure in accordance with 203 [I-D.ietf-anima-bootstrapping-keyinfra]. This key infrastructure 204 will be used to secure the ACP (next section) and may be used by ASAs 205 to set up additional secure interactions with their peers, if needed. 207 Note that the secure bootstrap process itself may include special- 208 purpose ASAs that run in a constrained insecure mode. 210 3.2. Interaction with the Autonomic Control Plane 212 In a normal autonomic network, ASAs will run as clients of the ACP. 213 It will provide a fully secured network environment for all 214 communication with other ASAs, in most cases mediated by GRASP (next 215 section). 217 Note that the ACP formation process itself may include special- 218 purpose ASAs that run in a constrained insecure mode. 220 3.3. Interaction with GRASP and its API 222 GRASP [I-D.ietf-anima-grasp] is expected to run as a separate process 223 with its API [I-D.liu-anima-grasp-api] available in user space. Thus 224 ASAs may operate without special privilege, unless they need it for 225 other reasons. The ASA's view of GRASP is built around GRASP 226 objectives (Section 4), defined as data structures containing 227 administrative information such as the objective's unique name, and 228 its current value. The format and size of the value is not 229 restricted by the protocol, except that it must be possible to 230 serialise it for transmission in CBOR [RFC7049], which is no 231 restriction at all in practice. 233 The GRASP API offers the following features: 235 o Registration functions, so that an ASA can register itself and the 236 objectives that it manages. 238 o A discovery function, by which an ASA can discover other ASAs 239 supporting a given objective. 241 o A negotiation request function, by which an ASA can start 242 negotiation of an objective with a counterpart ASA. With this, 243 there is a corresponding listening function for an ASA that wishes 244 to respond to negotiation requests, and a set of functions to 245 support negotiating steps. 247 o A synchronization function, by which an ASA can request the 248 current value of an objective from a counterpart ASA. With this, 249 there is a corresponding listening function for an ASA that wishes 250 to respond to synchronization requests. 252 o A flood function, by which an ASA can cause the current value of 253 an objective to be flooded throughout the AN so that any ASA can 254 receive it. 256 For further details and some additional housekeeping functions, see 257 [I-D.liu-anima-grasp-api]. 259 This API is intended to support the various interactions expected 260 between most ASAs, such as the interactions outlined in Section 2. 261 However, if ASAs require additional communication between themselves, 262 they can do so using any desired protocol. One option is to use 263 GRASP discovery and synchronization as a rendez-vous mechanism 264 between two ASAs, passing communication parameters such as a TCP port 265 number as the value of a GRASP objective. As noted above, either the 266 ACP or in special cases the autonomic key infrastructure will be used 267 to secure such communications. 269 3.4. Interaction with Intent mechanism 271 At the time of writing, the Intent mechanism for the ANI is 272 undefined. It is expected to operate by an information distribution 273 mechanism that can reach all autonomic nodes, and therefore every 274 ASA. However, each ASA must be capable of operating "out of the box" 275 in the absence of locally defined Intent, so every ASA implementation 276 must include carefully chosen default values and settings for all 277 parameters and choices that might depend on Intent. 279 4. Design of GRASP Objectives 281 The general rules for the format of GRASP Objective options, their 282 names, and IANA registration are given in [I-D.ietf-anima-grasp]. 283 Additionally that document discusses various general considerations 284 for the design of objectives, which are not repeated here. However, 285 we emphasize that the GRASP protocol does not provide transactional 286 integrity. In other words, if an ASA is capable of overlapping 287 several negotiations for a given objective, then the ASA itself must 288 use suitable locking techniques to avoid interference between these 289 negotiations. For example, if an ASA is allocating part of a shared 290 resource to other ASAs, it needs to ensure that the same part of the 291 resource is not allocated twice. This might impact the design of the 292 objective as well as the logic flow of the ASA. 294 In particular, if 'dry run' mode is defined for the objective, its 295 specification, and every implementation, must consider what state 296 needs to be saved following a dry run negotiation, such that a 297 subsequent live negotiation can be expected to succeed. It must be 298 clear how long this state is kept, and what happens if the live 299 negotiation occurs after this state is deleted. An ASA that requests 300 a dry run negotiation must take account of the possibility that a 301 successful dry run is followed by a failed live negotiation. Because 302 of these complexities, the dry run mechanism should only be supported 303 by objectives and ASAs where there is a significant benefit from it. 305 The actual value field of an objective is limited by the GRASP 306 protocol definition to any data structure that can be expressed in 307 Concise Binary Object Representation (CBOR) [RFC7049]. For some 308 objectives, a single data item will suffice; for example an integer, 309 a floating point number or a UTF-8 string. For more complex cases, a 310 simple tuple structure such as [item1, item2, item3] could be used. 311 Nothing prevents using other formats such as JSON, but this requires 312 the ASA to be capable of parsing and generating JSON. The formats 313 acceptable by the GRASP API will limit the options in practice. A 314 fallback solution is for the API to accept and deliver the value 315 field in raw CBOR, with the ASA itself encoding and decoding it via a 316 CBOR library. 318 5. Life Cycle 320 Autonomic functions could be permanent, in the sense that ASAs are 321 shipped as part of a product and persist throughout the product's 322 life. However, a more likely situation is that ASAs need to be 323 installed or updated dynamically, because of new requirements or 324 bugs. Because continuity of service is fundamental to autonomic 325 networking, the process of seamlessly replacing a running instance of 326 an ASA with a new version needs to be part of the ASA's design. 328 The implication of service continuity on the design of ASAs can be 329 illustrated along the three main phases of the ASA life-cycle, namely 330 Installation, Instantiation and Operation. 332 +--------------+ 333 Undeployed ------>| |------> Undeployed 334 | Installed | 335 +-->| |---+ 336 Mandate | +--------------+ | Receives a 337 is revoked | +--------------+ | Mandate 338 +---| |<--+ 339 | Instantiated | 340 +-->| |---+ 341 set | +--------------+ | set 342 down | +--------------+ | up 343 +---| |<--+ 344 | Operational | 345 | | 346 +--------------+ 348 Figure 1: Life cycle of an Autonomic Service Agent 350 5.1. Installation phase 352 Before being able to instantiate and run ASAs, the operator must 353 first provision the infrastructure with the sets of ASA software 354 corresponding to its needs and objectives. The provisioning of the 355 infrastructure is realized in the installation phase and consists in 356 installing (or checking the availability of) the pieces of software 357 of the different ASA classes in a set of Installation Hosts. 359 There are 3 properties applicable to the installation of ASAs: 361 The dynamic installation property allows installing an ASA on 362 demand, on any hosts compatible with the ASA. 364 The decoupling property allows controlling resources of a NE from a 365 remote ASA, i.e. an ASA installed on a host machine different from 366 the resources' NE. 368 The multiplicity property allows controlling multiple sets of 369 resources from a single ASA. 371 These three properties are very important in the context of the 372 installation phase as their variations condition how the ASA class 373 could be installed on the infrastructure. 375 5.1.1. Installation phase inputs and outputs 377 Inputs are: 379 [ASA class of type_x] that specifies which classes ASAs to install, 381 [Installation_target_Infrastructure] that specifies the candidate 382 Installation Hosts, 384 [ASA class placement function, e.g. under which criteria/constraints 385 as defined by the operator] 386 that specifies how the installation phase shall meet the 387 operator's needs and objectives for the provision of the 388 infrastructure. In the coupled mode, the placement function is 389 not necessary, whereas in the decoupled mode, the placement 390 function is mandatory, even though it can be as simple as an 391 explicit list of Installation hosts. 393 The main output of the installation phase is an up-to-date directory 394 of installed ASAs which corresponds to [list of ASA classes] 395 installed on [list of installation Hosts]. This output is also 396 useful for the coordination function and corresponds to the static 397 interaction map (see next section). 399 The condition to validate in order to pass to next phase is to ensure 400 that [list of ASA classes] are well installed on [list of 401 installation Hosts]. The state of the ASA at the end of the 402 installation phase is: installed. (not instantiated). The following 403 commands or messages are foreseen: install(list of ASA classes, 404 Installation_target_Infrastructure, ASA class placement function), 405 and un-install (list of ASA classes). 407 5.2. Instantiation phase 409 Once the ASAs are installed on the appropriate hosts in the network, 410 these ASA may start to operate. From the operator viewpoint, an 411 operating ASA means the ASA manages the network resources as per the 412 objectives given. At the ASA local level, operating means executing 413 their control loop/algorithm. 415 But right before that, there are two things to take into 416 consideration. First, there is a difference between 1. having a 417 piece of code available to run on a host and 2. having an agent based 418 on this piece of code running inside the host. Second, in a coupled 419 case, determining which resources are controlled by an ASA is 420 straightforward (the determination is embedded), in a decoupled mode 421 determining this is a bit more complex (hence a starting agent will 422 have to either discover or be taught it). 424 The instantiation phase of an ASA covers both these aspects: starting 425 the agent piece of code (when this does not start automatically) and 426 determining which resources have to be controlled (when this is not 427 obvious). 429 5.2.1. Operator's goal 431 Through this phase, the operator wants to control its autonomic 432 network in two things: 434 1 determine the scope of autonomic functions by instructing which of 435 the network resources have to be managed by which autonomic 436 function (and more precisely which class e.g. 1. version X or 437 version Y or 2. provider A or provider B), 439 2 determine how the autonomic functions are organized by instructing 440 which ASAs have to interact with which other ASAs (or more 441 precisely which set of network resources have to be handled as an 442 autonomous group by their managing ASAs). 444 Additionally in this phase, the operator may want to set objectives 445 to autonomic functions, by configuring the ASAs technical objectives. 447 The operator's goal can be summarized in an instruction to the ANIMA 448 ecosystem matching the following pattern: 450 [ASA of type_x instances] ready to control 451 [Instantiation_target_Infrastructure] with 452 [Instantiation_target_parameters] 454 5.2.2. Instantiation phase inputs and outputs 456 Inputs are: 458 [ASA of type_x instances] that specifies which are the ASAs to be 459 targeted (and more precisely which class e.g. 1. version X or 460 version Y or 2. provider A or provider B), 462 [Instantiation_target_Infrastructure] that specifies which are the 463 resources to be managed by the autonomic function, this can be the 464 whole network or a subset of it like a domain a technology segment 465 or even a specific list of resources, 467 [Instantiation_target_parameters] that specifies which are the 468 technical objectives to be set to ASAs (e.g. an optimization 469 target) 471 Outputs are: 473 [Set of ASAs - Resources relations] describing which resources are 474 managed by which ASA instances, this is not a formal message, but 475 a resulting configuration of a set of ASAs, 477 5.2.3. Instantiation phase requirements 479 The instructions described in section 4.2 could be either: 481 sent to a targeted ASA In which case, the receiving Agent will have 482 to manage the specified list of 483 [Instantiation_target_Infrastructure], with the 484 [Instantiation_target_parameters]. 486 broadcast to all ASAs In which case, the ASAs would collectively 487 determine from the list which Agent(s) would handle which 488 [Instantiation_target_Infrastructure], with the 489 [Instantiation_target_parameters]. 491 This set of instructions can be materialized through a message that 492 is named an Instance Mandate (description TBD). 494 The conclusion of this instantiation phase is a ready to operate ASA 495 (or interacting set of ASAs), then this (or those) ASA(s) can 496 describe themselves by depicting which are the resources they manage 497 and what this means in terms of metrics being monitored and in terms 498 of actions that can be executed (like modifying the parameters 499 values). A message conveying such a self description is named an 500 Instance Manifest (description TBD). 502 Though the operator may well use such a self-description "per se", 503 the final goal of such a description is to be shared with other ANIMA 504 entities like: 506 o the coordination entities (see [I-D.ciavaglia-anima-coordination] 507 - Autonomic Functions Coordination) 509 o collaborative entities in the purpose of establishing knowledge 510 exchanges (some ASAs may produce knowledge or even monitor metrics 511 that other ASAs cannot make by themselves why those would be 512 useful for their execution) 514 5.3. Operation phase 516 Note: This section is to be further developed in future revisions of 517 the document, especially the implications on the design of ASAs. 519 During the Operation phase, the operator can: 521 Activate/Deactivate ASA: meaning enabling those to execute their 522 autonomic loop or not. 524 Modify ASAs targets: meaning setting them different objectives. 526 Modify ASAs managed resources: by updating the instance mandate 527 which would specify different set of resources to manage (only 528 applicable to decouples ASAs). 530 During the Operation phase, running ASAs can interact the one with 531 the other: 533 in order to exchange knowledge (e.g. an ASA providing traffic 534 predictions to load balancing ASA) 536 in order to collaboratively reach an objective (e.g. ASAs 537 pertaining to the same autonomic function targeted to manage a 538 network domain, these ASA will collaborate - in the case of a load 539 balancing one, by modifying the links metrics according to the 540 neighboring resources loads) 542 During the Operation phase, running ASAs are expected to apply 543 coordination schemes 545 then execute their control loop under coordination supervision/ 546 instructions 548 The ASA life-cycle is discussed in more detail in "A Day in the Life 549 of an Autonomic Function" [I-D.peloso-anima-autonomic-function]. 551 6. Coordination 553 Some autonomic functions will be completely independent of each 554 other. However, others are at risk of interfering with each other - 555 for example, two different optimization functions might both attempt 556 to modify the same underlying parameter in different ways. In a 557 complete system, a method is needed of identifying ASAs that might 558 interfere with each other and coordinating their actions when 559 necessary. This issue is considered in "Autonomic Functions 560 Coordination" [I-D.ciavaglia-anima-coordination]. 562 7. Robustness 564 It is of great importance that all components of an autonomic system 565 are highly robust. In principle they must never fail. This section 566 lists various aspects of robustness that ASA designers should 567 consider. 569 1. If despite all precautions, an ASA does encounter a fatal error, 570 it should in any case restart automatically and try again. To 571 mitigate a hard loop in case of persistent failure, a suitable 572 pause should be inserted before such a restart. The length of 573 the pause depends on the use case. 575 2. If a newly received or calculated value for a parameter falls out 576 of bounds, the corresponding parameter should be either left 577 unchanged or restored to a safe value. 579 3. If a GRASP synchronization or negotiation session fails for any 580 reason, it may be repeated after a suitable pause. The length of 581 the pause depends on the use case. 583 4. If a session fails repeatedly, the ASA should consider that its 584 peer has failed, and cause GRASP to flush its discovery cache and 585 repeat peer discovery. 587 5. Any received GRASP message should be checked. If it is wrongly 588 formatted, it should be ignored. Within a unicast session, an 589 Invalid message (M_INVALID) may be sent. This function may be 590 provided by the GRASP implementation itself. 592 6. Any received GRASP objective should be checked. If it is wrongly 593 formatted, it should be ignored. Within a negotiation session, a 594 Negotiation End message (M_END) with a Decline option (O_DECLINE) 595 should be sent. An ASA may log such events for diagnostic 596 purposes. 598 7. If an ASA receives either an Invalid message (M_INVALID) or a 599 Negotiation End message (M_END) with a Decline option 600 (O_DECLINE), one possible reason is that the peer ASA does not 601 support a new feature of either GRASP or of the objective in 602 question. In such a case the ASA may choose to repeat the 603 operation concerned without using that new feature. 605 8. All other possible exceptions should be handled in an orderly 606 way. There should be no such thing as an unhandled exception 607 (but see point 1 above). 609 8. Security Considerations 611 ASAs are intended to run in an environment that is protected by the 612 Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], 613 admission to which depends on an initial secure bootstrap process 614 [I-D.ietf-anima-bootstrapping-keyinfra]. However, this does not 615 relieve ASAs of responsibility for security. In particular, when 616 ASAs configure or manage network elements outside the ACP, they must 617 use secure techniques and carefully validate any incoming 618 information. As appropriate to their specific functions, ASAs should 619 take account of relevant privacy considerations [RFC6973]. 621 Authorization of ASAs is a subject for future study. At present, 622 ASAs are trusted by virtue of being installed on a node that has 623 successfully joined the ACP. 625 9. IANA Considerations 627 This document makes no request of the IANA. 629 10. Acknowledgements 631 TBD. 633 11. References 635 11.1. Normative References 637 [I-D.ietf-anima-autonomic-control-plane] 638 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 639 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 640 plane-12 (work in progress), October 2017. 642 [I-D.ietf-anima-bootstrapping-keyinfra] 643 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 644 S., and K. Watsen, "Bootstrapping Remote Secure Key 645 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 646 keyinfra-08 (work in progress), October 2017. 648 [I-D.ietf-anima-grasp] 649 Bormann, C., Carpenter, B., and B. Liu, "A Generic 650 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 651 grasp-15 (work in progress), July 2017. 653 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 654 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 655 October 2013, . 657 11.2. Informative References 659 [DeMola06] 660 De Mola, F. and R. Quitadamo, "An Agent Model for Future 661 Autonomic Communications", Proceedings of the 7th WOA 2006 662 Workshop From Objects to Agents 51-59, September 2006. 664 [GANA13] ETSI GS AFI 002, "Autonomic network engineering for the 665 self-managing Future Internet (AFI): GANA Architectural 666 Reference Model for Autonomic Networking, Cognitive 667 Networking and Self-Management.", April 2013, 668 . 671 [Huebscher08] 672 Huebscher, M. and J. McCann, "A survey of autonomic 673 computing--degrees, models, and applications", ACM 674 Computing Surveys (CSUR) Volume 40 Issue 3 DOI: 675 10.1145/1380584.1380585, August 2008. 677 [I-D.ciavaglia-anima-coordination] 678 Ciavaglia, L. and P. Peloso, "Autonomic Functions 679 Coordination", draft-ciavaglia-anima-coordination-01 (work 680 in progress), March 2016. 682 [I-D.ietf-anima-reference-model] 683 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 684 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 685 Reference Model for Autonomic Networking", draft-ietf- 686 anima-reference-model-05 (work in progress), October 2017. 688 [I-D.liu-anima-grasp-api] 689 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 690 Autonomic Signaling Protocol Application Program Interface 691 (GRASP API)", draft-liu-anima-grasp-api-05 (work in 692 progress), October 2017. 694 [I-D.peloso-anima-autonomic-function] 695 Pierre, P. and L. Ciavaglia, "A Day in the Life of an 696 Autonomic Function", draft-peloso-anima-autonomic- 697 function-01 (work in progress), March 2016. 699 [Movahedi12] 700 Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A 701 Survey of Autonomic Network Architectures and Evaluation 702 Criteria", IEEE Communications Surveys & Tutorials Volume: 703 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, 704 Page(s): 464 - 490, 2012. 706 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 707 Morris, J., Hansen, M., and R. Smith, "Privacy 708 Considerations for Internet Protocols", RFC 6973, 709 DOI 10.17487/RFC6973, July 2013, 710 . 712 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 713 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 714 Networking: Definitions and Design Goals", RFC 7575, 715 DOI 10.17487/RFC7575, June 2015, 716 . 718 Appendix A. Change log [RFC Editor: Please remove] 720 draft-carpenter-anima-asa-guidelines-03, 2017-10-25: 722 Added details on life cycle. 724 Added details on robustness. 726 Added co-authors. 728 draft-carpenter-anima-asa-guidelines-02, 2017-07-01: 730 Expanded description of event-loop case. 732 Added note about 'dry run' mode. 734 draft-carpenter-anima-asa-guidelines-01, 2017-01-06: 736 More sections filled in 738 draft-carpenter-anima-asa-guidelines-00, 2016-09-30: 740 Initial version 742 Authors' Addresses 744 Brian Carpenter 745 Department of Computer Science 746 University of Auckland 747 PB 92019 748 Auckland 1142 749 New Zealand 751 Email: brian.e.carpenter@gmail.com 752 Laurent Ciavaglia 753 Nokia 754 Villarceaux 755 Nozay 91460 756 FR 758 Email: laurent.ciavaglia@nokia.com 760 Sheng Jiang 761 Huawei Technologies Co., Ltd 762 Q14, Huawei Campus, No.156 Beiqing Road 763 Hai-Dian District, Beijing, 100095 764 P.R. China 766 Email: jiangsheng@huawei.com 768 Pierre Peloso 769 Nokia 770 Villarceaux 771 Nozay 91460 772 FR 774 Email: pierre.peloso@nokia.com