idnits 2.17.1 draft-irtf-nmrg-an-gap-analysis-02.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 2, 2014) is 3487 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-03 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Management Research Group S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Informational B. Carpenter 5 Expires: April 5, 2015 Univ. of Auckland 6 M. Behringer 7 Cisco Systems 8 October 2, 2014 10 Gap Analysis for Autonomic Networking 11 draft-irtf-nmrg-an-gap-analysis-02 13 Abstract 15 This document provides a problem statement and gap analysis for an 16 IP-based autonomic network that is mainly based on distributed 17 network devices. The document provides a background by reviewing the 18 current status of autonomic aspects of IP networks and the extent to 19 which current network management depends on centralisation and human 20 administrators. Finally the document describes the general gaps 21 between current network abilities and the ideal autonomic network 22 concept. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 5, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Automatic and Autonomic Aspects of Current IP Networks . 3 62 3.1.1. IP Address Management and DNS . . . . . . . . . . . . 3 63 3.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.3. Configuration of Default Router in a Host . . . . . . 5 65 3.1.4. Hostname Lookup . . . . . . . . . . . . . . . . . . . 5 66 3.1.5. User Authentication and Accounting . . . . . . . . . 5 67 3.1.6. Security . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1.7. Synchronization . . . . . . . . . . . . . . . . . . . 6 69 3.1.8. Miscellaneous . . . . . . . . . . . . . . . . . . . . 7 70 3.2. Current Non-Autonomic Behaviors . . . . . . . . . . . . . 7 71 3.2.1. Network Establishment . . . . . . . . . . . . . . . . 7 72 3.2.2. Network Maintenance and Management . . . . . . . . . 8 73 3.2.3. Security Setup . . . . . . . . . . . . . . . . . . . 9 74 3.2.4. Troubleshooting and Recovery . . . . . . . . . . . . 9 75 4. Features Needed by Autonomic Networks . . . . . . . . . . . . 10 76 4.1. More Coordination among Devices or Network Partitions . . 10 77 4.2. Reusable Common Components . . . . . . . . . . . . . . . 11 78 4.3. Secure Control Plane . . . . . . . . . . . . . . . . . . 11 79 4.4. Less Configuration . . . . . . . . . . . . . . . . . . . 12 80 4.5. Forecasting and Dry Runs . . . . . . . . . . . . . . . . 12 81 4.6. Benefit from Knowledge . . . . . . . . . . . . . . . . . 13 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 85 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 86 9. Informative References . . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 The general goals and relevant definitions for autonomic networking 92 are discussed in [I-D.irtf-nmrg-autonomic-network-definitions]. In 93 summary, the fundamental goal of an autonomic network is self- 94 management, including self-configuration, self-optimization, self- 95 healing and self-protection. Whereas interior gateway routing 96 protocols such as OSPF and IS-IS largely exhibit these properties, 97 most other aspects of networking require top-down configuration, 98 often involving human administrators and a considerable degree of 99 centralisation. In essence Autonomic Networking is putting all 100 network configurations onto the same footing as routing, limiting 101 manual or database-driven configuration to an essential minimum. It 102 should be noted that this is highly unlikely to eliminate the need 103 for human administrators, because many of their essential tasks will 104 remain. The idea is to eliminate tedious and error-prone tasks, for 105 example manual calculations, cross-checking between two different 106 configuration files, or tedious data entry. Higher level operational 107 tasks, and complex trouble-shooting, will remain to be done by 108 humans. 110 This document first provides background by identifying examples of 111 partial autonomic behavior in the Internet, and by describing 112 important areas of non-autonomic behavior. Based on these 113 observations, it then describes missing general mechanisms which 114 would allow autonomic behaviours to be added throughout the Internet. 116 2. Terminology 118 The terminology defined in 119 [I-D.irtf-nmrg-autonomic-network-definitions] is used in this 120 document. 122 3. Background 124 3.1. Automatic and Autonomic Aspects of Current IP Networks 126 This section discusses the history and current status of automatic or 127 autonomic operations in various aspects of network configuration, in 128 order to establish a baseline for the gap analysis. In particular, 129 routing protocols already contain elements of autonomic processes, 130 such as information exchange and state synchronization. 132 3.1.1. IP Address Management and DNS 134 Originally there was no alternative to completely manual and static 135 management of IP addresses. Once a site had received an IPv4 address 136 assignment (usually a Class C /24 or Class B /16, and rarely a Class 137 A /8) it was a matter of paper-and-pencil design of the subnet plan 138 (if relevant) and the addressing plan itself. Subnet prefixes were 139 manually configured into routers, and /32 addresses were assigned 140 administratively to individual host computers, and configured 141 manually by system administrators. Records were typically kept in a 142 plain text file or a simple spreadsheet. 144 Clearly this method was clumsy and error-prone as soon as a site had 145 more than a few tens of hosts, but it had to be used until DHCP 146 [RFC2131] became a viable solution during the second half of the 147 1990s. DHCP made it possible to avoid manual configuration of 148 individual hosts (except, in many deployments, for a small number of 149 servers configured with static addresses). 151 In terms of management, it is difficult to separate IP address 152 management from DNS management. At roughly the same time as DHCP 153 came into widespread use, it became very laborious to manually 154 maintain DNS source files in step with IP address assignments. 155 Because of reverse DNS lookup, it also became necessary to synthesise 156 DNS names even for hosts that only played the role of clients. 157 Therefore, it became necessary to synchronise DHCP server tables with 158 forward and reverse DNS. For this reason, Internet Protocol address 159 management tools emerged. These are, however, a centralised and far 160 from autonomic type of solution. 162 A related issue is prefix delegation, especially in IPv6 when more 163 than one prefix may be delegated to the same physical subnet. DHCPv6 164 Prefix Delegation [RFC3633] is a useful solution, but how this topic 165 is to be handled in home networks is still an open question. Still 166 further away is automated assignment and delegation of IPv4 subnet 167 prefixes. 169 Another complication is the possibility of Dynamic DNS Update 170 [RFC2136]. With appropriate security, this is an autonomic approach, 171 where no human intervention is required to create the DNS records for 172 a host. Also, there are coexistence issues with a traditional DNS 173 setup. 175 3.1.2. Routing 177 Since a very early stage, it has been a goal that Internet routing 178 should be self-healing when there is a failure of some kind in the 179 routing system (i.e. a link or a router goes wrong). Also, the 180 problem of finding optimal routes through a network was identified 181 many years ago as a problem in mathematical graph theory, for which 182 well known algorithms were discovered (the Dijkstra and Bellman-Ford 183 algorithms). Thus routing protocols became largely autonomic in the 184 1980s, as soon as the network was large enough for manual 185 configuration of routing tables to become difficult. 187 IGP routers do need some initial configuration data to start up the 188 autonomic routing protocol. Also, BGP-4 routers need detailed static 189 configuration of routing policy data. 191 3.1.3. Configuration of Default Router in a Host 193 Originally this was a manual operation. Since the deployment of 194 DHCP, this has been automatic as far as most IPv4 hosts are 195 concerned, but the DHCP server must be appropriately configured. In 196 simple environments such as a home network, the DHCP server resides 197 in the same box as the default router, so this configuration is also 198 automatic. In more complex environments, where an independent DHCP 199 server or a local DHCP relay is used, DHCP configuration is more 200 complex and not automatic. 202 In IPv6 networks, the default router is provided by Router 203 Advertisement messages [RFC4861] from the router itself, and all IPv6 204 hosts make use of it. The router may also provide more complex Route 205 Information Options. The process is essentially autonomic as far as 206 all IPv6 hosts are concerned, and DHCPv6 is not involved. However, 207 there are still open issues when more than one prefix is in use on a 208 subnet and more than one first-hop router may be available as a 209 result. 211 3.1.4. Hostname Lookup 213 Originally host names were looked up in a static table, often 214 referred to as /etc/hosts from its traditional file path in Unix 215 systems. When the DNS was deployed during the 1980s, all hosts 216 needed DNS resolver code, and needed to be configured with the IP 217 addresses (not the names) of suitable DNS servers. Like the default 218 router, these were originally manually configured. Today, they are 219 provided automatically via DHCP or DHCPv6 [RFC3315]. For IPv6 end 220 systems, there is also a way for them to be provided automatically 221 via a Router Advertisement option. However, the DHCP or DHCPv6 222 server, or the IPv6 router, need to be configured with the 223 appropriate DNS server addresses. 225 3.1.5. User Authentication and Accounting 227 Originally, user authentication and accounting was mainly based on 228 physical connectivity and the degree of trust that follows from 229 direct connectivity. Network operators charged based on the set up 230 of dedicated physical links with users. Automated user 231 authentication was introduced by Point-to-Point Protocol [RFC1661], 232 [RFC1994] and RADIUS protocol [RFC2865], [RFC2866] in early 1990s. 233 As long as a user completes online authentication through the RADIUS 234 protocol, the accounting for that user starts on the corresponding 235 AAA server automatically. This mechanism enables business models 236 with charging based on traffic based or time based usage. However, 237 the management of user authentication information remains manual by 238 network administrators. It also becomes complex in the case of 239 mobile users who roam between operators, since prior relationships 240 between the operators are needed. 242 3.1.6. Security 244 Security has many aspects that need configuration and are therefore 245 candidates to become autonomic. On the other hand, it is essential 246 that a network's central policy should be applied strictly for all 247 security configurations. As a result security has largely been based 248 on centrally imposed configurations. 250 Many aspects of security depend on policy, for example firewall 251 policies. Policies are by definition human made and will therefore 252 also persist in an autonomic environment. However, policies are 253 becoming more high-level, abstracting for example addressing, and 254 focusing on the user or application. The methods to manage, 255 distribute and apply policy, and to monitor compliance and violations 256 could be autonomic. 258 Today, many security mechanisms show some autonomic properties. For 259 example user authentication via 802.1x allows automatic mapping of 260 users after authentication into logical contexts (typically VLANs). 261 While today configuration is still very important, the overall 262 mechanism displays signs of self-adaption to changing situations. 264 BGP Flowspec [RFC5575] allows a partially autonomic threat defense 265 mechanism, where threats are identified, the flow information is 266 automatically distributed, and counter-actions can be applied. Today 267 typically a human operator is still in the loop to check correctness, 268 but over time such mechanisms can become more autonomic. 270 Negotiation capabilities, present in many security protocols, also 271 display simple autonomic behaviours. In this case a security policy 272 about algorithm strength can be configured into servers but will 273 propagate automatically to clients. 275 3.1.7. Synchronization 277 Another area where autonomic processes between peers are involved is 278 state synchronization. In this case, several devices start out with 279 inconsistent state and go through a peer-to-peer procedure after 280 which their states are consistent. Network time synchronisation 281 [RFC5905] is a well-established example, guaranteeing that a 282 participating node's clock state is synchronized with reliable time 283 servers within a defined margin of error, without any overall 284 controller being involved. 286 3.1.8. Miscellaneous 288 There are innumerable other properties of network devices and end 289 systems that today need to be configured either manually or using a 290 management protocol such as SNMP [RFC1157] or NETCONF [RFC6241]. In 291 a truly autonomic network, all of these, without exception, would 292 need to either have satisfactory default values or be configured 293 automatically. Some examples are parameters for tunnels of various 294 kinds, flows (in an SDN context), quality of service, service 295 function chaining, energy management, system identification and NTP 296 configuration. 298 3.2. Current Non-Autonomic Behaviors 300 In current networks, many operations are still heavily dependent on 301 human intelligence and decision, or on centralised top-down network 302 management systems. These operations are the targets of Autonomic 303 Network technologies. The ultimate goal of an Autonomic Network is 304 to replace human and automated operations by autonomic functions, so 305 that the networks can run independently without depending on a human 306 or NMS system for routine details, while maintaining central control 307 where required. Of course, there would still be the absolute minimum 308 of human input required, particularly during the network 309 establishment stage, and during emergencies and difficult trouble- 310 shooting. 312 This section analyzes the existing human and central dependencies in 313 typical current networks and suggests cases where they could in 314 principle be replaced by autonomic behaviors. 316 3.2.1. Network Establishment 318 Network establishment requires network operators to analyze the 319 requirements of the new network, design a network architecture and 320 topology, decide device locations and capacities, set up hardware, 321 design network services, choose and enable required protocols, 322 configure each device and each protocol, set up central user 323 authentication and accounting policies and databases, design and 324 deploy security mechanisms, etc. 326 Overall, these jobs are quite complex work that cannot become fully 327 autonomic in the foreseeable future. However, part of these jobs may 328 be able to become autonomic, such as detailed device and protocol 329 configurations and database population. The initial network 330 management policies/behaviors may also be transplanted from other 331 networks and automatically localized. 333 3.2.2. Network Maintenance and Management 335 Network maintenance and management are very different for ISP 336 networks and enterprise networks. ISP networks have to change much 337 more frequently than enterprise networks, given the fact that ISP 338 networks have to serve a large number of customers who have very 339 diversified requirements. The current rigid model is that network 340 administrators design a limited number of services for customers to 341 order. New requirements of network services may not be able to be 342 met quickly by human management. Given a real-time request, the 343 response must be autonomic, in order to be flexible and quickly 344 deployed. However, behind the interface, describing abstracted 345 network information and user authorization management may have to 346 depend on human intelligence from network administrators in the 347 foreseeable future. User identification integration/consolidation 348 among networks or network services is another challenge for autonomic 349 network access. Currently, many end users have to manually manage 350 their user accounts and authentication information when they switch 351 among networks or network services. 353 Classical network maintenance and management mainly manages the 354 configuration of network devices. Tools have been developed to 355 enable remote management and make such management easier. However, 356 the decision about each configuration detail depends either on human 357 intelligence or rigid templates. This is the source of most network 358 configuration errors. It is also a barrier to increasing the utility 359 of network resources, because the human managers cannot respond 360 quickly enough to network events, such as traffic bursts, etc. For 361 example, currently, a light load is normally assumed in network 362 design because there is no mechanism to properly handle a sudden 363 traffic flood. It is actually normal to avoid network crashes caused 364 by traffic overload by wasting a huge amount of resources. 366 It is worth noting that the introduction of new, more flexible, 367 methods of network configuratiom, typified by software-defined 368 networking (SDN), will only make this problem worse unless the 369 details are managed autonomically. 371 Autonomic decision processes for configuration would enable dynamic 372 management of network resources (by managing resource-relevant 373 configuration). Self-adapting network configuration would adjust the 374 network into the best possible situation, which also prevents 375 configuration errors from having lasting impact. 377 3.2.3. Security Setup 379 Setting up security for a network generally requires very detailed 380 human intervention, or relies entirely on default configurations that 381 may be too strict or too risky for the particular situation of the 382 network. While some aspects of security are intrinsically top-down 383 in nature (e.g. broadcasting a specific security policy to all 384 hosts), others could be self-managed within the network. 386 In an autonomic network, where nodes within a domain have a mutually 387 verifiable domain identity, security processes could run entirely 388 automatically. Nodes could identify each other securely, negotiating 389 required security settings and even shared keys if needed. The 390 location of trust anchors (certificate authority, registration 391 authority), certificate revocation lists, policy server, etc., can be 392 found by service discovery. Transactions such as a certificate 393 revocation list download can be authenticated via a common trust 394 anchor. Policy distribution can also be entirely automated, and 395 secured via a common trust anchor. 397 These concepts lead to a network where the intrinsic security is 398 automatic and applied by default, i.e., a "self-protecting" network. 399 For further discussion, see [I-D.behringer-default-secure] 401 3.2.4. Troubleshooting and Recovery 403 Current networks suffer difficulties in locating the cause of network 404 failures. Although network devices may issue many warnings while 405 running, most of them are not sufficiently precise to be identified 406 as errors. Some of them are early warnings that would not develop 407 into real errors. Others are in effect random noise. During a major 408 failure, many different devices will issue multiple warnings within a 409 short time, causing overload for the NMS and the operators. However, 410 for many scenarios, human experience is still vital to identify real 411 issues and locate them. This situation may be improved by 412 automatically associating warnings from multiple network devices 413 together. Also, introducing automated learning techniques (comparing 414 current warnings with historical relationships between warnings and 415 actual faults) could increase the possibility and success rate of 416 autonomic network diagnoses and troubleshooting. 418 Depending on the network errors, some of them may always require 419 human interventions, particularly for hardware failures. However, 420 autonomic network management behavior may help to reduce the impact 421 of errors, for example by switching traffic flows around. Today this 422 is usually manual (except for classical routing updates). Fixing 423 software failures and configuration errors currently depends on 424 humans, and may even involve rolling back software versions and 425 rebooting hardware. Such problems could be autonomically corrected 426 if there were diagnostics and recovery functions defined in advance 427 for them. This would fulfill the concept of self-healing. 429 Another possible autonomic function is predicting device failures or 430 overloads before they occur. A device could predict its own failure 431 and warn its neighbors; or a device could predict its neighbor's 432 failure. In either case, an autonomic network could respond as if 433 the failure had already occurred by routing around the problem and 434 reporting the failure, with no disturbance to users. The criteria 435 for predicting failure could be temperature, battery status, bit 436 error rates, etc. The criteria for predicting overload could be 437 increasing load factor, latency, jitter, congestion loss, etc. 439 4. Features Needed by Autonomic Networks 441 The task of autonomic networking is to build up individual autonomic 442 processes that could properly combine to respond to every type of 443 network event. Building on the preceding background information, and 444 on the reference model in 445 [I-D.irtf-nmrg-autonomic-network-definitions], this section will 446 outline the gaps and missing features in general terms, and in some 447 cases mentions general design principles that should apply. 449 4.1. More Coordination among Devices or Network Partitions 451 Network services are dependent on a number of devices and parameters 452 to be in place in a certain order. For example after a power failure 453 a coordinated sequence of "return to normal" operations is desirable 454 (e.g., switches and routers first, DNS servers second, etc.). Today, 455 the correct sequence of events is either known only by a human 456 administrator, or automated in a central script. In a truly 457 autonomic network, elements should understand their dependencies, and 458 be able to resolve them locally. 460 In order to make right or good decisions autonomically, the network 461 devices need to know more information than just reachability 462 (routing) information from the relevant or neighbor devices. There 463 are dependencies between such information and configurations, which 464 devices must be able to derive for themselves. 466 There are therefore increased requirements for horizontal information 467 exchange in the networks. Particularly, three types of interaction 468 among peer network devices are needed for autonomic decisions: 469 discovery (to find neighbours and peers), synchronization (to agree 470 on network status) and negotiation (when things need to be changed). 471 Although there are many existing protocols with some discovery, 472 syncronization or negotiation ability, each of them only serves a 473 specific and narrow purpose. To avoid continued proliferation of 474 such protocols, there is a need for reusable discovery, 475 synchronization and negotiation mechanisms, which would support the 476 discovery of many different types of device, the synchronization of 477 many types of parameter and the negotiation of many different types 478 of objective. 480 4.2. Reusable Common Components 482 Elements of autonomic functions already exist today, within many 483 different protocols. However, all such functions have their own 484 discovery, transport, messaging and security mechanisms as well as 485 non-autonomic management interfaces. Each protocol has its own 486 version of the above-mentioned functions to serve specific and narrow 487 purposes. It is often difficult to extend an existing protocol to 488 serve different purposes. Therefore, in order to provide the 489 reusable discovery, synchronization and negotiation mechanism 490 mentioned above, it is desirable to develop a set of reusable common 491 protocol components for Autonomic Networks. These components should 492 be: 494 o Able to identify other devices, users and processes securely. 496 o Able to automatically secure operations, based on the above 497 identity scheme. 499 o Able to manage any type of information and information flows. 501 o Able to discover peer devices and services for various autonomic 502 service agents (or autonomic functions). 504 o Able to support closed-loop operations when needed to provide 505 self-managing functions involving more than one device. 507 o Separable from the specific autonomic service agents (or autonomic 508 functions). 510 o Reusable by other autonomic functions. 512 4.3. Secure Control Plane 514 The common components will in effect act as a control plane for 515 autonomic operations, regardless whether they are implemented in-band 516 as functions of the target network, in an overlay network, or even 517 out-of-band in a separate network. Autonomic operations will be 518 capable of changing how the network operates and allocating resources 519 without human intervention or knowledge, so it is essential that they 520 are secure. Therefore the control plane must be fully secure against 521 forged autonomic operations and man-in-the middle attacks, and as 522 secure as reasonably possible against denial of service attacks. It 523 must be decided whether the control plane needs to be resistant to 524 unwanted monitoring, i.e., whether encryption is required. 526 4.4. Less Configuration 528 Most existing protocols have been defined to be as flexible as 529 possible. Consequently, these protocols need many initial 530 configurations to start operations. There are many choices and 531 options that are unnecessary in any particular case. A large portion 532 of these configurations target corner cases. Furthermore, in many 533 protocols that already exist for years, some design considerations 534 are no longer valid since the hardware technologies have made 535 dramatic progress in recent years. There is much scope for 536 simplifying the protocols and the operation of protocols. 538 From another perspective, the deep reason why human decisions are 539 often needed mainly result from the lack of information. When a 540 device can collect enough information horizontally from other 541 devices, it should be able to decide many parameters by itself, 542 instead of receiving them from top-down configuration. 544 It is desired that the top-down management is reduced in the 545 Autonomic Networking. Ideally, only the abstract intent is needed 546 from the human administrators. Neither users nor administrators 547 should need to create and maintain detailed policies and profiles; if 548 they are needed, they should be built autonomically. The local 549 parameters should be decided by distributed Autonomic Nodes 550 themselves, either from historic knowledge, analytics of current 551 conditions, closed logical decision loops, or a combination of all. 553 4.5. Forecasting and Dry Runs 555 In a conventional network, there is no mechanism for trying something 556 out. That means that configuration changes have to be designed in 557 the abstract and their probable effects have to be estimated 558 theoretically. The only alternative to this would be to test them on 559 a complete and realistic network simulator, which is unlikely to be 560 possible for a network of any size. In any case, there is a risk 561 that applying the changes to the running network will cause a failure 562 of some kind. An autonomic network should fill this gap by 563 supporting a "dry run" mode in which a configuration change could be 564 tested out in the control plane without actually affecting the data 565 plane. If the results are satisfactory, the change could be made 566 live; if there is a problem, the change could be rolled back with no 567 impact on users. 569 4.6. Benefit from Knowledge 571 The more knowledge we have, the more intelligent we are. It is the 572 same for networks and network management. It is when one component 573 in the network lacks knowledge that affects what it should do, and 574 another component has that knowledge, that we usually rely on a human 575 operator or a centralised management tool to convey the knowledge. 577 Up to now, the only available network knowledge is usually the 578 current network status inside a given device or relevant current 579 status from other devices. 581 However, historic knowledge is very helpful to make correct 582 decisions, in particular to reduce network oscillation or to manage 583 network resources over time. Transplantable knowledge from other 584 networks can be helpful to initially set up a new network or new 585 network devices. Knowledge of relationships between network events 586 and network configuration may help a network to decide the best 587 parameters according to real performance feedback. 589 In addition to such historic knowledge, powerful data analytics of 590 current network conditions may also be a valuable source of knowledge 591 that can be exploited directly by autonomic nodes. 593 5. Security Considerations 595 This document is focused on what is missing to allow autonomic 596 network configuration, including of course security settings. 597 Therefore, it does not itself create any new security issues. It is 598 worth underlining that autonomic technology must be designed with 599 strong security properties from the start, since a network with 600 vulnerable autonomic functions would be at great risk. 602 6. IANA Considerations 604 This memo includes no request to IANA. 606 7. Acknowledgements 608 The authors would like to acknowledge the valuable comments made by 609 participants in the IRTF Network Management Research Group. A review 610 by Rene Struik was especially helpful. 612 This document was produced using the xml2rfc tool [RFC2629]. 614 8. Change log [RFC Editor: Please remove] 616 draft-irtf-nmrg-an-gap-analysis-02: Review comments actioned, 617 2014-10-02. 619 draft-irtf-nmrg-an-gap-analysis-01: RG comments added and more 620 content in "Approach toward Autonomy" section, 2014-08-30. 622 draft-irtf-nmrg-an-gap-analysis-00: RG comments added, 2014-04-02. 624 draft-jiang-nmrg-an-gap-analysis-00: original version, 2014-02-14. 626 9. Informative References 628 [I-D.behringer-default-secure] 629 Behringer, M., Pritikin, M., and S. Bjarnason, "Making The 630 Internet Secure By Default", draft-behringer-default- 631 secure-00 (work in progress), January 2014. 633 [I-D.irtf-nmrg-autonomic-network-definitions] 634 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 635 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 636 Networking - Definitions and Design Goals", draft-irtf- 637 nmrg-autonomic-network-definitions-03 (work in progress), 638 August 2014. 640 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 641 "Simple Network Management Protocol (SNMP)", STD 15, RFC 642 1157, May 1990. 644 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 645 RFC 1661, July 1994. 647 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 648 Protocol (CHAP)", RFC 1994, August 1996. 650 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 651 2131, March 1997. 653 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 654 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 655 RFC 2136, April 1997. 657 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 658 June 1999. 660 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 661 "Remote Authentication Dial In User Service (RADIUS)", RFC 662 2865, June 2000. 664 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 666 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 667 and M. Carney, "Dynamic Host Configuration Protocol for 668 IPv6 (DHCPv6)", RFC 3315, July 2003. 670 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 671 Host Configuration Protocol (DHCP) version 6", RFC 3633, 672 December 2003. 674 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 675 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 676 September 2007. 678 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 679 and D. McPherson, "Dissemination of Flow Specification 680 Rules", RFC 5575, August 2009. 682 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 683 Time Protocol Version 4: Protocol and Algorithms 684 Specification", RFC 5905, June 2010. 686 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 687 Bierman, "Network Configuration Protocol (NETCONF)", RFC 688 6241, June 2011. 690 Authors' Addresses 692 Sheng Jiang 693 Huawei Technologies Co., Ltd 694 Q14, Huawei Campus, No.156 Beiqing Road 695 Hai-Dian District, Beijing, 100095 696 P.R. China 698 Email: jiangsheng@huawei.com 699 Brian Carpenter 700 Department of Computer Science 701 University of Auckland 702 PB 92019 703 Auckland 1142 704 New Zealand 706 Email: brian.e.carpenter@gmail.com 708 Michael H. Behringer 709 Cisco Systems 710 Building D, 45 Allee des Ormes 711 Mougins 06250 712 France 714 Email: mbehring@cisco.com