idnits 2.17.1 draft-liu-nmrg-networkless-roadmap-01.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 17, 2018) is 2010 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Note' is mentioned on line 182, but not defined == Unused Reference: 'I-D.ietf-anima-reference-model' is defined on line 514, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-16 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-08 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Liu 3 Internet-Draft Huawei Technologies 4 Intended status: Informational B. Carpenter 5 Expires: April 20, 2019 Univ. of Auckland 6 October 17, 2018 8 Roadmap to a Networkless World 9 draft-liu-nmrg-networkless-roadmap-01 11 Abstract 13 This document aims to illustrate possible approaches to make network 14 management and operations more autonomic in several aspects. The 15 ultimate goal is that the network could run all by itself, so that 16 users and administrators may feel that there is no network to take 17 care of at all (a.k.a. "Networkless"). The approaches are described 18 in a form of different levels (inspired by the Self-Driven Car 19 levels). The higher the level is, the more autonomic management 20 capabilities the network would have. 22 Although some specific technologies are categorized into different 23 levels, it is not the document's intent to rank them; rather, this 24 document is more about discussing the possible next stage and the 25 ultimate vision. Hopefully, this document could collect people's 26 consensus in the industry and provide guidance for future technology 27 developments. 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 https://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 April 20, 2019. 46 Copyright Notice 48 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Level-by-Level approach to Networkless . . . . . . . . . . . 3 65 2.1. Self-Organization Levels . . . . . . . . . . . . . . . . 3 66 2.2. Self-Configuration Levels . . . . . . . . . . . . . . . . 4 67 2.3. Self-Optimization and Levels . . . . . . . . . . . . . . 5 68 2.4. Self-Diagnostic Levels . . . . . . . . . . . . . . . . . 5 69 2.5. Self-Healing Levels . . . . . . . . . . . . . . . . . . . 6 70 3. Key Capablities to Achieve Networkless . . . . . . . . . . . 6 71 3.1. Network Perception . . . . . . . . . . . . . . . . . . . 6 72 3.2. Decision and Reasoning . . . . . . . . . . . . . . . . . 7 73 3.3. Operation Interface . . . . . . . . . . . . . . . . . . . 7 74 4. Possible next-step technologies . . . . . . . . . . . . . . . 8 75 4.1. Self-Organization . . . . . . . . . . . . . . . . . . . . 8 76 4.2. Self-Configuration . . . . . . . . . . . . . . . . . . . 9 77 4.3. Self-Optimization . . . . . . . . . . . . . . . . . . . . 11 78 4.4. Self-Diagnostic/Healing . . . . . . . . . . . . . . . . . 11 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 8. Informative References . . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 As the network is evolving rapidly, the system is becoming more and 88 more complex; thus managing a network is more and more challenging. 89 It has been a common feeling in the industry that the operational 90 expense of running networks is becoming a vital pain point. To 91 address the management complexity challenges, there are new 92 technologies emerging. For example, Autonomic Networking [RFC7575], 93 which is under standardization in IETF Anima working group [Anima], 94 is following an approach to allow the network elements do more 95 management related operations by themselves. SDN techniques have 96 significantly improved the efficiency of network service delivery in 97 some scenarios. Network function virtualization, network slicing, 98 and the related orchestration techniques are expected to do the same. 99 In future, the intent-based network concept, which focuses more on 100 the operational simplicity perspective, should allow users or 101 administrators to control the network system in a radically simple 102 way (that is, driven by abstract intent, rather than by detailed 103 configurations). 105 This document is not proposing a new technology, rather, it collects 106 available tecnologies and illustrates possible future technologies 107 and the final effect on network users or administrators. The 108 ultimate goal is that the network could run all by itself, so that 109 users oradministrators may feel like there no network to take care of 110 at all (a.k.a. "Networkless"). 112 In Section 2, network management is divided into several aspects for 113 discussion, from an administrator's perspective. In each aspect 114 there are automation and autonomicity levels to illustrate past 115 (Level 0), current state of art (Level 1) and possible future 116 technologies (Level 2-4). Section 3 focuses on some common and vital 117 capabilities the network system needs to have, in order to support 118 the goals described in Section 2. 120 2. Level-by-Level approach to Networkless 122 2.1. Self-Organization Levels 124 Self-organization represents the ability of network elements to 125 autonomically connect with each other, form domains, or even decide 126 the topology, hierarchy or architecture. 128 o Level 1: LAN auto-connection 130 - E.g. current Ethernets can connected with each other without 131 any configurations once the cables are connected. 133 o Level 2: IP auto-routing & NE auto-connection to NMS 135 - IGP and BGP protocols allow the routers to connect with each 136 other autonomically, assuming prefixes are assigned to links. 138 - NEs automatically get connected with the NMS, current solutions 139 includes DCN [Q: What is DCN?], Anima ACP 140 [I-D.ietf-anima-autonomic-control-plane] etc. [Q: Mention 141 Netconf "call home"?] 143 o Level 3: Network Areas Self-Division and Key NEs election 145 - E.g. IGP Area self-division; controller election 147 o Level 4: Network Architecture and NE roles Self-identification 149 - E.g. autonomically identify topology characteristics and divide 150 network layers; autonomically identify roles such as access 151 gateway, aggregation gateway, core gateway etc. 153 [Note] More detailed technical discussion regarding to Level-3 154 and Level-4 please refer to Section 4.1 . 156 o Level 5: Self-Construction of Network Topologies 158 - E.g. for wireless network or overlay virtual networks 160 2.2. Self-Configuration Levels 162 o Level 1: CLI 164 - remote log-in, do configs one by one 166 o Level 2: NE Configs Auto-delivery 168 - Administrators design detailed configurations of each NE, using 169 NMS/Controller automatically deliver the configurations 171 o Level 3/4: NE Configs Auto-Compiling 173 - Administrators design network architecture and solutions, the 174 network autonomically compiles detailed NE configurations 175 (centrally or in a distributed manner). 177 - All detailed configurations are created by software. 179 - More and more machine-native configurations rather than human 180 interfaces. 182 [Note] More detailed technical discussion please refer to 183 Section 4.2 . 185 o Level 5: Network Self-Orchestration 187 - Administrators/Apps only input highly abstracted service 188 requests (e.g., build a wireless backhaul network), then the 189 network would deduce all configurations. 191 2.3. Self-Optimization and Levels 193 This sub-section focuses on traffic forwarding performance of the 194 network, mainly include path selection and QoS related issues. 196 o Level 1: Static Traffic Engineering 198 o Level 2: Auto Traffic Load Balance 200 - Controller dynamically adjust paths to achieve balanced traffic 201 load and congestion, according to specific algorithms; 203 - NE can achieve port-based load balancing locally 205 o Level 3/4: Comprehensive SLA/QoS Self-Optimization 207 - The network autonomically optimizes delay, bandwidth etc. 208 according to Administrator's or App's requirements; 210 - The network autonomically achieves measurement according to the 211 optimization goal. 213 o Level 5: Autonomous Optimization 215 - The network generates optimization policies by itself, and 216 keeps the performance at the best level; 218 - Meanwhile, achieves balance between performance and cost. 220 2.4. Self-Diagnostic Levels 222 This sub-section focuses on network fault diagnostic. 224 o Level 1: NMS-assisted manual diagnostic 226 - Administrators use tools like ping/tracroute for mannual 227 diagnostics 229 o Level 2: Automatic Data Analysis 231 - Software collects data around the whole network, and use data 232 mining or machine learning and decision tree to aggregate 233 alarms and analyze the cause. 235 o Level 3/4: Precise Fault Location 237 - Precise alarms to report the exact fault events. 239 - Precise location to reveal the real root cause. 241 o Level 5: Fault Prediction 243 - Network uses current data (e.g. bit error rates, temperature 244 alarms) to predict failures. 246 2.5. Self-Healing Levels 248 o Level 1: NMS-assisted manual healing 250 - Administrators use NMS to manually recover the configurations 251 or do the adjustment. 253 o Level 2: Protocol-based Healing 255 - Fixed healing functions built into NEs, such as BFD, and FRR 256 etc. 258 o Level 3: Programmable Healing 260 - Administrators can set specific healing policies based on a set 261 of general and abstracted rules of dealing with fault. 263 - Automatic call-out of technician. 265 o Level 4/5: Fault Avoidance 267 - According to the prediction, avoid the fault by backup, adjust 268 traffic, early call-out of technician, etc. 270 3. Key Capablities to Achieve Networkless 272 3.1. Network Perception 274 o Level 1: NE-based Statistics and Probe 276 - E.g. NE port statistics; end to end probe. Based on known 277 fixed topology. 279 o Level 2: Network Visualization 281 - Telemetry, logs/event analysis etc. 283 - Display current toplogy. 285 o Level 3: Real-time Holographic Network Data 286 - Network Digital Twin; 288 - NE deeply sense local traffic and fault etc. 290 o Level 4: Network Modeling and Pattern Recognition 292 - Comprehensive modeling for complex network problems; 294 - Pattern recognition to identify current network status 296 o Level 5: Network Event/Traffic Trend Prediction 298 - Based on ML trained on past observation of similar networks. 300 3.2. Decision and Reasoning 302 o Level 1: Fixed Control Loops 304 - The control loop functions are embedded in specific protocols/ 305 modules, such as IGP, DHCP, Anima BRSKI 306 [I-D.ietf-anima-bootstrapping-keyinfra] , and Anima ACP 307 [I-D.ietf-anima-autonomic-control-plane] etc. 309 o Level 2: Programmable Control Loops 311 - Algorithms (in Controller or Autonomic Service Agent) for 312 specific functions and scenarios 314 - might embed some Machine Learning capabilities, or outsource ML 315 to a central resource. 317 o Level 3: Machine Learning [Q: Maybe this should be Level 2/3?] 319 - General control loops, driven by specific Intents (e.g. Intent 320 provides the Reward definition of the reinforcement learning) 322 o Level 4: Machine Inference [Q: Maybe this should be Level 4?] 324 - Configuration, optimization, diagnostic, healing policies 325 inference 327 o Level 5: (To be filled) 329 3.3. Operation Interface 331 o Level 1: CLI 332 - Manual management oriented interface; batch processing within a 333 machine (e.g. Shell) 335 o Level 2: NE-level Primitive API 337 - Controller oriented NE-level API containing detailed 338 configurations. (E.g. Openflow, Netconf/YANG) 340 o Level 3: NE-level Declarative API 342 - Orchestrator oriented NE-level declarative API 344 - Orchestrator doesn't need to care about detailed NE specific 345 configurations 347 o Level 4: Network-level Declarative API 349 - User/Administrator oriented declarative API, to make the 350 network be called as a service. 352 o Level 5: Machine-native Autonomous API 354 - The machines would autonomously construct the content of the 355 APIs to fulfill the need of collaboration between modules. 357 - This level would likely be based on ML trained on similar 358 networks with similar applications. 360 4. Possible next-step technologies 362 This section discusses some possible next-steps for the technologies 363 described in Section 2. Basically, the next-steps are Level-3 or 364 Level-4 for each aspect. 366 4.1. Self-Organization 368 Current technologies (such as the Level-2 Self-organization ) can 369 decently deal with the problem of how a device can get connected to 370 the NOC and then get managed. After that, it still relies on human 371 planning to properly configure the basic network connectivity, such 372 as IP addresses, IGP etc. (This part of basic configurations is 373 always called "underlay configurations" comparing to the overlay 374 services.) 376 Thus, to simplify human work, it is expected that the system can do 377 some "planning" work. Some critical aspects of network planning are 378 as following, which are pre-conditions for both underlay 379 configurations and overlay configurations. 381 - Routing domain division: the system can divide the devices into 382 groups, according to some mechanisms. 384 - Network hierarchy recognition: the system can learn there is 385 hierarchy in the network; and it can even recognize which are 386 higher hierarchy and which are lower. 388 - Roles recognition: some device roles are directly related to the 389 topology, such as access gateway, aggregation gateway, core 390 gateway. 392 If the system can figure out the above things, then it would be much 393 easier to create the specific configurations. The IP addresses could 394 be assigned in a good order (e.g. from higher hierarchy to lower, 395 keep the addresses in a certain prefix for a specific domain); the 396 IGP could be inheritably configured according to the routing domain 397 divisions. 399 4.2. Self-Configuration 401 This section is mostly regarding service configurations (e.g. VPN 402 configurations). 404 The following figure shows a typical architecture of how current 405 state-of-the-art technologies do configurations for services. 407 (preamble) 409 l3vpn-svc | 410 Model | 411 | 412 +------------------+ +-----+ 413 | Orchestration | < --- > | OSS | 414 +------------------+ +-----+ 415 | | 416 +----------------+ | 417 | Config manager | | 418 +----------------+ | 419 | | 420 | NETCONF/CLI ... 421 | | 422 +------------------------------------------------+ 423 Network 425 +++++++ 426 + AAA + 427 +++++++ 429 ++++++++ Bearer ++++++++ ++++++++ ++++++++ 430 + CE A + ----------- + PE A + + PE B + ---- + CE B + 431 ++++++++ Connection ++++++++ ++++++++ ++++++++ 433 Site A Site B 435 Figure 1: L3VPN Service Configuration Architecture (from RFC8299) 437 For this approach, there are several issues: 439 1. Too much details in currently defined service models, which 440 implies 442 - Cost a lot of human labor 444 - The more details, the harder to achieve a unified and correct 445 model 447 2. Orchestrator/Controller is hard to scale 449 - Binding to specific service and underlay models; need to 450 develop new instance when service/underlay varies 452 - Need to compile each single model in each device 454 3. Southbound data models are hard to be unified 455 - Each vendor's capabilities are different 457 - Each operator's needs are different 459 - A long-term puzzle from the SNMP era, not fixed by Netconf/ 460 YANG 462 To address Issue-1, we'll need some easy expression of the network 463 service, this surely fits into the Intent-based network field. 464 (TBD.) 466 To address Issue-2 we might need a intermediate common layer to 467 separate the binding between specific service-level models and 468 device-level configurations. (TBD.) 470 4.3. Self-Optimization 472 TBD. 474 4.4. Self-Diagnostic/Healing 476 TBD. 478 5. Security Considerations 480 Security mechanisms such as firewall placement, firewall or route 481 filtering rules, authorization to join the network, key distribution, 482 VPN encryption policy etc. are potentially subject to all of the 483 above. However, raising security management to Levels 3 or 4 484 requires great confidence that the autonomic mechanisms are 485 themselves foolproof. It is to be expected that security management 486 remains at Level 0, 1 or 2 longer than most other aspects. An 487 exception is threat or DoS detection, where ML techniques should be 488 applicable in the short term. 490 6. IANA Considerations 492 No IANA assignment is needed. 494 7. Acknowledgements 496 The initial idea of this work and the "networkless" concept were from 497 Xiaofei Xu. 499 8. Informative References 501 [Anima] "https://datatracker.ietf.org/wg/anima/about/". 503 [I-D.ietf-anima-autonomic-control-plane] 504 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 505 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 506 plane-18 (work in progress), August 2018. 508 [I-D.ietf-anima-bootstrapping-keyinfra] 509 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 510 S., and K. Watsen, "Bootstrapping Remote Secure Key 511 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 512 keyinfra-16 (work in progress), June 2018. 514 [I-D.ietf-anima-reference-model] 515 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 516 and J. Nobre, "A Reference Model for Autonomic 517 Networking", draft-ietf-anima-reference-model-08 (work in 518 progress), October 2018. 520 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 521 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 522 Networking: Definitions and Design Goals", RFC 7575, 523 DOI 10.17487/RFC7575, June 2015, 524 . 526 Authors' Addresses 528 Bing Liu 529 Huawei Technologies 530 Q14, Huawei Campus 531 No.156 Beiqing Road 532 Hai-Dian District, Beijing 100095 533 P.R. China 535 Email: leo.liubing@huawei.com 537 Brian Carpenter 538 Department of Computer Science 539 University of Auckland 540 PB 92019 541 Auckland 1142 542 New Zealand 544 Email: brian.e.carpenter@gmail.com