idnits 2.17.1 draft-du-anima-an-intent-05.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. ** The abstract seems to contain references ([RFC7575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (February 14, 2017) is 2621 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBC' is mentioned on line 370, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-05 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-09 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-02 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG Z. Du 3 Internet-Draft S. Jiang 4 Intended status: Informational Huawei Technologies Co., Ltd 5 Expires: August 18, 2017 J. Nobre 6 Federal University of Rio Grande do Sul 7 L. Ciavaglia 8 Alcatel Lucent 9 M. Behringer 10 Cisco Systems 11 February 14, 2017 13 ANIMA Intent Policy and Format 14 draft-du-anima-an-intent-05 16 Abstract 18 One of the goals of autonomic networking is to simplify the 19 management of networks by human operators. Intent Based Networking 20 (IBN) is a possible approach to realize this goal. With IBN, the 21 operator indicates to the network what to do (i.e. her intent) and 22 not how to do it. In the field of Policy Based Management (PBM), the 23 concept of intent is called a declarative policy. This document 24 proposes a refinement of the intent concept initially defined in 25 [RFC7575] for autonomic networks by providing a more complete 26 definition, a life-cycle, some use cases and a tentative format of 27 the ANIMA Intent Policy. 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 August 18, 2017. 46 Copyright Notice 48 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Language and Terminology . . . . . . . . . . . . 3 65 3. Concept of ANIMA Intent Policy . . . . . . . . . . . . . . . 4 66 4. Intent Life Cycle . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Use Cases for ANIMA Intent Policy . . . . . . . . . . . . . . 6 68 6. Distribution of ANIMA Intent Policy . . . . . . . . . . . . . 7 69 7. Management of ANIMA Intent Policy . . . . . . . . . . . . . . 7 70 8. Interpretation of ANIMA Intent Policy . . . . . . . . . . . . 7 71 9. Uniform Format of the ANIMA Intent Policy . . . . . . . . . . 8 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 76 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 One of the goals of autonomic networking is to simplify the 82 management of networks by human operators. Intent Based Networking 83 (IBN) is a possible approach to realize this goal. With IBN, the 84 operator indicates to the network what to do (i.e. her intent) and 85 not how to do it. In the field of Policy Based Management (PBM), the 86 concept of intent is called a declarative policy. This document 87 proposes a refinement of the intent concept initially defined in 88 [RFC7575] for autonomic networks by providing a more complete 89 definition, a life-cycle, some use cases and a tentative format of 90 the ANIMA Intent Policy. 92 An Autonomic Network must be able to operate with minimum 93 intervention from human operators. However, it still needs to 94 receive some form of guidance (e.g. ANIMA Intent Policies) in order 95 to fulfill the operator requirements. 97 In PBM, the Policy Continuum defines the levels at which the policies 98 are defined (policy creation point), consumed (policy execution 99 point) and translated (policy interpretation point). Using PBM, the 100 operator can manage the network as a whole, and does not need to 101 configure each individual devices in the network. The transformation 102 of the high-level/abstract policies to the low-level device 103 configurations is realized automatically by a set of functions 104 usually regrouped inside a Policy Engine. 106 The use of policies and in particular of declarative policies assumes 107 that the entities in the Autonomic Network receiving the ANIMA Intent 108 Policy are capable of processing (refining and/or executing) the 109 policy with no ambiguity. For that, the format of the ANIMA Intent 110 Policy and the hierarchy of policy levels must be specified. 112 This document proposes a base format of the ANIMA Intent Policy. 113 Application-specific extensions of the base format should be defined 114 on a per need basis in dedicated documents. 116 2. Requirements Language and Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 [RFC2119] when they appear in ALL CAPS. When these words are not in 122 ALL CAPS (such as "should" or "Should"), they have their usual 123 English meanings, and are not to be interpreted as [RFC2119] key 124 words. 126 Autonomic Function: A feature or function which requires no 127 configuration, and can derive all required information either 128 through self-knowledge, discovery or through Intent. 130 Autonomic Node: A node which employs exclusively Autonomic 131 Functions. 133 Legacy Node: A non-autonomic node, i.e., a node which employs some 134 non-autonomic functions. 136 Autonomic Network: A network containing exclusively Autonomic Nodes. 137 It may contain one or several Autonomic Domains. 139 Autonomic Domain: A collection of autonomic nodes that instantiate 140 the same Intent. 142 Autonomic Service Agent: An agent implemented on an Autonomic Node 143 which implements an Autonomic Function. 145 Intent: An abstract, high-level policy used to operate the network. 147 ANIMA Intent Policy: A declarative type of policy used in Autonomic 148 Networks. 150 Configlet: Intent is interpreted on the Autonomic Node, and the 151 results will be interpreted and stored in a local format on the 152 Autonomic Node. This stored version is known as a "configlet". 154 NOC: A network operations center is the location where network 155 monitoring and control is exercised. 157 3. Concept of ANIMA Intent Policy 159 In the scope of autonomic networking, the definition of intent can be 160 found in [I-D.ietf-anima-reference-model], in which intent is 161 described as "an abstract, declarative, high-level policy used to 162 operate an autonomic domain, such as an enterprise network." 164 An Autonomic Network will comprise multiple ANIMA Intent Policies. 165 Different ANIMA Intent Policies will be "interpreted" by different 166 entities in autonomic networks, and the "level" of understanding of 167 the intent will impact how the intent will be presented to this 168 entity. So there should be "intermediate" mechanisms/functions that 169 cater for the intent translation continuum across the heterogeneity 170 (in policy capabilities) of the network entities. Also, ANIMA Intent 171 Policies will possibly overlap and this overlapping should be managed 172 (e.g., avoid conflicts, resolve applicable policies in context). 174 4. Intent Life Cycle 176 This section describes a top-down flow about how an ANIMA Intent 177 Policy is derived through an autonomic network. 179 1. Business goals: The network owner wants the network to follow 180 some business goals. These goals are initially not formalised 181 in a particular way. A Domain Specific Language (DSL) is used 182 to format these goals in a form subsequent components can 183 interpret and process. 185 2. ANIMA Intent Policy (or Intent): Is the formalisation of 186 business goals so that computer can deal with them. It is 187 encoded as a file (or several files), and this file must be 188 "given to the network". 190 3. Ingestion: The Intent file(s) get instantiated on an autonomic 191 node. On a particular node, an intent file is "ingested". 192 After that, it needs to be distributed. 194 4. Intent Distribution: Intent is flooded to all nodes in a 195 network. Every node has a copy of the original "Intent" 196 file(s), without modification. Each node re-distributes the 197 original Intent files, without modification. Therefore, Intent 198 is optional and transitive in nature. The Intent files must now 199 be interpreted by each node. Editor's note: need to better 200 defined meaning of "optional" and "transitive". 202 5. Intent splitting (on each node): Intent is split into sections, 203 one for the ANI itself, others for specific Autonomic Functions. 204 ASAs are notified if there is new Intent for them. Some intent 205 sections may not apply to a particular node. Now each component 206 of a node (ANI, all ASAs) know their respective Intent. 208 6. Intent Interpretation (on each node, by each function): The ANI 209 as well as all ASAs on a node interpret their respective Intent 210 section(s). It gets translated into a "target configuration", 211 taking into account local state. For this translation, it may 212 be necessary for ASAs to communicate with ASAs on other nodes, 213 to pass on resources (IP addresses), to negotiate, etc. All 214 such communications may be triggered by Intent, but the 215 communications themselves are not Intent. (NB: This 216 interpretation could also be done centrally, and the resulting 217 configurations distributed; This is of course an option, but out 218 the scope of ANIMA.) After interpreting Intent locally on each 219 node, each node has target configlet to apply. Editor's note: 220 define new terms such as "configlet" 222 7. Conflict Resolution with non-autonomic management (on each 223 node): The target configlet resulting from Intent has the lowest 224 priority; meanwhile, any other management method (CLI, NETCONF, 225 etc.) overrides Intent. 227 8. Conflict Resolution between autonomic components (on each node): 228 Each autonomic function needs to register with a "conflict 229 resolution function" which parameters it modifies; in case of 230 conflict, the conflict resolution function takes a decision and 231 feeds that back to the autonomic functions. This may modify the 232 target configlet. 234 9. Applying the target configlet. 236 10. Feedback loops to NOC: The NOC needs to know about certain 237 conditions, such as conflicts with non-autonomic management. 239 Not all conflicts can be resolved automatically, so they may 240 require NOC actions. Undesirable states (deviations from 241 expected default behaviour) may have to be communicated too. To 242 some extent, Intent itself can specify which conditions should 243 trigger feedback loops to the NOC. Feedback loops may happen at 244 other phases as well (ex: 8). 246 5. Use Cases for ANIMA Intent Policy 248 In this section, some use cases are introduced to clarify the concept 249 of ANIMA Intent Policy. It should be noted that intent is defined 250 per Autonomic Function, and can also be a general one related to 251 multiple AFs. 253 The first example is about "arranging VM guest distribution". The 254 autonomic network is supposed to be able to monitor the CPU/power 255 utilization on each host machine, and control the status of each host 256 machine (e.g. turn on/off). The operator may have an intent "there 257 should be enough hosts to keep CPU utilization less than 70%", and 258 also another one "there are few enough hosts powered so that 259 electricity isn't wasted". 261 These two intents can both influence the ASA responsible for 262 controlling how many hosts are needed. The final decision is made 263 according to multiple factors, including network environment and 264 intents entered by the operators. 266 In this case, the first intent should have a higher priority than the 267 later one. The two intents should be analyzed and coordinated to 268 ensure the ASA act rightly. 270 Another example is about coordination of "load balancing" intent and 271 "energy saving" intent. Autonomic Network of Operator A is composed 272 of Autonomic Function Agents such as load balancing (LB_AFA) and 273 energy saving (ES_AFA). Operator A wants to limit the proportion of 274 links loaded over a certain threshold and thus defines an Intent to 275 activate load balancing if the load is superior to 0.6 on more than 276 30% of the links. 278 Meanwhile, operator A wants different load balancing policies per 279 (technology, administrative, topology) domain. Let's consider a 280 metropolitan network domain and a core network domain, or different 281 LB policy for border routers than interior routers. For the 282 metropolitan network domain, Operator A defines an Intent to minimize 283 the link load variance. For the core network domain, Operator A 284 applies the previously defined intent (activate load balancing if the 285 load is superior to 0.6 on more than 30% of the links). 287 The intents will be distributed to the right network domain, and take 288 effect after being interpreted and coordinated, and it is easy to 289 change them without the need to configure every device manually. 291 6. Distribution of ANIMA Intent Policy 293 The distribution of intent can be done by using GRASP 294 [I-D.ietf-anima-grasp] and ACP 295 [I-D.ietf-anima-autonomic-control-plane]. The operator can issue a 296 new intent or modify an intent through any authorized nodes in the 297 autonomic network. After that, the intent will be flooded to all the 298 nodes in the autonomic network. Another scenario is that when a new 299 node joins into an autonomic domain, it may receive an intent from 300 its neighbor. 302 For example, GRASP can be used to communicate version number of the 303 intent, and meanwhile, a URL where to find it. 305 {Editor Notes: other distribution methods are also possible. } 307 7. Management of ANIMA Intent Policy 309 Every Autonomic Node in the Autonomic domain should own an intent 310 with the same version. Any updating of intent will cause the change 311 of the intent version number. To ensure all the nodes own the same 312 intent, the nodes should be able to communicate with neighbors in the 313 domain about the version of the intent. If its neighbor has a newer 314 version of intent, it can request an intent update. 316 If the operator issues a new intent or modify intents, it will 317 trigger a domain level updating of intent. Nodes in the Autonomic 318 Network should be aware which domain it belongs to, and accept intent 319 for that domain. 321 {Editor Notes: talk about the questions as follows. When/on which 322 triggers are intents generated, updated? How the domain(s) are 323 defined and recognized (if I am an AFA, how do I know I am part of 324 domain x, y or z...?). } 326 8. Interpretation of ANIMA Intent Policy 328 After receiving an intent, the Autonomic Node should confirm whether 329 it is acceptable, according to the domain name information, intent 330 version, signature, and so on. If it passes the validation, an 331 intent interpretation module will be involved to decide which ASAs 332 will be involved in. Coordination of intents may be needed before 333 the execution of the policies interpreted from the intent. 335 {Editor Notes: talk about the questions as follows. How the AFAs 336 receive, understand and react to an intent? } 338 {Editor Notes: how the splitting (step 5 in the Life Cycle section) 339 happens here can be explained more here. It would be better that an 340 example can be introduced here.} 342 9. Uniform Format of the ANIMA Intent Policy 344 {Editor Notes: Format of Intent is FFS. It is suggested to contain 345 the following information.} 347 This section proposes a uniform intent format. It uses the tag-based 348 format. 350 Autonomic intent: The root tag for the Autonomic Network Intent. 352 Intent type: It indicates the intent type, which is associated with 353 a specific Autonomic Function. 355 Autonomic domain: It indicates the domain of the Autonomic Network. 356 It is also the scope of the Autonomic Network Intent. 358 Intent version: It indicates the version of the ANIMA Intent Policy. 359 This is an important feature for synchronization. 361 Model version: The version of the model used to define the intent. 363 Name: The name of the intent which describes the intent for human 364 operators. 366 Signature: The signature is used as a security mechanism to provide 367 authentication, integrity, and non-repudiation. 369 Timestamp: The timestamp of the creation of the intent using the 370 format supported by the IETF [TBC]. 372 Lifetime: The lifetime in which the intent may be observed. A 373 special case of the lifetime is the definition of permanent 374 intents. 376 Content: It contains the main information of the intent. It may 377 include objects, policies, goals and configuration data. The 378 detailed contents and formats should be defined under their 379 specific situations by documents that specifies the Autonomic 380 Service Agent. Within the content, there may be sub_intents. 382 10. Security Considerations 384 Relevant security issues are discussed in [I-D.ietf-anima-grasp]. 385 The ANIMA Intent Policy requires strong security environment from the 386 start, because it would be great risk if the ANIMA Intent Policy had 387 been maliciously tampered. The Autonomic Intent should employ a 388 signature scheme to provide authentication, integrity, and non- 389 repudiation. 391 11. IANA Considerations 393 This document defines one new format. The IANA is requested to 394 establish a new assigned list for it. 396 12. Acknowledgements 398 The authors of this draft would like to thank the following persons 399 for their valuable feedback and comments: Bing Liu, Brian Carpenter, 400 Michael Richardson, Joel Halpern, John Strassner, and Jason Coleman. 402 This document was produced using the xml2rfc tool [RFC2629]. 404 13. Change log [RFC Editor: Please remove] 406 draft-du-anima-an-intent-00: original version, 2015-06-11. 408 draft-du-anima-an-intent-01: add intent use case section, add some 409 elements for the format section, and coauthor Jeferson Campos Nobre 410 and Laurent Ciavaglia, 2015-07-06. 412 draft-du-anima-an-intent-02: add the intent concept section, and some 413 other sections, 2015-10-14. 415 draft-du-anima-an-intent-03: modify the use case section, and add 416 some other contents, 2016-03-17. 418 draft-du-anima-an-intent-04: modify the use case section, add the 419 procedure section, and reorganize contents, 2016-07-08. 421 draft-du-anima-an-intent-05: modify the use case section, and delete 422 some sections, 2017-02-15. 424 14. References 426 [I-D.ietf-anima-autonomic-control-plane] 427 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 428 Control Plane", draft-ietf-anima-autonomic-control- 429 plane-05 (work in progress), January 2017. 431 [I-D.ietf-anima-grasp] 432 Bormann, C., Carpenter, B., and B. Liu, "A Generic 433 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 434 grasp-09 (work in progress), December 2016. 436 [I-D.ietf-anima-reference-model] 437 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 438 Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A 439 Reference Model for Autonomic Networking", draft-ietf- 440 anima-reference-model-02 (work in progress), July 2016. 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, 444 DOI 10.17487/RFC2119, March 1997, 445 . 447 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 448 DOI 10.17487/RFC2629, June 1999, 449 . 451 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 452 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 453 Networking: Definitions and Design Goals", RFC 7575, 454 DOI 10.17487/RFC7575, June 2015, 455 . 457 Authors' Addresses 459 Zongpeng Du 460 Huawei Technologies Co., Ltd 461 Q14, Huawei Campus, No.156 Beiqing Road 462 Hai-Dian District, Beijing, 100095 463 P.R. China 465 Email: duzongpeng@huawei.com 467 Sheng Jiang 468 Huawei Technologies Co., Ltd 469 Q14, Huawei Campus, No.156 Beiqing Road 470 Hai-Dian District, Beijing, 100095 471 P.R. China 473 Email: jiangsheng@huawei.com 474 Jeferson Campos Nobre 475 Federal University of Rio Grande do Sul 476 Porto Alegre 477 Brazil 479 Email: jcnobre@inf.ufrgs.br 481 Laurent Ciavaglia 482 Alcatel Lucent 483 Route de Villejust 484 Nozay 91620 485 France 487 Email: laurent.ciavaglia@alcatel-lucent.com 489 Michael Behringer 490 Cisco Systems 491 Building D, 45 Allee des Ormes 492 Mougins 06250 493 France 495 Email: mbehring@cisco.com