idnits 2.17.1 draft-behringer-anima-reference-model-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 30, 2015) is 3223 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7576' is mentioned on line 786, but not defined == Missing Reference: 'TBC' is mentioned on line 822, but not defined == Missing Reference: 'Kephart03' is mentioned on line 916, but not defined == Missing Reference: 'Strassner09' is mentioned on line 917, but not defined == Missing Reference: 'Strassner07' is mentioned on line 919, but not defined == Missing Reference: 'Boyd95' is mentioned on line 920, but not defined == Missing Reference: 'Meyer97' is mentioned on line 1041, but not defined == Unused Reference: 'I-D.behringer-anima-autonomic-addressing' is defined on line 1226, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-behringer-anima-autonomic-addressing-01 == Outdated reference: A later version (-03) exists of draft-behringer-anima-autonomic-control-plane-02 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA M. Behringer, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational B. Carpenter 5 Expires: January 1, 2016 Univ. of Auckland 6 T. Eckert 7 Cisco 8 L. Ciavaglia 9 Alcatel Lucent 10 B. Liu 11 Huawei Technologies 12 J. Nobre 13 Federal University of Rio Grande do Sul 14 J. Strassner 15 Huawei Technologies 16 June 30, 2015 18 A Reference Model for Autonomic Networking 19 draft-behringer-anima-reference-model-03 21 Abstract 23 This document describes a reference model for Autonomic Networking. 24 The goal is to define how the various elements in an autonomic 25 context work together, to describe their interfaces and relations. 26 While the document is written as generally as possible, the initial 27 solutions are limited to the chartered scope of the WG. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 1, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 4 65 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 5 66 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Full AN Nodes . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Constrained AN Nodes (*) . . . . . . . . . . . . . . . . 6 69 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 6 70 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1.1. Naming requirements . . . . . . . . . . . . . . . . . 6 72 4.1.2. Proposed Mechanisms . . . . . . . . . . . . . . . . . 7 73 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.2.1. Requirements and Fundamental Concepts . . . . . . . . 9 75 4.2.2. The Base Addressing Scheme . . . . . . . . . . . . . 10 76 4.2.3. Possible Sub-Schemes . . . . . . . . . . . . . . . . 11 77 4.2.4. Address Hierarchy . . . . . . . . . . . . . . . . . . 12 78 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.4. Signaling Between Autonomic Nodes . . . . . . . . . . . . 13 80 4.5. Intent Distribution . . . . . . . . . . . . . . . . . . . 14 81 4.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.7. The Autonomic Control Plane . . . . . . . . . . . . . . . 14 83 5. Security and Trust Infrastructure . . . . . . . . . . . . . . 15 84 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 15 85 5.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 15 86 5.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.4. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 15 88 5.5. Cross-Domain Functionality (*) . . . . . . . . . . . . . 15 89 6. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 16 90 6.1. General Description of an ASA . . . . . . . . . . . . . . 16 91 6.2. Specific ASAs for the Enrolment Process . . . . . . . . . 16 92 6.2.1. The Enrolment ASA . . . . . . . . . . . . . . . . . . 16 93 6.2.2. The Enrolment Proxy ASA . . . . . . . . . . . . . . . 16 94 6.2.3. The Registrar ASA . . . . . . . . . . . . . . . . . . 16 95 7. Management and Programmability . . . . . . . . . . . . . . . 16 96 7.1. How an AN Network Is Managed . . . . . . . . . . . . . . 16 97 7.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 17 98 7.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 18 99 7.4. Feedback Loops to NOC(*) . . . . . . . . . . . . . . . . 19 100 7.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 19 101 7.5.1. Types of Control (*) . . . . . . . . . . . . . . . . 20 102 7.5.2. Types of Control Loops (*) . . . . . . . . . . . . . 20 103 7.5.3. Management of an Autonomic Control Loop (*) . . . . . 21 104 7.5.4. Elements of an Autonomic Control Loop (*) . . . . . . 22 105 7.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 22 106 7.6.1. Dynamic APIs (*) . . . . . . . . . . . . . . . . . . 22 107 7.6.2. APIs and Semantics(*) . . . . . . . . . . . . . . . . 23 108 7.6.3. API Considerations (*) . . . . . . . . . . . . . . . 23 109 7.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 23 110 8. Coordination Between Autonomic Functions (*) . . . . . . . . 24 111 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 24 112 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 25 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 114 9.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 26 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 116 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 120 1. Introduction 122 The document "Autonomic Networking - Definitions and Design Goals" 123 [RFC7575] explains the fundamental concepts behind Autonomic 124 Networking, and defines the relevant terms in this space. In section 125 5 it describes a high level reference model. This document defines 126 this reference model with more detail, to allow for functional and 127 protocol specifications to be developed in an architecturally 128 consistent, non-overlapping manner. While the document is written as 129 generally as possible, the initial solutions are limited to the 130 chartered scope of the WG. 132 As discussed in [RFC7575], the goal of this work is not to focus 133 exclusively on fully autonomic nodes or networks. In reality, most 134 networks will run with some autonomic functions, while the rest of 135 the network is traditionally managed. This reference model allows 136 for this hybrid approach. 138 This is a living document and will evolve with the technical 139 solutions developed in the ANIMA WG. Sections marked with (*) do not 140 represent current charter items. While this document must give a 141 long term architectural view, not all functions will be standardized 142 at the same time. 144 2. The Network View 146 This section describes the various elements in a network with 147 autonomic functions, and how these entities work together, on a high 148 level. Subsequent sections explain the detailed inside view for each 149 of the autonomic network elements, as well as the network functions 150 (or interfaces) between those elements. 152 Figure 1 shows the high level view of an Autonomic Network. It 153 consists of a number of autonomic nodes, which interact directly with 154 each other. Those autonomic nodes provide a common set of 155 capabilities across the network, called the "Autonomic Networking 156 Infrastructure" (ANI). The ANI provides functions like naming, 157 addressing, negotiation, synchronization, discovery and messaging. 159 Autonomic functions typically span several, possibly all nodes in the 160 network. The atomic entities of an autonomic function are called the 161 "Autonomic Service Agents" (ASA), which are instantiated on nodes. 163 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 164 : : Autonomic Function 1 : : 165 : ASA 1 : ASA 1 : ASA 1 : ASA 1 : 166 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 167 : : : 168 : +- - - - - - - - - - - - - - + : 169 : : Autonomic Function 2 : : 170 : : ASA 2 : ASA 2 : : 171 : +- - - - - - - - - - - - - - + : 172 : : : 173 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 174 : Autonomic Networking Infrastructure : 175 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 176 +--------+ : +--------+ : +--------+ : +--------+ 177 | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | 178 +--------+ : +--------+ : +--------+ : +--------+ 180 Figure 1: High level view of an Autonomic Network 182 In a horizontal view, autonomic functions span across the network, as 183 well as the Autonomic Networking Infrastructure. In a vertical view, 184 a node always implements the ANI, plus it may have one or several 185 Autonomic Service Agents. 187 The Autonomic Networking Infrastructure (ANI) therefore is the 188 foundation for autonomic functions. The current charter of the ANIMA 189 WG is to specify the ANI, using a few autonomic functions as use 190 cases. 192 3. The Autonomic Network Element 194 3.1. Architecture 196 This section describes an autonomic network element and its internal 197 architecture. The reference model explained in 198 [I-D.irtf-nmrg-autonomic-network-definitions] shows the sources of 199 information that an autonomic service agent can leverage: Self- 200 knowledge, network knowledge (through discovery), Intent, and 201 feedback loops. Fundamentally, there are two levels inside an 202 autonomic node: the level of Autonomic Service Agents, and the level 203 of the Autonomic Networking Infrastructure, with the former using the 204 services of the latter. Figure 2 illustrates this concept. 206 +------------------------------------------------------------+ 207 | | 208 | +-----------+ +------------+ +------------+ | 209 | | Autonomic | | Autonomic | | Autonomic | | 210 | | Service | | Service | | Service | | 211 | | Agent 1 | | Agent 2 | | Agent 3 | | 212 | +-----------+ +------------+ +------------+ | 213 | ^ ^ ^ | 214 | - - | - - API level - -| - - - - - - - |- - - | 215 | V V V | 216 |------------------------------------------------------------| 217 | Autonomic Networking Infrastructure | 218 | - Data structures (ex: certificates, peer information) | 219 | - Autonomic Control Plane | 220 | - discovery, negotiation and synchronisation functions | 221 | - Intent distribution | 222 | - aggregated reporting and feedback loops | 223 | - routing | 224 |------------------------------------------------------------| 225 | Basic Operating System Functions | 226 +------------------------------------------------------------+ 228 Figure 2: Model of an autonomic node 230 The Autonomic Networking Infrastructure (lower part of Figure 2) 231 contains node specific data structures, for example trust information 232 about itself and its peers, as well as a generic set of functions, 233 independent of a particular usage. This infrastructure should be 234 generic, and support a variety of Autonomic Service Agents (upper 235 part of Figure 2). The Autonomic Control Plane is the summary of all 236 interactions of the Autonomic Networking Infrastructure with other 237 nodes and services. 239 The use cases of "Autonomics" such as self-management, self- 240 optimisation, etc, are implemented as Autonomic Service Agents. They 241 use the services and data structures of the underlying autonomic 242 networking infrastructure. The underlying Autonomic Networking 243 Infrastructure should itself be self-managing. 245 The "Basic Operating System Functions" include the "normal OS", 246 including the network stack, security functions, etc. 248 3.2. Full AN Nodes 250 Full AN nodes have the full Autonomic Networking Infrastructure, with 251 the full functionality (details to be worked out). They support all 252 the capabilities outlined in the rest of the document. [tbc] 254 3.3. Constrained AN Nodes (*) 256 Constrained nodes have a reduced ANI, with a well-defined minimal 257 functionality (details to be worked out): They do need to be able to 258 join the network, and communicate with at least a helper node which 259 has full ANI functionality. Capabilities of constrained nodes need 260 to be defined here. [tbc] 262 4. The Autonomic Networking Infrastructure 264 The Autonomic Networking Infrastructure provides a layer of common 265 functionality across an Autonomic Network. It comprises "must 266 implement" functions and services, as well as extensions. 268 An Autonomic Function, comprising of Autonomic Service Agents on 269 nodes, can rely on the fact that all nodes in the network implement 270 at least the "must implement" functions. 272 4.1. Naming 274 4.1.1. Naming requirements 276 o Representing each device 278 Inside a domain, each autonomic device needs a domain specific 279 identifier. 281 [Open Questions] Are there devices that don't need names? Do 282 ASAs need names? 284 o Uniqueness 286 The names MUST NOT collide within one autonomic domain. 288 It is acceptable that the names in different domains collide, 289 since they could be distinguished by domains. 291 o Semantic Encoding 293 It is RECOMMENDED that the names encode some semantics rather 294 than meaningless strings. The semantics might be: 296 + Location 298 + Device type 300 + Functional role 302 + Ownership 304 + etc. 306 This is for ease of management consideration that network 307 administrators could easily recognize the device directly 308 through the names. 310 o Consistency 312 The devices' naming SHOULD follow the same pattern within a 313 domain. 315 4.1.2. Proposed Mechanisms 317 __ 319 o Structured Naming Pattern 321 The whole name string could be divided into several fields, 322 each of which representing a specific semantic as described 323 above. For example: Location-DeviceType-FunctionalRole- 324 DistinguisherNumber@NameofDomain. 326 The structure should be flexible that some fields are optional. 327 When these optional fields are added, the name could still be 328 recognized as the previous one. In above example, the 329 "DistinguisherNumber" and "NameofDomain" are mandatory whereas 330 others are optional. At initial stage, the devices might be 331 only capable of self-generating the mandatory fields and the 332 "DeviceType" because of the lack of knowledge. Later, they 333 might have learned the "Location" and "FunctionalRole" and 334 added the fields into current name. However, the other devices 335 could still recognize it according to the same 336 "DistinguisherNumber". 338 o Advertised Common Fields 340 Some fields in the structured name might be common among the 341 domain (e.g. "Location" "NameofDomain"). Thus, these part of 342 the names could be advertised through Intent 343 DistributionSection 4.5. 345 o Self-generated Fields 347 The mandatory fields SHOULD be self-generated so that one 348 device could name itself sufficiently without any advertised 349 knowledges. 351 There should various methods for a device to extract/generate a 352 proper word for each mandatory semantic fields (e.g. 353 "DeviceType", "DistinguisherNum") from its self-knowledge. 355 Detailed design of specific naming patterns and methods are out of 356 scope of this document. 358 4.2. Addressing 360 Autonomic Service Agents (ASAs) need to communicate with each other, 361 using the autonomic addressing of the node they reside on. This 362 section describes the addressing approach of the Autonomic Networking 363 Infrastructure, used by ASAs. It does NOT describe addressing 364 approaches for the data plane of the network, which may be configured 365 and managed in the traditional way, or negotiated as a service of an 366 ASA. One use case for such an autonomic function is described in 367 [I-D.jiang-auto-addr-management]. The addressing of the Autonomic 368 Networking Infrastructure is in scope for this section, the address 369 space they negotiate for the data plane is not. 371 Autonomic addressing is a function of the Autonomic Networking 372 Infrastructure (lower part of Figure 2). ASAs do not have their own 373 addresses. They may use either API calls, or the autonomic 374 addressing scheme of the Autonomic Networking Infrastructure. 376 4.2.1. Requirements and Fundamental Concepts 378 An autonomic addressing scheme has the following requirements: 380 o Zero-touch for simple networks: Simple networks should have 381 complete self-management of addressing, and not require any 382 central address management, tools, or address planning. 384 o Low-touch for complex networks: If complex networks require 385 operator input for autonomic address management, it should be 386 limited to high level guidance only, expressed in Intent. 388 o Flexibility: The addressing scheme must be flexible enough for 389 nodes to be able to move around, for the network to grow, split 390 and merge. 392 o Robustness: It should be as hard as possible for an administrator 393 to negatively affect addressing (and thus connectivity) in the 394 autonomic context. 396 o Support for virtualization: Autonomic Nodes may support Autonomic 397 Service Agents in different virtual machines or containers. The 398 addressing scheme should support this architecture. 400 o Simplicity: To make engineering simpler, and to give the human 401 administrator an easy way to trouble-shoot autonomic functions. 403 o Scale: The proposed scheme should work in any network of any size. 405 o Upgradability: The scheme must be able to support different 406 addressing concepts in the future. 408 These are the fundamental concepts of autonomic addressing: 410 o IPv6 only: Autonomic processes SHOULD (as defined in [RFC2119]) 411 use exclusively IPv6, for simplicity reasons. 413 o Usage: Autonomic addresses are exclusively used for self- 414 management functions inside a trusted domain. They are not used 415 for user traffic. Communications with entities outside the 416 trusted domain use another address space, for example normally 417 managed routable address space. 419 o Separation: Autonomic address space is used separately from user 420 address space and other address realms. This supports the 421 robustness requirement. Link-local is considered not part of user 422 address space for this purpose. 424 o Overlay network: Routeable addresses for AN nodes are used 425 exclusively in a secure overlay network which is the basis of the 426 ACP. This means that these addresses will be assigned to the 427 loopback interface in most operating systems. All other 428 interfaces exclusively use IPv6 link local for autonomic 429 functions. The usage of IPv6 link local addressing is discussed 430 in [RFC7404]. 432 o Use-ULA: For these overlay addresses of autonomic nodes, we use 433 Unique Local Addresses (ULA), as specified in [RFC4193]. An 434 alternative scheme was discussed, using assigned ULA addressing. 435 The consensus was to use standard ULA, because it was deemed to be 436 sufficient. 438 o No external connectivity: They do not provide access to the 439 Internet. If a node requires further reaching connectivity, it 440 should use another, traditionally managed address scheme in 441 parallel. 443 4.2.2. The Base Addressing Scheme 445 The Base ULA addressing scheme for autonomic nodes has the following 446 format: 448 8 40 3 77 449 +--+--------------+------+------------------------------------------+ 450 |FD| hash(domain) | Type | (sub-scheme) | 451 +--+--------------+------+------------------------------------------+ 453 Figure 3: Base Addressing Scheme 455 The first 48 bits follow the ULA scheme, as defined in [RFC4193], to 456 which a type field is added: 458 o "FD" identifies a locally defined ULA address. 460 o The "global ID" is set here to be a hash of the domain name, which 461 results in a pseudo-random 40 bit value. It is calculated as the 462 first 40 bits of the MD5 hash of the domain name, in the example 463 "example.com". 465 o Type: Set to 000 (3 zero bits). This field allows different 466 address sub-schemes in the future. The goal is to start with a 467 minimal number of sub-scheme initially, but to allow for 468 extensions later if and when required. This addresses the 469 "upgradability" requirement. Assignment of types for this field 470 should be maintained by IANA. 472 4.2.3. Possible Sub-Schemes 474 The sub-schemes listed here are not intended to be all supported 475 initially, but are listed for discussion. The final document should 476 define ideally only a single sub-scheme for now, and leave the other 477 "types" for later assignment. 479 4.2.3.1. Sub-Scheme 1 481 51 13 64 482 +------------------------+---------+--------------------------------+ 483 | (base scheme) | Zone ID | Device ID | 484 +------------------------+---------+--------------------------------+ 486 Figure 4: Addressing Scheme 1 488 The fields are defined as follows: [Editor's note: The lengths of the 489 fields is for discussion.] 491 o Zone ID: If set to all zero bits: Flat addressing scheme. Any 492 other value indicates a zone. See section Section 4.2.4 on how 493 this field is used in detail. 495 o Device ID: A unique value for each device, typically assigned by a 496 registrar. 498 The device ID is derived as follows: In an Autonomic Network, a 499 registrar is enrolling new devices. As part of the enrolment process 500 the registrar assigns a number to the device, which is unique for 501 this registrar, but not necessarily unique in the domain. The 64 bit 502 device ID is then composed as: 504 o 48 bit: Registrar ID, a number unique inside the domain that 505 identifies the registrar which assigned the name to the device. A 506 MAC address of the registrar can be used for this purpose. 508 o 16 bit: Device ID, a number which is unique for a given registrar, 509 to identify the device. This can be a sequentially assigned 510 number. 512 The "device ID" itself is unique in a domain (i.e., the Zone-ID is 513 not required for uniqueness). Therefore, a device can be addressed 514 either as part of a flat hierarchy (zone ID = 0), or with an 515 aggregation scheme (any other zone ID). An address with zone-ID 0 516 (zero) could be interpreted as an identifier, with another zone-ID as 517 a locator. 519 4.2.3.2. Sub-Scheme 2 521 51 13 64-V ? 522 +------------------------+---------+----------------------------+---+ 523 | (base scheme) | Zone ID | Device ID | V | 524 +------------------------+---------+----------------------------+---+ 526 Figure 5: Addressing Scheme 2 528 The fields are defined as follows: [Editor's note: The lengths of the 529 fields is for discussion.] 531 o Zone ID: As in sub-scheme 1. 533 o Device ID: As in sub-scheme 1. 535 o V: Virtualization bit(s): 1 or more bits that indicate a virtual 536 context on an autonomic node. 538 In addition the scheme 1 (Section 4.2.3.1), this scheme allows the 539 direct addressing of specific virtual containers / VMs on an 540 autonomic node. An increasing number of hardware platforms have a 541 distributed architecture, with a base OS for the node itself, and the 542 support for hardware blades with potentially different OSs. The VMs 543 on the blades could be considered as separate autonomic nodes, in 544 which case it would make sense to be able to address them directly. 545 Autonomic Service Agents (ASAs) could be instantiated in either the 546 base OS, or one of the VMs on a blade. This addressing scheme allows 547 for the easy separation of the hardware context. 549 The location of the V bit(s) at the end of the address allows to 550 announce a single prefix for each autonomic node, while having 551 separate virtual contexts addressable directly. 553 4.2.4. Address Hierarchy 555 The "zone ID" allows for the definition of a simple address 556 hierarchy. If set to zero, the address scheme is flat. In this 557 case, the addresses primarily act as identifiers for the nodes. Used 558 like this, aggregation is not possible. 560 If aggregation is required, the 13 bit value allows for up to 8191 561 zones. (Theoretically, the 13 bits for the zone ID would allow also 562 for two levels of zones, introducing a sub-hierarchy. We do not 563 think this is required at this point, but a new type could be used in 564 the future to support such a scheme.) 565 Another way to introduce hierarchy is to use sub-domains in the 566 naming scheme. The node names "node17.subdomainA.example.com" and 567 "node4.subdomainB.example.com" would automatically lead to different 568 ULA prefixes, which can be used to introduce a routing hierarchy in 569 the network, assuming that the subdomains are aligned with routing 570 areas. 572 4.3. Discovery 574 Traditionally, most of the information a node requires is provided 575 through configuration or northbound interfaces. An autonomic 576 function should rely on such northbound interfaces minimally or not 577 at all, and therefore it needs to discover peers and other resources 578 in the network. This section describes various discovery functions 579 in an autonomic network. 581 Discovering nodes and their properties and capabilities: A core 582 function to establish an autonomic domain is the mutual discovery of 583 autonomic nodes, primarily adjacent nodes and secondarily off-link 584 peers. This may in principle either leverage existing discovery 585 mechanisms, or use new mechanisms tailored to the autonomic context. 586 An important point is that discovery must work in a network with no 587 predefined topology, ideally no manual configuration of any kind, and 588 with nodes starting up from factory condition or after any form of 589 failure or sudden topology change. 591 Discovering services: Network services such as AAA should also be 592 discovered and not configured. Service discovery is required for 593 such tasks. An autonomic network can either leverage existing 594 service discovery functions, or use a new approach, or a mixture. 596 Thus the discovery mechanism could either be fully integrated with 597 autonomic signaling (next section) or could use an independent 598 discovery mechanism such as DNS Service Discovery or Service Location 599 Protocol. This choice could be made independently for each Autonomic 600 Service Agent, although the infrastructure might require some minimal 601 lowest common denominator (e.g., for discovering the security 602 bootstrap mechanism, or the source of intent distribution, 603 Section 4.5). 605 4.4. Signaling Between Autonomic Nodes 607 Autonomic nodes must communicate with each other, for example to 608 negotiate and/or synchronize technical objectives (i.e., network 609 parameters) of any kind and complexity. This requires some form of 610 signaling between autonomic nodes. Autonomic nodes implementing a 611 specific use case might choose their own signaling protocol, as long 612 as it fits the overall security model. However, in the general case, 613 any pair of autonomic nodes might need to communicate, so there needs 614 to be a generic protocol for this. A prerequisite for this is that 615 autonomic nodes can discover each other without any preconfiguration, 616 as mentioned above. To be generic, discovery and signaling must be 617 able to handle any sort of technical objective, including ones that 618 require complex data structures. The document "A Generic Discovery 619 and Negotiation Protocol for Autonomic Networking" 620 [I-D.carpenter-anima-gdn-protocol] describes more detailed 621 requirements for discovery, negotiation and synchronization in an 622 autonomic network. It also defines a protocol, GDNP, for this 623 purpose, including an integrated but optional discovery protocol. 625 4.5. Intent Distribution 627 Intent is the policy language of an Autonomic Network; see 628 Section 7.2 for general information on Intent. The distribution of 629 Intent is also a function of the Autonomic Control Plane. It is 630 expected that Intent will be expressed as quite complex human- 631 readable data structures, and the distribution mechanism must be able 632 to support that. Some Intent items will need to be flooded to most 633 or all nodes, and other items of Intent may only be needed by a few 634 nodes. Various methods could be used to distribute Intent across an 635 autonomic domain. One approach is to treat it like any other 636 technical objective needing to be synchronized across a set of nodes. 637 In that case the autonomic signaling protocol could be used (previous 638 section). 640 4.6. Routing 642 All autonomic nodes in a domain must be able to communicate with each 643 other, and with autonomic nodes outside their own domain. Therefore, 644 an Autonomic Control Plane relies on a routing function. For 645 Autonomic Networks to be interoperable, they must all support one 646 common routing protocol. 648 4.7. The Autonomic Control Plane 650 The totality of autonomic interactions forms the "Autonomic Control 651 Plane". This control plane can be either implemented in the global 652 routing table of a node, such as IGPs in today's networks; or it can 653 be provided as an overlay network. The document "An Autonomic 654 Control Plane" ([I-D.behringer-anima-autonomic-control-plane]) 655 describes the details. 657 5. Security and Trust Infrastructure 659 An Autonomic Network is self-protecting. All protocols are secure by 660 default, without the requirement for the administrator to explicitly 661 configure security. 663 Autonomic nodes have direct interactions between themselves, which 664 must be secured. Since an autonomic network does not rely on 665 configuration, it is not an option to configure for example pre- 666 shared keys. A trust infrastructure such as a PKI infrastructure 667 must be in place. This section describes the principles of this 668 trust infrastructure. 670 A completely autonomic way to automatically and securely deploy such 671 a trust infrastructure is to set up a trust anchor for the domain, 672 and then use an approach as in the document "Bootstrapping Key 673 Infrastructures" [I-D.pritikin-bootstrapping-keyinfrastructures]. 675 5.1. Public Key Infrastructure 677 An autonomic domain uses a PKI model. The root of trust is a 678 certification authority (CA). A registrar acts as a registration 679 authority (RA). 681 A minimum implementation of an autonomic domain contains one CA, one 682 Registrar, and network elements. 684 5.2. Domain Certificate 686 We need to define how the fields in a domain certificate are to be 687 used. [tbc] 689 5.3. The MASA 691 Explain briefly the function, point to 692 [I-D.pritikin-bootstrapping-keyinfrastructures]. [tbc] 694 5.4. Sub-Domains (*) 696 Explain how sub-domains are handled. (tbc) 698 5.5. Cross-Domain Functionality (*) 700 Explain how trust is handled between different domains. (tbc) 702 6. Autonomic Service Agents (ASA) 704 This section describes how autonomic services run on top of the 705 Autonomic Networking Infrastructure. 707 6.1. General Description of an ASA 709 general concepts, such as sitting on top of the ANI, etc. Also needs 710 to explain that on a constrained node (see Section 3.3) not all ASAs 711 may run, so we have two classes of ASAs: Ones that run on an 712 unconstrained node, and limited function ASAs that run also on 713 constrained nodes. We expect unconstrained nodes to support all 714 ASAs. 716 6.2. Specific ASAs for the Enrolment Process 718 The following ASAs provide essential, required functionality in an 719 autonomic network, and are therefore mandatory to implement on 720 unconstrained autonomic nodes. 722 6.2.1. The Enrolment ASA 724 This section describes the function of an autonomic node to bootstrap 725 into the domain with the help of an enrolment proxy (see previous 726 section). [tbc] 728 6.2.2. The Enrolment Proxy ASA 730 This section describes the function of an autonomic node that helps a 731 non-enrolled, adjacent devices to enrol into the domain. [tbc] 733 6.2.3. The Registrar ASA 735 This section describes the registrar function in an autonomic 736 network. It explains the tasks of a registrar element, and how 737 registrars are placed in a network, redundancy between several, etc. 738 [tbc] 740 7. Management and Programmability 742 This section describes how an Autonomic Network is managed, and 743 programmed. 745 7.1. How an AN Network Is Managed 747 Autonomic management usually co-exists with traditional management 748 methods in most networks. Thus, autonomic behavior will be defined 749 for individual functions in most environments. In fact, the co- 750 existence is twofold: autonomic functions can use traditional methods 751 and protocols (e.g., SNMP and NETCONF) to perform management tasks; 752 and autonomic functions can conflict with behavior enforced by the 753 same traditional methods and protocols. 755 The autonomic intent is defined at a high level of abstraction. 756 However, since it is necessary to address individual managed 757 elements, autonomic management needs to communicate in lower-level 758 interactions (e.g., commands and requests). For example, it is 759 expected that the configuration of such elements be performed using 760 NETCONF and YANG modules as well as the monitoring be executed 761 through SNMP and MIBs. 763 Conflict can occur between autonomic default behavior, autonomic 764 intent, traditional management methods. Conflict resolution is 765 achieved in autonomic management through prioritization [RFC7575]. 766 The rationale is that manual and node-based management have a higher 767 priority over autonomic management. Thus, the autonomic default 768 behavior has the lowest priority, then comes the autonomic Intent 769 (medium priority), and, finally, the highest priority is taken by 770 node-specific network management methods, such as the use of command 771 line interfaces [RFC7575]. 773 7.2. Intent (*) 775 This section describes Intent, and how it is managed. Intent and 776 Policy-Based Network Management (PBNM) is already described inside 777 the IETF (e.g., PCIM and SUPA) and in other SDOs (e.g., DMTF and TMF 778 ZOOM). 780 Intent can be describe as an abstract, declarative, high-level policy 781 used to operate an autonomic domain, such as an enterprise network 782 [RFC7575]. Intent should be limited to high level guidance only, 783 thus it does not directly define a policy for every network element 784 separately. In an ideal autonomic domain, only one intent provided 785 by human administrators is necessary to operate such domain 786 [RFC7576]. However, it is als expected intent definition from 787 autonomic function(s) and even from traditional network management 788 elements (e.g., OSS). 790 Intent can be refined to lower level policies using different 791 approaches, such as Policy Continuum model [ref]. This is expected 792 in order to adapt the intent to the capabilities of managed devices. 793 In this context, intent may contain role or function information, 794 which can be translated to specific nodes [RFC7575]. One of the 795 possible refinements of the intent is the refinement to Event 796 Condition Action (ECA) rules. Such rules, which are more suitable to 797 individual entities, can be defined using different syntax and 798 semantics. 800 Different parameters may be configured for intents. These parameters 801 are usually provided by the human operator. Some of these parameters 802 can influence the behavior of specific autonomic functions as well as 803 the way the intent is used to manage the autonomic domain (towards 804 intended operational point). 806 Some examples of parameters for intents are: 808 o Model version: The version of the model used to define the intent. 810 o Domain: The network scope in which the intent has effect. 812 o Name: The name of the intent which describes the intent for human 813 operators. 815 o Version: The version of the intent, which is primarly used to 816 control intent updates. 818 o Signature: The signature is used as a security mechanism to 819 provide authentication, integrity, and non-repudiation. 821 o Timestamp: The timestamp of the creation of the intent using the 822 format supported by the IETF [TBC]. 824 o Lifetime: The lifetime in which the intent may be observed. A 825 special case of the lifetime is the definition of permanent 826 intents. 828 Intent distribution is considered as one of the common control and 829 management functions of an autonomic network [RFC7575]. Since 830 distribution is fundamental for autonomic networking, it is necessary 831 a mechanism to provision intent by all devices in a domain [draft- 832 carpenter-anima-gdn-protocol]. The distribution of Intent is 833 function of the Autonomic Control Plane and several methods can be 834 used to distribute Intent across an autonomic domain [draft- 835 behringer-anima-reference-model]. Intent distribution might not use 836 the ANIMA signaling protocol itself [draft-carpenter-anima-gdn- 837 protocol], but there is a proposal to extend such protocol for intent 838 delivery [draft-liu-anima-intent-distribution]. 840 7.3. Aggregated Reporting (*) 842 Autonomic Network should minimize the need for human intervention. 843 In terms of how the network should behave, this is done through an 844 autonomic intent provided by the human administrator. In an 845 analogous manner, the reports which describe the operational status 846 of the network should aggregate the information produced in different 847 network elements in order to present the effectiveness of autonomic 848 intent enforcement. Therefore, reporting in an autonomic network 849 should happen on a network-wide basis [RFC7575]. The information 850 gathering and the reporting delivery should be done through the 851 autonomic control plane. 853 Several events can occur in an autonomic network in the same way they 854 can happen in a traditional network. These events can be produced 855 considering traditional network management protocols, such as SNMP 856 and syslog. However, when reporting to a human administrator, such 857 events should be aggregated in order to avoid advertisement about 858 individual managed elements. In this context, algorithms may be used 859 to determine what should be reported (e.g., filtering) and in which 860 way and how different events are related to each other. Besides 861 that, an event in an individual element can be compensated by changes 862 in other elements in order to maintain in a network-wide level which 863 is described in the autonomic intent. 865 Reporting in an autonomic network may be in the same abstraction 866 level of the intent. In this context, the visibility on current 867 operational status of an autonomic network can be used to switch to 868 different management modes. Despite the fact that autonomic 869 management should minimize the need for user intervention, possibly 870 there are some events that need to be addressed by human 871 administrator actions. An alternative to model this is the use of 872 exception-based management [RFC7575]. 874 7.4. Feedback Loops to NOC(*) 876 Feedback loops are required in an autonomic network to allow the 877 intervention of a human administrator or central control systems, 878 while maintaining a default behaviour. Through a feedback loop an 879 administrator can be prompted with a default action, and has the 880 possibility to acknowledge or override the proposed default action. 882 7.5. Control Loops (*) 884 Control loops provide a generic mechanism for self-adaptation. That 885 is, as user needs, business goals, and the ANI itself change, self- 886 adaptation enables the ANI to change the services and resources it 887 makes available to adapt to these changes. Self-adaptive systems 888 move decision-making from static, pre-defined commands to dynamic 889 processes computed at runtime. 891 Control loops operate to continuously capture data that enables the 892 understanding of the system, and then provide actions to move the 893 state of the system toward a common goal. 895 7.5.1. Types of Control (*) 897 There are two generic types of closed loop control. Feedback control 898 adjusts the control loop based on measuring the output of the system 899 being managed to generate an error signal (the deviation of the 900 current state vs. its desired state). Action is then taken to reduce 901 the deviation. 903 In contrast, feedforward control anticipates future effects on a 904 controlled variable by measuring other variables whose values may be 905 more timely, and adjusts the process based on those variables. In 906 this approach, control is not error-based, but rather, based on 907 knowledge. 909 Autonomic control loops MAY require both feedforward and feedback 910 control. 912 7.5.2. Types of Control Loops (*) 914 There are many different types of control loops. In autonomics, the 915 most commonly cited loop is called Monitor-Analyze-Plan-Execute (with 916 Knowledge), called MAPE-K [Kephart03]. However, MAPE-K has a number 917 of systemic problems, as described in [Strassner09]. Therefore, 918 other autonomic architectures, such as AutoI [autoi] and FOCALE 919 [Strassner07] and use control loops that evolved from the OODA 920 (Observe-Orient-Decide-Act) control loop [Boyd95]. The reason for 921 using this loop, and not the MAPE-K loop, is because the OODA loop 922 contains a critical step not contained in other loops: orientation. 923 Orientation determines how observations, decisions, and actions are 924 performed. 926 Figure 6 shows a simplified model of a control loop containing both 927 feedforward and feedback elements. 929 Input Variables 930 ----------+-------------------------+ 931 | | 932 | | 933 \ / \ / 934 +-----+------+ +----+----+ 935 Set Point --->| Controller |------------>| Process |--+---> Output 936 +-----+------+ Deltas of +---------+ | 937 ^ Control | 938 | Variable(s) | 939 | | 940 +---------------------------------+ 942 Figure 6: Control Loop with Feedforward and Feedback Elements 944 Note that Figure 6 is a STATIC model. Figure 7 is a dynamic version, 945 called a Model-Reference Adaptive Control Loop (MRACL). 947 Model +--------------+ 948 +-------+ Output | Adaptive |<----+ 949 +--->| Model |--------->| Algorithm(s) | | 950 | +-------+ +---+-----+----+ | 951 | Adjusted | ^ | 952 Input | Parameters | | | 953 --------+ +----------------+ | | 954 | | | | 955 | | +---------+ | 956 | \ / | | 957 | +-----+------+ | +---------+ | 958 +--->| Controller |-----+------>| Process |--+---> Output 959 +-----+------+ Deltas of +---------+ | 960 ^ Control | 961 | Variable(s) | 962 | | 963 +---------------------------------+ 965 Figure 7: A Model-Reference Adaptive Control Loop 967 More complex adaptive control loops have been defined; these will be 968 described in a future I-D, so that an appropriate gap analysis can be 969 defined to recommend an architectural approach for ANIMA. 971 7.5.3. Management of an Autonomic Control Loop (*) 973 Both standard and adaptive control loops (e.g., as represented in 974 Figures X and X1, respectively) enable intervention by a human 975 administrator or central control systems, if required. Interaction 976 mechanisms include changing the behaviour of one or more elements in 977 the control loop, as well as providing mechanisms to bypass parts of 978 the control loop (e.g., skip the "decide" phase and go directly to 979 the "action" phase of an OODA loop, as is done in FOCALE). This also 980 enables the default behaviour to be changed if necessary. 982 7.5.4. Elements of an Autonomic Control Loop (*) 984 An autonomic control loop MUST be able to perform the following 985 functions as part of its operation: 987 o Observe and collect data from the system being managed 989 o Orient these data, so that their meaning and significance can be 990 understood in proper context 992 o Analyze the collected data through filtering, correlation, and 993 other mechanisms to define a model of past and current states 995 o Plan different actions based on inferring trends, determining root 996 causes, and similar processes 998 o Decide which plan(s) to take 1000 o Execute the plan, and then repeat these steps 1002 In addition, an autonomic control loop SHOULD be able to execute one 1003 or more machine learning algorithms that can learn from and make 1004 predictions on monitored data. This enables more efficient 1005 adaptivity. Note that machine learning is build from a model of 1006 exemplar inputs in order to make decisions and predictions. 1007 Supporting algorithms, such as those for data mining and analytics, 1008 SHOULD also be supported. 1010 7.6. APIs (*) 1012 Most APIs are static, meaning that they are pre-defined and represent 1013 an invariant mechanism for operating with data. An Autonomic Network 1014 SHOULD be able to use dynamic APIs in addition to static APIs. APIs 1015 MUST be able to express and preserve semantics across different 1016 domains. 1018 7.6.1. Dynamic APIs (*) 1020 A dynamic API is one that retrieves data using a generic mechanism, 1021 and then enables the client to navigate the retrieved data and 1022 operate on it. Such APIs typically use introspection and/or 1023 reflection (the former enables software to examine the type and 1024 properties of an object at runtime, while the latter enables a 1025 program to manipulate the attributes, methods, and/or metadata of an 1026 object. 1028 7.6.2. APIs and Semantics(*) 1030 An API is NOT the same as an interface. 1032 An interface is a boundary across which different components of a 1033 system exchange information. An API is a set of software (including 1034 tools, protocols, and programs) for building software applications. 1035 An API defines a set of data structures, inputs, outputs, and 1036 operations that can be used by a programmer to build an application. 1038 An Autonomic API must pay particular attention to semantics. 1039 Previous designs have used the notion of a software contract to build 1040 high-quality APIs that are distributed and modular. A software 1041 contract [Meyer97] is based on the principle that a software- 1042 intensive system, such as an Autonomic Network, is a set of 1043 communicating components whose interaction is based on precisely- 1044 defined specification of the mutual obligations that interacting 1045 components must respect. For example, when a method executes, the 1046 following must hold: 1048 o pre-conditions must be satisfied before the method can start 1049 execution 1051 o post-conditions must be satisfied when the method has finished 1052 execution 1054 o invariant attributes must not change during the execution of the 1055 method 1057 7.6.3. API Considerations (*) 1059 APIs should perform one function well, not perform many different and 1060 unrelated functions. In software design, this is called the Single 1061 Responsibility Principle [srp] 1063 7.7. Data Model (*) 1065 The following definitions are taken from [supa-model]: 1067 An information model is a representation of concepts of interest to 1068 an environment in a form that is independent of data repository, data 1069 definition language, query language, implementation language, and 1070 protocol. In contrast, a data model is a representation of concepts 1071 of interest to an environment in a form that is dependent on data 1072 repository, data definition language, query language, implementation 1073 language, and protocol (typically, but not necessarily, all three). 1075 The utility of an information model is to define objects and their 1076 relationships in a technology-neutral manner. This forms a 1077 consensual vocabulary that the ANI and ASAs can use. A data model is 1078 then a technology-specific mapping of all or part of the information 1079 model to be used by all or part of the system. 1081 A system may have multiple data models. Operational Support Systems, 1082 for example, typically have multiple types of repositories, such as 1083 SQL and NoSQL, to take advantage of the different properties of each. 1084 If multiple data models are required by an Autonomic System, then an 1085 information model SHOULD be used to ensure that the concepts of each 1086 data model can be related to each other without technological bias. 1088 A data model is essential for certain types of functions, such as a 1089 MRACL. More generally, a data model can be used to define the 1090 objects, attributes, methods, and relationships of a software system 1091 (e.g., the ANI, an autonomic node, or an ASA). A data model can be 1092 used to help design an API, as well as any language used to interface 1093 to the Autonomic Network. 1095 8. Coordination Between Autonomic Functions (*) 1097 8.1. The Coordination Problem (*) 1099 Different autonomic functions may conflict in setting certain 1100 parameters. For example, an energy efficiency function may want to 1101 shut down a redundant link, while a load balancing function would not 1102 want that to happen. The administrator must be able to understand 1103 and resolve such interactions, to steer autonomic network performance 1104 to a given (intended) operational point. 1106 Several interaction types may exist among autonomic functions, for 1107 example: 1109 o Cooperation: An autonomic function can improve the behavior or 1110 performance of another autonomic function, such as a traffic 1111 forecasting function used by a traffic allocation function. 1113 o Dependency: An autonomic function cannot work without another one 1114 being present or accessible in the autonomic network. 1116 o Conflict: A metric value conflict is a conflict where one metric 1117 is influenced by parameters of different autonomic functions. A 1118 parameter value conflict is a conflict where one parameter is 1119 modified by different autonomic functions. 1121 Solving the coordination problem beyond one-by-one cases can rapidly 1122 become intractable for large networks. Specifying a common 1123 functional block on coordination is a first step to address the 1124 problem in a systemic way. The coordination life-cycle consists in 1125 three states: 1127 o At build-time, a "static interaction map" can be constructed on 1128 the relationship of functions and attributes. This map can be 1129 used to (pre-)define policies and priorities on identified 1130 conflicts. 1132 o At deploy-time, autonomic functions are not yet active/acting on 1133 the network. A "dynamic interaction map" is created for each 1134 instance of each autonomic functions and on a per resource basis, 1135 including the actions performed and their relationships. This map 1136 provides the basis to identify conflicts that will happen at run- 1137 time, categorize them and plan for the appropriate coordination 1138 strategies/mechanisms. 1140 o At run-time, when conflicts happen, arbitration is driven by the 1141 coordination strategies. Also new dependencies can be observed 1142 and inferred, resulting in an update of the dynamic interaction 1143 map and adaptation of the coordination strategies and mechanisms. 1145 Multiple coordination strategies and mechanisms exists and can be 1146 devised. The set ranges from basic approaches such as random process 1147 or token-based process, to approaches based on time separation and 1148 hierarchical optimization, to more complex approaches such as multi- 1149 objective optimization, and other control theory approaches and 1150 algorithms family. 1152 8.2. A Coordination Functional Block (*) 1154 A common coordination functional block is a desirable component of 1155 the ANIMA reference model. It provides a means to ensure network 1156 properties and predictable performance or behavior such as stability, 1157 and convergence, in the presence of several interacting autonomic 1158 functions. 1160 A common coordination function requires: 1162 o A common description of autonomic functions, their attributes and 1163 life-cycle. 1165 o A common representation of information and knowledge (e.g., 1166 interaction maps). 1168 o A common "control/command" interface between the coordination 1169 "agent" and the autonomic functions. 1171 Guidelines, recommendations or BCPs can also be provided for aspects 1172 pertaining to the coordination strategies and mechanisms. 1174 9. Security Considerations 1176 9.1. Threat Analysis 1178 This is a preliminary outline of a threat analysis, to be expanded 1179 and made more specific as the various Autonomic Networking 1180 specifications evolve. 1182 Since AN will hand over responsibility for network configuration from 1183 humans or centrally established management systems to fully 1184 distributed devices, the threat environment is also fully 1185 distributed. On the one hand, that means there is no single point of 1186 failure to act as an attractive target for bad actors. On the other 1187 hand, it means that potentially a single misbehaving autonomic device 1188 could launch a widespread attack, by misusing the distributed AN 1189 mechanisms. For example, a resource exhaustion attack could be 1190 launched by a single device requesting large amounts of that resource 1191 from all its peers, on behalf of a non-existent traffic load. 1192 Alternatively it could simply send false information to its peers, 1193 for example by announcing resource exhaustion when this was not the 1194 case. If security properties are managed autonomically, a 1195 misbehaving device could attempt a distributed attack by requesting 1196 all its peers to reduce security protections in some way. In 1197 general, since autonomic devices run without supervision, almost any 1198 kind of undesirable management action could in theory be attempted by 1199 a misbehaving device. 1201 If it is possible for an unauthorised device to act as an autonomic 1202 device, or for a malicious third party to inject messages appearing 1203 to come from an autonomic device, all these same risks would apply. 1205 If AN messages can be observed by a third party, they might reveal 1206 valuable information about network configuration, security 1207 precautions in use, individual users, and their traffic patterns. If 1208 encrypted, AN messages might still reveal some information via 1209 traffic analysis, but this would be quite limited (for example, this 1210 would be highly unlikely to reveal any specific information about 1211 user traffic). AN messages are liable to be exposed to third parties 1212 on any unprotected Layer 2 link, and to insider attacks even on 1213 protected Layer 2 links. 1215 10. IANA Considerations 1217 This document requests no action by IANA. 1219 11. Acknowledgements 1221 Many people have provided feedback and input to this document: Sheng 1222 Jiang, Roberta Maglione, Jonathan Hansford. 1224 12. References 1226 [I-D.behringer-anima-autonomic-addressing] 1227 Behringer, M., "An Autonomic IPv6 Addressing Scheme", 1228 draft-behringer-anima-autonomic-addressing-01 (work in 1229 progress), June 2015. 1231 [I-D.behringer-anima-autonomic-control-plane] 1232 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 1233 Autonomic Control Plane", draft-behringer-anima-autonomic- 1234 control-plane-02 (work in progress), March 2015. 1236 [I-D.carpenter-anima-gdn-protocol] 1237 Carpenter, B. and B. Liu, "A Generic Discovery and 1238 Negotiation Protocol for Autonomic Networking", draft- 1239 carpenter-anima-gdn-protocol-04 (work in progress), June 1240 2015. 1242 [I-D.irtf-nmrg-autonomic-network-definitions] 1243 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1244 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1245 Networking - Definitions and Design Goals", draft-irtf- 1246 nmrg-autonomic-network-definitions-07 (work in progress), 1247 March 2015. 1249 [I-D.jiang-auto-addr-management] 1250 Jiang, S., Carpenter, B., and Q. Qiong, "Autonomic 1251 Networking Use Case for Auto Address Management", draft- 1252 jiang-auto-addr-management-00 (work in progress), April 1253 2014. 1255 [I-D.pritikin-bootstrapping-keyinfrastructures] 1256 Pritikin, M., Behringer, M., and S. Bjarnason, 1257 "Bootstrapping Key Infrastructures", draft-pritikin- 1258 bootstrapping-keyinfrastructures-01 (work in progress), 1259 September 2014. 1261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1262 Requirement Levels", BCP 14, RFC 2119, March 1997. 1264 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1265 Addresses", RFC 4193, October 2005. 1267 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1268 Addressing inside an IPv6 Network", RFC 7404, November 1269 2014. 1271 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1272 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1273 Networking: Definitions and Design Goals", RFC 7575, June 1274 2015. 1276 Authors' Addresses 1278 Michael H. Behringer (editor) 1279 Cisco Systems 1280 Building D, 45 Allee des Ormes 1281 Mougins 06250 1282 France 1284 Email: mbehring@cisco.com 1286 Brian Carpenter 1287 Department of Computer Science 1288 University of Auckland 1289 PB 92019 1290 Auckland 1142 1291 New Zealand 1293 Email: brian.e.carpenter@gmail.com 1295 Toerless Eckert 1296 Cisco 1298 Email: eckert@cisco.com 1300 Laurent Ciavaglia 1301 Alcatel Lucent 1302 Route de Villejust 1303 Nozay 91620 1304 France 1306 Email: laurent.ciavaglia@alcatel-lucent.com 1307 Bing Liu 1308 Huawei Technologies 1309 Q14, Huawei Campus 1310 No.156 Beiqing Road 1311 Hai-Dian District, Beijing 100095 1312 P.R. China 1314 Email: leo.liubing@huawei.com 1316 Jeferson Campos Nobre 1317 Federal University of Rio Grande do Sul 1318 Av. Bento Goncalves, 9500 1319 Porto Alegre 91501-970 1320 Brazil 1322 Email: jcnobre@inf.ufrgs.br 1324 John Strassner 1325 Huawei Technologies 1326 2330 Central Expressway 1327 Santa Clara, CA 95050 1328 USA 1330 Email: john.sc.strassner@huawei.com