idnits 2.17.1 draft-xia-ibnemo-icim-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 == Line 161 has weird spacing: '...etailed plan ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 22, 2015) is 3261 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Y. Xia, Ed. 3 Intended Status: Standards Track T. Zhou, Ed. 4 Expires: November 23, 2015 Y. Zhang, Ed. 5 S. Hares 6 Huawei 7 P. Aranda 8 D. Lopez 9 Telefornica 10 J. Crowcroft 11 Cambridge University 12 Y. Zhang 13 China Unicom 14 May 22, 2015 16 Intent Common Information Model 17 draft-xia-ibnemo-icim-00 19 Abstract 21 Intent Common Information Model (ICIM) generalizes a unified model 22 for expressing different layers' intent whatever role, 23 responsibility, knowledge, etc. This document provides an information 24 model to be inherited and expanded to construct specific intent model 25 in different areas. According to this information model, network 26 intent model is put forward which can satisfy users' need in 27 different layers, such as, end-users, business developers, and 28 network administers. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Intent Common Information Model Overview . . . . . . . . . . . 4 70 2.1 Elements . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1.1 User . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.1.2 Context . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.1.3 Object . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1.4 Result . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2.1.5 Operation . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.2 Relationships in ICIM . . . . . . . . . . . . . . . . . . . 6 77 2.2.1 Relationship between Result and Operation . . . . . . . 6 78 2.2.2 Relationship between Object and Operation . . . . . . . 7 79 2.2.3 Relationship between Object and Result . . . . . . . . 7 80 2.3 Intent and Policy . . . . . . . . . . . . . . . . . . . . . 7 81 2.4 Layers of Intent . . . . . . . . . . . . . . . . . . . . . 8 82 3. Intent Modeling . . . . . . . . . . . . . . . . . . . . . . . 8 83 3.1 Intent overview . . . . . . . . . . . . . . . . . . . . . . 8 84 3.2 Top level intent expression . . . . . . . . . . . . . . . . 8 85 3.3 Objects in the network . . . . . . . . . . . . . . . . . . 9 86 3.4 Type of result . . . . . . . . . . . . . . . . . . . . . . 10 87 3.5 Operation composition . . . . . . . . . . . . . . . . . . . 10 88 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 89 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 90 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 91 7 Informative References . . . . . . . . . . . . . . . . . . . . 12 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 94 1 Introduction 96 Intent is a new philosophy to design open interface. Opposite to the 97 'bottom up' method which opens what system has, Intent interface uses 98 'top down' method which opens what user's requirement. With this 99 Intent interface, users just need to express what their requirements 100 are, rather than how to implement them, so Intent interface is user 101 friendly. Intent interface is much closer to user, but different 102 users have different intention manifestations, which have different 103 granularity or different level. It depends on users' role, knowledge 104 and their purpose. Intent can be some final results of objects and 105 also can be some specific operations on objects in specific context. 106 Although dictating operations is the manifestation of intent, a user 107 just need to assign the operations he cares about, and has no need to 108 plan complete and detailed operations list for the system to achieve 109 the intent. 111 Intent Common Information Model (ICIM) generalizes a generic model 112 for expressing key components of intent interface and the 113 relationship between these components. This document provides a 114 common model to be inherited and expanded to construct specific 115 intent interface in specific areas. According to this information 116 model, intent interface in network area is put forward which can 117 satisfy user' intention in different layers or different roles, such 118 as, end-users, business developers, network administers, etc 120 1.1 Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Intent Common Information Model Overview 128 Intent Common Information Model aims to generalize a unified 129 information model which satisfied different areas, scenarios, and 130 other constraints. So, it is a complete and detailed information 131 model to define the constituent elements of intent, but some elements 132 can be omitted or implied under some special situations when using 133 this model to express specific data model. 135 From the overall perspective, construction elements of intent can be 136 generalized into user of intent who author and own this intent, 137 intent content which is a desired purpose and the specific context 138 for implementing intent. Furthermore, in general, person's intent 139 content is often visioning ultimate state of some objects or 140 performing actions to these objects, so intent content can be 141 abstracted into object which is the target for intent, result which 142 is a desired state and operation which is the specific actions to 143 achieve a purpose. 145 2.1 Elements 147 2.1.1 User 149 User is an abstract class which refers the subject and owner to 150 express the intent. For example, end-users, business designers, 151 network administrators are all instances of User class. Intent has a 152 strong relationship with the user. So intent is different for 153 specific user when this information model is applied to specific 154 scenario. So when ICIM is implemented, this class will involve a role 155 mapping. 157 2.1.2 Context 159 Context refers to a set of specific background information such as, 160 timer, price, and so on. Context has a huge influence on a person 161 designing a detailed plan or selecting the best program to achieve a 162 purpose. For example, when an enterprise plans to build a dedicated 163 connection between two sites, price and distance will be the context 164 in this scenario. While may not be part of how an entity expresses or 165 executes some intent, it is a factor that must be considered with the 166 expression of intent. 168 2.1.3 Object 170 Object refers an abstract class which defines some entities affected 171 or managed by intent. For the management, users could manage life 172 cycle of the objects through some concrete operations, such as, 173 create, update, delete, etc. In addition, users could use other 174 specific operations to affect the behavior of managed objects. For 175 example, a business designer want all traffic be filtered by a 176 special firewall. The object of this business designers intent could 177 be the all traffic flowing on a specific network (e.g. L3VPN), and 178 this intent impacts the forwarding behavior of the traffic network. 179 Object is different in specific area. In network area, object is an 180 aggregation class with node, connection and flow. For objects, users 181 could construct some specific objects to achieve intent, and it is 182 also allowed for users to assign intent to existing resources. 184 2.1.4 Result 186 Result is a type of intent which refers to an ultimate state or 187 something an individual wants to achieve. This type of intent shields 188 difference and diversity of an environment away from the users' 189 intent. The person just envisions the ultimate state of objects 190 without worrying about how to achieve it. For example, a result could 191 be that the company accesses any sites on the Internet safely. It 192 just defines a result that ignores technology details, such as, 193 firewall, ACL, and so on. 195 Though desired state is a general requirement, violation state is 196 another special state which has an important status when achieving 197 integral compliance. For example, a typical scenario is all virtual 198 machines owned by different tenants should not be deployed in a same 199 hypervisor. This type of result just shows the undesired state which 200 is a type of violation state, and this kind of intent should be 201 involved in this information model. 203 2.1.5 Operation 205 Operation is a type of intent which refers to some specific actions 206 an individual desires to take for realizing the purpose. This type of 207 intent formulates explicit plan to realize a purpose which may take a 208 better control of the whole system. According to the diversity of 209 system support capability, there are large sets of operations for 210 users to take. 212 Generally, operations can be divided into two categories. One is 213 action without condition which is called "command" usually. For 214 example, create a virtual machine. This kind of operation defines a 215 concrete action which is executed immediately without any trigger. 216 The other is action with condition. For this kind of operations, 217 condition is a trigger for the action. And actions will not be 218 executed immediately until the condition clause is tested to be true. 219 For example, "do load balancing when the utilization of a link 220 exceeds 80%". In this example, "utilization of a link" is the 221 trigger, and "do load balancing" is the action. Action will not be 222 taken until the trigger is true. Actions are different by stages 223 which depend on the layer of intent. Actions expressed in upper layer 224 may lead to cascaded actions in other lower layers. For example, the 225 action "do load balancing" will bring out many actions which are 226 depend on technologies and devices. 228 2.2 Relationships in ICIM 230 2.2.1 Relationship between Result and Operation 232 Users are free to express their intent, no matter it is an ultimate 233 result or specific operations in their mind, but there are some 234 relationships between these two basic types of intent. For result, 235 users just need to express the goal without worrying how to implement 236 it in a specific system which facilitates users to focus on real 237 requirement. When achieving the ultimate result, it needs some 238 reasoning mechanisms to transfer it to real executable operations 239 which are supported by specific system. So in a specific scenario, a 240 result can generate concrete operations. For example, for a 241 geographical distributed enterprise, its intent is constructing a 242 dedicated line between headquarters and branches at the least cost. 243 This intent just expresses a result without defining how to construct 244 this dedicated line. So business designers will design the best 245 solution and concrete operations referring capability of devices, 246 optional programs, prices, etc. 248 2.2.2 Relationship between Object and Operation 250 Operation refers to some specific actions on some objects, so object 251 is the target of an action. In general, any action will include some 252 objects to execute this action. When users want to execute some 253 actions to achieve goals, they may construct the target objects and 254 assign specific actions on them, and it is allowed for users to use 255 existing resources to do some operations. Though object is the target 256 of action, it offers the constraint for optional operations. For 257 example, for a virtual machine, the optional operations are create, 258 delete, immigrant, etc. 260 2.2.3 Relationship between Object and Result 262 Result refers to some ultimate state for some objects. This type of 263 intent does not define which specific operations to take but express 264 the desired state of objects. So it is independent on objects' 265 capability. For example, intent is all virtual machines' CPU 266 utilization could not exceed 80%. It does not assign specific 267 operations. So reasoning mechanism will choose suitable operations to 268 satisfy this intent, such as, immigrant virtual machine or expand it. 270 2.3 Intent and Policy 272 In industry, Policy already has a clear definition, such as in 273 RFC3060. Policy rule consists of an event, a set of conditions and a 274 set of actions. When an event occurs, actions will be taken until 275 condition clauses are evaluated to be true. 277 As mentioned above, intent refers to a purpose in achieving ultimate 278 result or performing operation. The intent has a larger scope 279 compared with the policy since Intent can express both result and 280 operation. On one hand if a result is described by intent, there may 281 be no specific action given to show how to achieve this intent. On 282 the other hand, if operation described by intent, conditions of 283 action is optional. Policy is a specific form of operation in 284 intent. 286 2.4 Layers of Intent 288 Intent reflects a person's mental desire which depends on person's 289 role, knowledge, and other contextual factors. So users in different 290 layers may have different intent. While different layer of intent has 291 some differences in content and implementation, the expression of 292 each layer of intent is same which defines an ultimate goal or 293 dictates specific operations. 295 For example, in the network area the intent of end-users could be 296 safe connectivity between two sites which a technology independent 297 and device independent requirement. For business-based network 298 designers, the network connectivity can be selected which is device- 299 independent but technology specific. An example of the business-based 300 technology is the L3VPN. For network administrators, intent can be 301 specific operations on a set of devices such as configuring IP 302 addresses on network servers in a data center. 304 3. Intent Modeling 306 This section defines the concept and hierarchy of intent, and 307 describes the Intent Common Information Model. 309 3.1 Intent overview 311 In general, intent is one's specific mental activity, so it strongly 312 depends on the subject. Different users may have different 313 manifestations and intent. In addition, context, omitted usually, is 314 an important factor when achieving purpose, which offers necessary 315 background information to impact the decision. Figure 1 illustrates 316 the overview of the intent. Figure 1 indicates that the user has 317 intent in some context. For example, an enterprise wants to block all 318 http traffic in work time. In this intent, the user is the 319 enterprise, the intent is to block all http traffic in the work 320 hours, and the context includes the definition of the "enterprise" 321 and the "work hours". 323 +------+ has +--------+ in +---------+ 324 | user +-------->+ intent +------->+ context | 325 +------+ +--------+ +---------+ 327 Figure 1 general prescription for intent 329 3.2 Top level intent expression 331 In Cambridge Dictionaries, the definition of "intent" is the fact 332 that you want and plan to do something. So, in general, intent refers 333 to an agent's purpose in getting an ultimate result or performing 334 some specific operation. In specific areas, these results or 335 operations will relate to some objects. Figure 2 describes the 336 general expression of intent. 338 +----------+ 339 | intent | 340 +-C--A--A--+ 341 | | | 342 +-----------+ | +------------+ 343 | | | 344 +---+----+ +---+----+ +-----+-----+ 345 | object | | result | | operation | 346 +--------+ +--------+ +-----------+ 348 Figure 2 intent expression 350 One type of intent is to express key operations that a user wants to 351 execute. The underlying intent system can generate a complete 352 operation list from user's request. The other type of intent is to 353 express an ultimate result or state without dictating any operations. 355 For example, intent of a user may be a result without defining how to 356 realize it, such as, requiring security communication between two 357 sites, or dictate some detailed operations in order to achieve a 358 purpose, such as, filtering all traffics by firewall between these 359 two sites. 361 3.3 Objects in the network 363 Object is an abstraction class which can be inherited and expanded in 364 different area. In network area, the object, i.e. the target of 365 intent, can be generalized into Node, Connection and Flow, as shown 366 in Figure 3. 368 +------+ 369 +------+ node | 370 | +------+ 371 +--------+G+-+ 372 | | +------------+ 373 | object |G+--------+ connection | 374 | | +------------+ 375 +--------+G+-+ 376 | +------+ 377 +------+ flow | 378 +------+ 380 Figure 3 common objects in network area 382 The Node represents the functions a network node may provide in a 383 network such as network services, forwarding functions (firewall, 384 load balancer, virtual router, and others), or a group of network 385 elements. A group of network elements can be a subnet, an autonomous 386 system, or a confederation of autonomous systems. 388 The Connection describes logical connectivity between node entities. 389 This connection is not limited to any physical link, but just 390 expresses the communication capacity between nodes. 392 The Flow refers to the traffic in network which describes data 393 packets have some certain common characters. 395 3.4 Type of result 397 Result refers an ultimate state which is expected or avoided. Figure 398 4 describes two types of result. For example, a user may express an 399 intent is his computer's CPU utilization must less than 80%. This 400 expression is a type of result which describes an expected state. Of 401 course, this user can also express this intent as it's an error when 402 his computer's CPU utilization exceeds 80%. This expression is 403 another type of result which describe a avoid state. Users are free 404 to describe either one. 406 +--------+ 407 | result | 408 +-G----G-+ 409 | | 410 +-----+ +----+ 411 | | 412 +---+----+ +---+---+ 413 | expect | | avoid | 414 +--------+ +-------+ 416 Figure 4 expression of Result 418 3.5 Operation composition 420 Operation refers to some specific actions in order to achieve some 421 purposes. An operation must have some actions. However, if condition 422 and constraint need to be defined in operations, it depends on 423 specific scenario and users' require. Once a condition is involved in 424 operation, actions will not be executed immediately until condition 425 is true. In additional, constraint restricts action itself or the 426 scope of action. 428 +-----------+ 429 | operation | 430 +-A---C---A-+ 431 | | | 432 +-------------+ | +--------------+ 433 | | | 434 | | | 435 +-----+-----+ +---+----+ +------+-----+ 436 | condition | | action | | constraint | 437 +-----------+ +--------+ +------------+ 439 Figure 5 composition of operation 441 4 Security Considerations 443 TBD 445 5 IANA Considerations 447 This draft includes no request to IANA. 449 6 Acknowledgements 451 The authors would like to thanks the valuable comments made by Wei 452 Cao, Sheng Jiang, Zhigang Ji, Xuewei Wang, Shixing Liu, Yan Zhang. 454 7 Informative References 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 Authors' Addresses 461 Yinben Xia 462 Huawei Technologies Co., Ltd 463 Q14, Huawei Campus, No.156 Beiqing Road 464 Hai-Dian District, Beijing, 100095 465 P.R. China 467 EMail: xiayinben@huawei.com 469 Tianran Zhou 470 Huawei Technologies Co., Ltd 471 Q14, Huawei Campus, No.156 Beiqing Road 472 Hai-Dian District, Beijing, 100095 473 P.R. China 475 EMail: zhoutianran@huawei.com 477 Yali Zhang 478 Huawei Technologies Co., Ltd 479 Q14, Huawei Campus, No.156 Beiqing Road 480 Hai-Dian District, Beijing, 100095 481 P.R. China 483 EMail: zhangyali369@huawei.com 484 Susan Hares 485 Huawei Technologies Co., Ltd 486 7453 Hickory Hill 487 Saline, MI 48176 488 USA 490 Email: shares@ndzh.com 492 Pedro Andres Aranda 493 Telefornica I+D, 494 Don Ramon de la Cruz, 82 Street 495 Madrid, 28006, Spain 497 EMail: pedroa.aranda@telefonica.com 499 Diego R. Lopez 500 Telefornica I+D, 501 Don Ramon de la Cruz, 82 Street 502 Madrid, 28006, Spain 504 EMail: diego.r.lopez@telefonica.com 506 Jon Crowcroft 507 University of Cambridge Computer Laboratory 508 William Gates Building, 15 JJ Thomson Avenue 509 Cambridge, CB3 0FD UK 511 Email: jon.crowcroft@cl.cam.ac.uk 513 Yan Zhang 514 China Unicom P.R. China 516 Email: zhangy1036@chinaunicom.cn