idnits 2.17.1 draft-moulchan-nmrg-network-intent-concepts-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 28, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force K. Sivakumar 3 Internet-Draft M. Chandramouli 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: May 1, 2018 October 28, 2017 7 Concepts of Network Intent 8 draft-moulchan-nmrg-network-intent-concepts-00 10 Abstract 12 This document presents an overview of the concepts of Network Intent 13 and provides definitions for some of the nomenclature. Some 14 potential use cases are presented. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 1, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 52 3. Hierarchy of Manageability . . . . . . . . . . . . . . . . . 4 53 4. Network Configuration . . . . . . . . . . . . . . . . . . . . 4 54 5. Network Policy . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Network Intent . . . . . . . . . . . . . . . . . . . . . . . 5 56 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 7.1. A simple example . . . . . . . . . . . . . . . . . . . . 7 58 7.2. Disaster Management . . . . . . . . . . . . . . . . . . . 7 59 8. Issues with Intent based networking . . . . . . . . . . . . . 8 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 11.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 Recently, there have been deployments of networks of Service 70 Provider, enterprise and data centres in a very large scale. From a 71 network management perspective, the manageability of networks of such 72 scale poses new challenges. The increasing complexity of network 73 configuration is an additional challenge for the network 74 administrators. To an extent, for device-level configurations, there 75 has been standardization efforts underway in technologies such as 76 YANG [RFC6020], and NETCONF [RFC6241]. However, the challenge still 77 remains at the network level configuration, orchestration and 78 management. The complexity of the network can lead to potential mis- 79 configurations and furthermore, it may be difficult to troubleshoot 80 the network failure conditions. 82 From a management perspective, it is of paramount importance for the 83 network administrator to reduce the complexity of the network 84 management. There are several measures and approaches that have been 85 under consideration towards that objective. One aspect that has 86 gained attention is Network Programmability APIs in the management 87 plane. Programmability allows the capabilities of network 88 functionality to be modified or extended. Programmability promises 89 to enable the development of a whole new wave of applications that 90 provide additional management intelligence. Programmability enables 91 the development of applications whose purpose is to make the networks 92 easier to manage, and those applications can be embedded and tightly 93 coupled with the network. The application developers can use the 94 Network Programmability APIs that can allow them to add new features 95 that can facilitate ease of network management, efficiency and the 96 effectiveness with which the network can be provisioned, 97 administrated and managed. Programmability, as provided through SDN, 98 provides exciting new opportunities to increase manageability by 99 facilitating the development of corresponding applications. Software 100 defined networking (SDN) is an umbrella term for a programmatic 101 approach to managing network devices, using software controls to 102 replace manual configuration. Initial motivations for SDN were to 103 overcome the the lack of network programmability, and manageability 104 in networks. 106 SDN technologies allow network-wide visibility and the possibility of 107 feedback actions across the network. The desire to implement higher 108 layers of management abstraction such as policy-based management, or 109 the desire to extend an application's capabilities with application- 110 specific pre-processing that can be delegated to the network. 112 Leveraging the Network Programmability APIs opens the possibility to 113 introduce an abstraction for the network, which can be used to 114 synthesise the overall system behaviour. In the networking parlance, 115 there have been several concepts that have been have been considered 116 to simplify the network management - Network Policy, Autonomic 117 Networking, Service Models, and Network Configuration. We introduce 118 the concept of Intent Based Networking, by which the network 119 administrator can articulate a desired outcome to the network. The 120 Network Intent is translated to appropriate network policies and/or 121 network configurations. With this approach to Network Intent, the 122 focus is more on "what" the network should do and less on "how" i.e., 123 the intermediate steps that should be executed. This level of 124 abstraction can be referred to as "Network Intent". The implicit 125 assumption is that for "Network Intent" there might be some 126 prerequisite steps that may need to be performed, such as the network 127 elements are discovered and controlled, and device capabilities and 128 features are identified. 130 While there has been investigations of Network Intent, there are some 131 still ambiguities in terms of the terminology used. This initial 132 proposal is an attempt to clarify some of the terms and provides a 133 brief outline of the goals or the vision intended. Some use cases 134 are presented to illustrate the concepts introduced in this document. 136 2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 3. Hierarchy of Manageability 144 There is a certain non-physical, logical hierarchy in a network 145 management environment, as described in the figure below. The user 146 at the top of the hierarchy can be represented by a "real" user or a 147 system that performs actions on behalf of a user, such as a 148 management station. 150 The "user" establishes an "intent" to be taken on the network as a 151 whole and pushes that intent to the second layer of the management 152 hierarchy, which consists of the intent engine. 154 The next layer of the hierarchy consumes the "intent" and translates 155 the intent to desired actions based on the meaning of the intent. 157 The bottom layer of the hierarchy consists of the devices on the 158 network that consume the configurations and actions issued to them by 159 the intent engine. These devices sit directly on the network and are 160 responsible for traffic flowing through the network. 162 +---------+ 163 | user | 164 +----+----+ 165 | 166 | Intent API 167 | 168 +------+-------+ +------+-------+ 169 | SDN | | | 170 + +-------------+Intent Engine + 171 | Controller | | | 172 +------+-------+ +------+-------+ 173 | 174 | Instruct 175 | network 176 +------------------+------------------+ 177 | | | 178 +----+----+ +----+----+ +----+----+ 179 | Device | | Device | | Device | 180 +---------+ +---------+ +---------+ 182 Figure 1 184 4. Network Configuration 186 Network configurations are the most basic atomic operations that can 187 be performed on a network device. A particular feature of the 188 network software can be enabled by one or many lines of network 189 configurations. Often the network devices are configured by experts 190 with _domain expertise_ and based on the functionality the network 191 device has to perform. Often, network configuration is performed on 192 a device by device basis and this is a manual process. Automation of 193 this process is very important step, which can save time and reduce 194 the possible number of mis-configurations. 196 5. Network Policy 198 Policy based network management has been widely discussed in the 199 literature [JNSM]. Several proposals for the semantics and structure 200 for expressing network policy have been considered. There are some 201 particular implementations and deployments of network policies such 202 as Performance Forwarding, QoS profiles etc. 204 A network policy can be viewed as a set of rules a network administer 205 can use to manage the network resources; for example to provide 206 differential treatment for traffic. Policies can be at a network 207 level and can provide a way of consistently managing multiple network 208 devices. The administrator can define policies and specify how the 209 network devices should deal with different types of traffic. 210 Policies can be defined to be conditional, in the sense, if there is 211 a condition A is observed, then a set a network policy can be 212 implemented on some network devices. Policies can be a group of 213 network configurations which perform a specific function that can be 214 applied to network devices. In the SDN paradigm, network policies 215 can be pushed to the network devices using NETCONF [RFC6020] and 216 RESTCONF [RFC8040]. 218 6. Network Intent 220 Network Intent can be considered as a declarative paradigm by which 221 the network administrator articulates a desited outcome or the state 222 of the network. In abstraction, the network enables a set of 223 services that can be consumed. In particular, Network Intent is a 224 desirable functionality that can be enabled from an SDN Controller. 225 There are potential benefits of ease-of-use and operational 226 simplicity and the capability of programming the entire network. 228 Network Intent need not be prescriptive or expressed explicitly in 229 terms of specific actions. The following are the intended design 230 considerations of network intent. 232 o First, there may be several alternative approaches to realise a 233 specific Network Intent. 235 o Second, it is conceivable that it may not be possible to realise 236 some of the Network Intents due to non-availability of network 237 resources or the network may not have functionality. 239 o Third, some new Network Intent can be in conflict with the current 240 state of the network or can disrupt the Network Intents expressed 241 previously. It is assumed such a feedback regarding the conflicts 242 is provided back to the administrator the originator of the 243 Network Intent. Based on the feedback, it should be possible for 244 the network administrator to refine the new Network Intent. 246 This proposal or definition of Network Intent can be viewed as 247 analogous to the promise theory framework proposed [Promise]. In 248 order to realise the Network Intent, it may be useful consider a 249 logical functional block - the Intent Engine - that can resolve the 250 network intent and render the Network Intent appropriately on to the 251 network. 253 The simplistic method to realise network intent is to consider linear 254 one-to-one mapping of Network Intents to actual network policies or 255 network configurations. In a more general framework of Network 256 Intent, it should be possible to consider a more general approach 257 leveraging artificial intelligence based techniques so that the 258 Network Intent can be accurately realised and appropriately rendered 259 on the network. Translating the intent requests to rendering actions 260 would require the modelling of network devices and the 261 functionalities and configurations. 263 In order to realise a Network Intent eventually that should consist 264 of network configuration blocks that can be implemented in one or 265 more network devices. 267 There is a general confusion between policy based network management 268 and intent based network management. An analogy can be drawn between 269 intent based network management and the automotive industry. Though 270 cliched, this analogy provides the closest match. Many cars, if not 271 all, have cruise control as a function today. Cruise control is a 272 very simplistic functionality that keeps the car going at a specific 273 speed. It monitors the speed and adjusts it up or down. This can be 274 considered as a policy, to keep the car driving at certain speed, 275 until the operator disengages the policy manually. 277 An car that can handle intent would, on the other hand, accept a 278 request such as "take me from San Francisco to Los Angeles within 6 279 hours," plot the appropriate path based on historical data on which 280 roads are the best ones to take to achieve the constraint of reaching 281 within 6 hours and plots the direction to go in. Then it would 282 constantly monitor the traffic on the path and provide feedback to 283 the operator about whether the path chosen will still achieve the 284 constraint. If the constraint cannot be achieved, then it either re- 285 plots the path or lets the operator know that the constraint cannot 286 be achieved and requests a new constraint. The operator is removed 287 from making the decision about which exact path to take and is 288 instead just providing the constraints that need to be achieved. 290 7. Use Cases 292 This section lists certain use cases that showcase the value of 293 intent based network management. There are a variety of use cases 294 where intent based network management is of value but the highest 295 value is present in scenarios where a network needs to be 296 reprogrammed in a significant manner in the shortest of time frames. 297 Such a network reconfiguration should not result in misconfiguration 298 that could result in the loss of communication capabilities for the 299 users of the network. 301 We provide two scenarios where such a reconfiguration of the network 302 is required. There are obviously many more day-to-day scenarios 303 where the intent of change or monitoring of a network can be of a 304 much lower scale. 306 7.1. A simple example 308 The network administrator articulates the Network Intent, "Route 309 traffic from Node A to Node B with minimum bandwidth of K mbps". The 310 Intent Engine then resolves the intent. This step involves 311 understanding the intent expressed and the second step to resolving 312 that intent would require performing routing calculations between 313 Node A and Node B. This is a key step involved in this proposal. 315 Once the intent has been resolved, routing calculations are well- 316 known and there are standard techniques taking into account the 317 network topology between Node A and Node B; the current utilisations 318 with minimum guaranteed bandwidth of K Mbps between Node A and Node 319 B. Once the path is determined, that routing and next hop 320 configurations are communicated to the respective network nodes. 322 7.2. Disaster Management 324 Planning for disaster management and sudden reconfiguration of 325 infrastructure is common in the "physical" world - ie roads, water 326 supply, electricity, etc. Similar reconfigurations of communication 327 networks also is important during a disaster. During a disaster 328 management / recovery, it is important to ensure that emergency 329 communication traffic (such as 911 in the USA, 999 in UK and similar 330 in other countries) gets more bandwidth and resources than non- 331 emergency communication. It is also important to allow people to 332 communicate with their family members inside and outside the disaster 333 area, to help in recovery efforts. For this reason, voice 334 communication, including VoIP, should be prioritized over streaming 335 video services. 337 Such a disaster management is geographically bounded, therefore the 338 network changes need to also be appropriately geographically bounded. 339 This is very often hard to apply manually in a very large network at 340 the moment that the change is needed. Intent based networks can 341 provide an abstraction that use the underlying knowledge of the 342 network and policies to achieve an action to provide this ability in 343 a finer grained manner. 345 As the disaster scenario subsides the applied intent should 346 automatically subside as well. This requires not only action to be 347 taken based on policies, but also requires constant monitoring of the 348 operational state network. Such monitoring presents significant 349 amounts of data and it is quite hard to build rules and conditions to 350 operate on such data while minimizing mistakes. Machine learning 351 based monitoring can provide a mechanism to make applying an intent 352 easier, especially in very large networks. Such machine learning 353 based mechanisms can be integrated with physical world monitoring to 354 identify when a disaster hits a certain geography and to 355 automatically trigger a pre-set intent for that scenario. With such 356 machine learning mechanisms and multiple pre-set intents, it would be 357 possible for a management system to automatically trigger a specific 358 intent when it detects a particular scenario. Similar combination of 359 operational monitoring and intent based networking mechanism can be 360 used to withdraw an intent when the disaster like scenario recedes. 362 8. Issues with Intent based networking 364 Intent based network management is about creating an abstraction to 365 handle the management of a network. Naturally issues related to any 366 abstraction mechanism applies here as well. Specifically, an 367 abstraction like this removes the direct interaction of a user with 368 the network for operations management. While the original creators 369 of this intent, and the associated policies, would have understood 370 the reasoning behind this intent, and more importantly the fine 371 distinction between when to apply and when NOT to apply such an 372 intent, later users of the system may not have that clear distinction 373 and may apply this intent needlessly. This problem exists in any 374 abstraction mechanism. 376 9. Security Considerations 378 This draft currently does not impose any security considerations. 380 10. IANA Considerations 382 This memo has no actions for IANA. 384 11. References 386 11.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, 390 DOI 10.17487/RFC2119, March 1997, 391 . 393 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 394 the Network Configuration Protocol (NETCONF)", RFC 6020, 395 DOI 10.17487/RFC6020, October 2010, 396 . 398 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 399 and A. Bierman, Ed., "Network Configuration Protocol 400 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 401 . 403 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 404 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 405 . 407 11.2. Informative References 409 [JNSM] Boutaba, R. and I. Aib, "Policy-Based Management: A 410 Historical perspective, Journal of Network and Systems 411 Management 15 (4), 447-480", 2007. 413 [Promise] Borril, P., Burgess, M., Craw, T., and M. Dvorkin, "A 414 Promise Theory Perspective on Data Networks, CoRR, 415 abs/1405.2627", September 2014. 417 Authors' Addresses 418 Kaarthik Sivakumar 419 Cisco Systems, Inc. 420 Sarjapur Outer Ring Road 421 Bangalore 560103 422 India 424 Phone: +91 80 4429 2264 425 Email: kasivaku@cisco.com 426 URI: http://www.cisco.com/ 428 Mouli Chandramouli 429 Cisco Systems, Inc. 430 Sarjapur Outer Ring Road 431 Bangalore 560103 432 India 434 Phone: +91 80 4429 2409 435 Email: moulchan@cisco.com 436 URI: http://www.cisco.com/