idnits 2.17.1 draft-klyus-supa-proposition-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 382: '... decisions (this SHOULD include more t...' RFC 2119 keyword, line 385: '... decisions (this SHOULD include more t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2015) is 3191 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ID.draft-strassner-supa-generic-policy-info-model' is mentioned on line 822, but not defined == Unused Reference: 'RFC6020' is defined on line 1051, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'SUPA-framework' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: 'SUPA-problem-statement' is defined on line 1068, but no explicit reference was found in the text == Unused Reference: 'SUPA-gap-analysis' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: 'SUPA-DDC' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RaBe11' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'Stras02' is defined on line 1088, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Klyus 2 Internet Draft NetCracker 3 Intended status: Standard Track J. Strassner 4 Expires: January 4, 2016 Huawei Technologies 6 July 4, 2015 8 SUPA Value Proposition 9 draft-klyus-supa-proposition-02 11 Abstract 13 The rapid growth in the variety and importance of traffic flowing 14 over increasingly complex enterprise and service provider network 15 architectures makes the task of network operations and management 16 applications and deploying new services much more difficult. 17 Simplified Use of Policy Abstractions (SUPA) defines an interface 18 to a network management function that takes high-level, possibly 19 network-wide policies as input and creates element configuration 20 snippets as output. SUPA expresses policies using a generic policy 21 information model, and outputs generic YANG data models. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet 29 Engineering Task Force (IETF), its areas, and its working 30 groups. Note that other groups may also distribute working 31 documents as Internet-Drafts. 33 Internet-Drafts are working documents of the Internet 34 Engineering Task Force (IETF). Note that other groups may also 35 distribute working documents as Internet-Drafts. The list of 36 current Internet-Drafts is at 37 http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other 41 documents at any time. It is inappropriate to use Internet- 42 Drafts as reference material or to cite them other than as 43 "work in progress." 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described 57 in Section 4.e of the Trust Legal Provisions and are provided 58 without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................3 63 1.1. Problem Statement.........................................4 64 1.2. Proposed Solution.........................................4 65 1.3. Value of the SUPA Approach ...............................5 66 2. Framework for Generic Policy-based Management..................6 67 2.1. Overview..................................................6 68 2.2. Operation.................................................8 69 2.3. Generic Policy Information Model..........................9 70 2.4. Refinement of the GPIM....................................9 71 2.4.1. Event-Condition-Action Policy Information Model.....10 72 2.4.2. Declarative Policy Information Model................10 73 3. Application of Generic Policy-based Management................10 74 3.1. Declarative Examples.....................................10 75 3.2. ECA Examples.............................................12 76 3.3. ECA plus Declarative Example.............................13 77 4. Related Work..................................................14 78 4.1. Related Work within the IETF.............................14 79 4.1.1. I2RS Working Group..................................14 80 4.1.2. L3SM Working Group..................................15 81 4.1.3. ALTO Working Group..................................15 82 4.1.4. TEAS Working Group..................................15 83 4.1.5. BESS Working Group..................................16 84 4.1.6. SFC Working Group...................................16 85 4.1.7. NVO3 Working Group..................................16 86 4.1.8. ACTN BoF (IETF-90)..................................17 87 4.1.9. Previous IETF Policy Models.........................17 88 4.2. Related Work outside the IETF............................17 89 4.2.1. TM Forum............................................17 90 4.2.2. MEF.................................................18 91 4.2.3. Open Daylight.......................................18 92 4.2.4. Open Networking Foundation..........................19 93 4.2.5. OpenStack...........................................19 94 4.2.6. The NEMO Project (Not a BoF Yet)....................20 95 4.2.7. The Floodlight Project..............................21 96 4.2.8. The ONOS Project....................................21 98 5. Conclusions - Value of SUPA...................................21 99 6. Security Considerations.......................................22 100 7. IANA Considerations...........................................22 101 8. Acknowledgments...............................................22 102 9. Additional Authors List.......................................22 103 10. References...................................................22 104 10.1. Informative References..................................22 106 1. Introduction 108 The rapid growth in the variety and importance of traffic flowing 109 over increasingly complex enterprise and service provider network 110 architectures makes the task of network operations and management 111 applications and deploying new services much more difficult. In 112 addition, network operators want to deploy new services quickly 113 and efficiently. Two possible mechanisms for dealing with this 114 growing difficulty are the use of software abstractions to 115 simplify the design and configuration of monitoring and control 116 operations and the use of programmatic control over the 117 configuration and operation of such networks. Policy-based 118 management can be used to combine these two mechanisms into an 119 extensible framework. 121 Policy statements can be used to express high-level network 122 operator requirements directly, or from a set of management 123 applications, to a network management or element system. The 124 network management or element system can then interpret those 125 requirements to control the configuration of network elements. 127 The key benefit of policy management is that it enables different 128 network elements and services to be instructed to behave the same 129 way, even if they are programmed differently. 131 Simplified Use of Policy Abstractions (SUPA) will define a 132 generic policy information model (GPIM) for use in network 133 operations and management applications. The GPIM represents 134 different types of policies for controlling the configuration 135 of network elements throughout the service development and 136 deployment lifecycle. The GPIM will be translated into 137 corresponding YANG data models to define interoperable 138 implementations that can exchange and modify generic policies 139 using protocols such as NETCONF/RESTCONF. 141 Management applications will benefit from using policy rules 142 that enable scalable and consistent programmatic control over 143 the configuration of network elements. 145 1.1. Problem Statement 147 Network operators are faced with networks of increasing size 148 and complexity while trying to improve their quality and 149 availability, as more and more business services depend on them. 151 Currently, different technologies and network elements require 152 different forms of the same policy that governs the production of 153 network configuration snippets. The power of policy management is 154 its applicability to many different types of systems. This provides 155 significant improvements in configuration agility, error detection, 156 and uptime for operators. 158 Many different types of actors can be identified that can use a 159 policy management system, including applications, end-users, 160 developers, network administrators, and operators. Each of these 161 actors typically has different skills and uses different concepts 162 and terminologies. For example, an operator may want to express 163 that only Platinum and Gold users can use streaming and interactive 164 multimedia applications. As a second example, an operator may want 165 to define a more concrete policy rule that looks at the number of 166 dropped packets. If, for example, this number exceeds a certain 167 threshold value, then the applied queuing, dropping and 168 scheduling algorithms could be changed in order to reduce the 169 number of dropped packets. 171 1.2. Proposed Solution 173 SUPA enables network operators to express policies to control 174 network configuration data models. SUPA provides a generic 175 infrastructure that defines policies to control the configuration 176 of network elements. The configuration process is independent of 177 domain or type of application, and results in configuration 178 according to YANG data models. 180 Both of the above examples can be referred to as "policy rules", 181 but they take very different forms, since they are at different 182 levels of abstraction and likely authored by different actors. 183 The first example described a very abstract policy rule, and 184 did not contain any technology-specific terms, while the second 185 example included a more concrete policy rule and likely used 186 technical terms of a general (e.g., IP address range and port 187 numbers) as well as vendor-specific nature (e.g., specific 188 algorithms implemented in a particular device). Furthermore, 189 these two policy rules could affect each other. For example, 190 Gold and Platinum users might need different device 191 configurations to give the proper QoS markings to their 192 streaming multimedia traffic. This is very difficult to do if a 193 common policy framework does not exist. 195 Note that SUPA is not limited to any one type of technology. 196 While the above two policies could be considered "QoS" 197 policies, other examples include: 199 - network elements must not accept passwords for logins 201 - all SNMP agents in this network must drop all SNMP traffic 202 unless it is originating from, or targeting, the 203 management network 205 - Periodically perform workload consolidation if average CPU 206 utilization falls below X% 208 The above three examples are not QoS related, and will be 209 explained more in Sections 4.1 and 4.2. This emphasizes the 210 utility of the SUPA approach in being able to provide policies 211 to control different types of network element configuration 212 snippets. 214 There are many types of policies. SUPA differentiates between 215 "management policies" and "embedded policies". Management 216 policies are used to control the configuration of network 217 elements. Management policies can be interpreted externally to 218 network elements, and the interpretation typically results in 219 configuration changes of collections of network elements. In 220 contrast, "embedded policies" are policies that are embedded 221 in the configuration of network elements, and are usually 222 interpreted on network elements in isolation. Since embedded 223 policies are interpreted in the network device, they are 224 typically composed in a very specific fashion to run at 225 near-realtime timescales. 227 1.3. Value of the SUPA Approach 229 SUPA will achieve an optimization and reduction in the amount 230 of work required to define and implement policy-based data 231 models in the IETF. Part of this is due to the generic and 232 extensible framework of SUPA, which models concepts common to 233 any type of policy as well as provides two information models 234 (ECA and declarative), along with the associated YANG data 235 models. 237 SUPA defines policy independent of where it is located. Other 238 WGs are working on embedding policy in the configuration of a 239 network element; SUPA is working on defining policies that 240 can be interpreted external to network elements. Hence, SUPA 241 policies can be used to define the behavior of and 242 interaction between embedded policies. 244 SUPA can also be used to derive a (more abstract) information 245 model from a (more specific) data model. This extracts data 246 that is part of a particular technology and/or application 247 and makes it reusable, so that these data can be applied to 248 multiple technologies and/or domains. 250 The SUPA policy framework defines a set of consistent, flexible, 251 and scalable mechanisms for monitoring and controlling resources 252 and services. It may be used to create a management and 253 operations interface that can enable existing IETF data models, 254 such as those from I2RS and L3SM, to be managed in a unified way 255 that is independent of application domain, technology and vendor. 256 Resource and service management become more effective, because 257 policy defines the context that different operations, such as 258 configuration, are applied to. 260 2. Framework for Generic Policy-based Management 262 This section briefly describes the design and operation of the 263 SUPA policy-based management framework. 265 2.1. Overview 267 Figure 1 shows a simplified functional architecture of how SUPA is 268 used to define policies for creating network element configuration 269 snippets. SUPA uses the Generic Policy Information Model (GPIM) to 270 define a consensual vocabulary that different actors can use to 271 interact with network elements. The GPIM defines a generic 272 structure for imperative and declarative policies. This is 273 converted to generic YANG data models. The IETF produces the 274 models, and IANA is used to register the model and changes. 276 In the preferred approach, SUPA generic policy data models are 277 then used to create vendor- and technology-specific data models. 278 These define the specific elements that will be controlled by 279 policies. The Policy Interface uses this information to create 280 appropriate input mechanisms for the operator to define policies 281 (e.g., a web form or a script) for creating and managing the 282 network configuration. The operator interacts with the interface, 283 which is then translated to configuration snippets. Note that the 284 policy interface is NOT being designed in SUPA. 286 In one of possibly several alternate approaches (shown with 287 asterisks in Figure 1), the SUPA generic policy YANG data models 288 contain enough information for the Policy Interface to create 289 appropriate input mechanisms for the operator to define policies. 290 This transfers the work of building vendor- and technology- 291 specific data models to the SUPA Data Model-Specific Translation 292 Function. 294 +---------------------+ 295 +----------+ \| SUPA Generic Policy | 296 | IETF |---+----| Information Model | 297 +----------+ | /| | 298 | +---------+-----------+ 299 | | 300 Assignments | | Defines Policy Concepts 301 and Manage | | 302 Content | \|/ 303 | +---------+-----------+ Preferred 304 | \| SUPA Generic Policy | Approach 305 +----| YANG Data Models |------------+ 306 /| | | 307 +---------+-----------+ | 308 * | 309 * | 310 +--------------------------------+------------------------+---------+ 311 | * | | 312 | * | | 313 | A Possible * \|/ | 314 | Approach * +-------+-------+ | 315 | * |Technology and | | 316 | * |Vendor-specific| | 317 | * | Data Models | | 318 | \*/ +-------+-------+ | 319 | Fills +----------+----------+ | | 320 | +--------+ Forms \| Policy Interface |/ | | 321 | |Operator|----------| (locally defined +-------------+ | 322 | +--------+ Runs /| forms, scripts,...) |\ | 323 | Scripts +----------+----------+ | 324 | | | 325 | | Produces Policy Rules | 326 | | | 327 | \|/ | 328 | +------------+--------+ +----------------+ | 329 | Local SUPA | SUPA Data Model- | \| Local Devices | | 330 | Execution |Specific Translation +------| and Management | | 331 | Environment | Functions | /| Systems | | 332 | +---------------------+ +----------------+ | 333 | | 334 +-------------------------------------------------------------------+ 336 Figure 1. SUPA Framework 338 Figure 1 is meant to be exemplary. The Operator actor shown in 339 Figure 1 can interact with SUPA in other ways not shown in the 340 Figure. In addition, other actors that can interact with SUPA were 341 not shown for simplicity. For example, an application developer 342 could build an application that uses the SUPA information and data 343 models to directly output configuration snippets. In addition, 344 other actors can use the SUPA framework. 346 SUPA defines an Event-Condition-Action (ECA) policy as an example 347 of imperative policies; it also defines two forms of declarative 348 policies using simple Propositional Logic and First Order Logic. 349 An ECA policy rule is activated when its event clause is true; 350 the condition clause is then evaluated and, if true, signals the 351 execution of one or more actions in the action clause. 353 In contrast, a declarative policy defines what actions to take, 354 but not how to execute them. Declarative policies in SUPA take the 355 form of a set of statements that present facts, and a conclusion 356 of those facts. 358 2.2. Operation 360 SUPA can be used to define various types of policies, including 361 policies that affect services and/or the configuration of 362 individual or groups of network elements. SUPA can be used by a 363 centralized and/or distributed set of entities that for creating, 364 managing, interacting with, and retiring policy rules. The Policy 365 Interface and SUPA Translation Function are two entities that make 366 up the Policy Management (PM) function. 368 The duties of the PM function depend on the type and nature of 369 policies being used. For example, imperative (e.g., ECA) policies 370 require conflict detection and resolution, while declarative 371 policies do not. A short exemplary list of functions that are 372 common to both types of policies include: 374 o policy creation, update, delete, and view functions 375 (typically in conjunction with policy repositories) 376 o policy storage, search, and retrieval (typically uses 377 distributed repositories that the PM communicates with) 378 o policy distribution (typically uses a message bus; note that 379 this involves requesting and responding to requests for 380 policy decisions as well as distributing policies and 381 inforing interested entities of policy results) 382 o making policy decisions (this SHOULD include more than 383 the simple Policy Decision Point functions defined in 384 [RFC3198]) 385 o executing policy decisions (this SHOULD include more than 386 the simple Policy Enforcement Point functions defined in 387 [RFC3198]) 388 o validating that the execution of the policy produced what 389 was expected (this is NOT defined in [RFC3198]). 391 An exemplary architecture that illustrates these concepts is shown 392 in [TR235]. 394 The SUPA scope is limited to policy information and data models. 395 SUPA will not define network resource data models, which is out 396 of scope. Similarly, SUPA will not define network service data 397 models, which is also out of scope. Instead, SUPA will make use 398 of network resource data models defined by other WGs or SDOs. 400 2.3. Generic Policy Information Model 402 The GPIM provides a common vocabulary for representing concepts 403 that are common to expressing different types of policy, but 404 which are independent of language, protocol, repository, and 405 level of abstraction. 407 This enables different policies at different levels of abstraction 408 to form a continuum, where more abstract policies can be translated 409 into more concrete policies, and vice-versa. For example, the 410 information model can be extended by generalizing concepts from an 411 existing data model into the GPIM; the GPIM extensions can then be 412 used by other data models. 414 SUPA will develop an information model for expressing policy at 415 different levels of abstraction. Specifically, three information 416 model fragments are envisioned: (i) a generic policy information 417 model (GPIM) that defines concepts needed by policy management 418 independent of the form and content of the policy, (ii) a more 419 specific information model that refines the GPIM to specify how 420 to build policy rules of the event-condition-action paradigm, and 421 (iii) a more specific information model that refines the GPIM to 422 specify how to build policy rules that declaratively specify what 423 goals to achieve (but not how to achieve those goals); this is 424 often called "intent-based" policy. These are all contained in 425 the Generic Policy Information Model block in Figure 1. 427 2.4. Refinement of the GPIM 429 An information model is abstract. As such, it cannot be directly 430 instantiated (i.e., objects cannot be created directly from it). 431 Therefore, SUPA translates its information model to two 432 different data models (which can be instantiated). 434 SUPA will translate the GPIM into concrete YANG data models that 435 define how to manage and communicate policies between systems. 436 Any number of imperative and/or declarative policy YANG data models 437 may be instantiated from the GPIM, and may be used separately or 438 in combination. This is enabled by the SUPA GPIM. 440 The two data models differ in how they represent policies. 441 However, they share common characteristics and behavior. 442 Therefore, it is easier to define a set of three information 443 models to represent the common, ECA, and declarative parts of a 444 policy. These three information models are then translated into 445 either a YANG ECA data model or a YANG declarative data model. 446 Note that because they share a common information model, they 447 can be used separately or together (e.g., a declarative policy 448 could call an ECA policy). This provides two different types 449 of abstractions that serve different use cases. It also helps 450 prove the genericity of the GPIM. 452 2.4.1. Event-Condition-Action Policy Information Model 454 The SUPA ECA Policy Rule Information Model (EPRIM) represents a 455 policy rule as a statement that consists of an event clause, a 456 condition clause, and an action clause. An ECA policy rule is 457 activated when its event clause is true; the condition clause is 458 then evaluated and, if true, signals the execution of one or more 459 actions in the action clause. This type of Policy Rule explicitly 460 defines the current and desired states of the system being managed. 462 2.4.2. Declarative Policy Information Model 464 The SUPA Logic Statement Information Model (LSIM) is a set of 465 (logic-based) propositions that form a (single) conclusion. A 466 proposition is a type of statement that is either TRUE or FALSE. 467 A proposition can be created from simpler propositions. This 468 version of the LSIM defines two forms of SUPA Logic Statements: 469 one using propositional logic, and one using first order logic. 471 3. Application of Generic Policy-based Management 473 This section provides examples of how SUPA can be used to 474 define different types of policies. Examples applied to various 475 domains, including system management, operations management, 476 access control, routing, and service function chaining, are 477 also included. 479 3.1. Declarative Examples 481 Declarative policies are policies that describe what to do, but 482 not how to do it. Declarative policies can apply to services 483 and/or resources. Here are some simple examples: 485 System and Operations Management Examples 487 All routers and switches must have password login disabled. 489 The above policy first resolves 'routers and switches' to a 490 set of network elements, and then pushes the appropriate 491 configuration to those network elements. 493 All SNMP agents must enable SNMPv3 and must disable all other 494 versions of SNMP. 496 The above policy can be mapped to the leafs v1, v2c, and v3 497 in the ietf-snmp YANG data model (RFC 7407). 499 All SNMP traffic is dropped unless it originates from, or 500 is directed to, an interface of a management system. 502 The above policy first resolves a management system interface 503 to a list of IP addresses, and then creates a set of suitable 504 ACL rules that are configured on all network elements. 506 Access to source code servers is limited to authorized 507 Intranet users. 509 The above policy assumes that the user is authenticated and 510 authorized to access the code server. It places an additional 511 constraint of requiring Intranet acces before granting access 512 to the resource. Note that this rule is not limited to any 513 one specific user or type of application. 515 Periodically perform workload consolidation if average CPU 516 utilization falls below X%. 518 This policy moves workloads on a set of source VMs to a 519 common target VM if the average CPU utilization for the CPUs 520 on the source VM is less than a predefined threshold. Note 521 that the policy did not specify which particular VM to move 522 the workload on the source VM to; that is part of the 523 search and optimization algorithms that are implied, but 524 not specified, by this policy. 526 Service Management Examples 528 Proactively monitor Gold Service users to ensure their SLAs 529 are not violated. 531 Gold Service is an aggregation of different traffic types, each 532 with different constraints. The policy will dynamically create 533 a service function chain based on the current context to ensure 534 that the customer's SLA is not violated. 536 Gold and Platinum Service Users must have WAN optimization 537 applied to multimedia applications. 539 The above policy applies only to multimedia applications for 540 users whose SLA types are either Gold or Platinum. It installs 541 a service chain that performs WAN optimization (and likely 542 content caching and other services) to ensure that the SLAs of 543 these users are not violated. 545 3.2. ECA Examples 547 ECA policies are statements that consist of an event clause, a 548 condition clause, and an action clause. 550 Network Service Management Example 552 Event: too many interface alarms received from an 553 L3VPN service 554 Condition: alarms resolve to the same interface within a 555 specified time period 556 Action: if error rate exceeds x% then put L3VPN service 557 to Error State and migrate users to one or more 558 new L3VPNs 560 Security Management Example 562 Event: anomalous traffic detected in network 563 Condition: determine the severity of the traffic 564 Action: apply one or more actions to affected NEs based 565 on the type of the traffic detected (along with 566 other factors, such as the type of resource 567 being attacked if the traffic is determined to 568 be an attack) 570 Traffic Management Examples 572 Event: edge link close to being overloaded by 573 incoming traffic 574 Condition: if link utilization exceeds Y% or if link 575 utilization average is increasing over a 576 specified time period 577 Action: change routing configuration to other peers 578 that have better metrics 580 Event: edge link close to be overloaded by 581 outgoing traffic 582 Condition: if link utilization exceeds Z% or if link 583 utilization average is increasing over a 584 specified time period 585 Action: reconfigure affected nodes to use source-based 586 routing to balance traffic across multiple links 588 Service Management Examples 590 Event: alarm received or periodic time period check 591 Condition: CPU utilization level comparison 592 Action: no violation: no action 593 violation: 594 1) determine workload profile in time interval 595 2) determine complementary workloads (e.g., 596 whose peaks are at different times in day) 597 3) combine workloads (e.g., using integer 598 programming) 600 Event: alarm received or periodic time check 601 Condition: if DSCP == AFxy and 602 throughput < T% or packet loss > P% 603 Action: no: no action 604 yes: remark to AFx'y'; reconfigure queuing; 605 configure shaping to S pps; ... 607 Note: it is possible to construct an ECA policy rule that is 608 directly tied to configuration parameters; this is in general 609 not possible for declarative policy. The value of declarative 610 policy is in expression of the goal of the policy, and the 611 freedom in implementing that goal. The value of ECA is in more 612 clearly specifying what needs to be done. 614 3.3. ECA plus Declarative Example 616 The fundamental reason that SUPA defines two different types of 617 policy rules is to enable different actors to express policy in 618 a manner conducive to their roles. The SGPIM defines concepts 619 that are common to both the EPRIM and the SLSIM. This enables 620 these two types of policies to be used together to provide a 621 more powerful definition of the goals of the policy as well as 622 how to implement those goals. 624 For example, compare the ECA and declarative forms of the SLA 625 Service Management Policy: 627 Declarative form: 628 Proactively monitor Gold Service users to ensure their SLAs 629 are not violated. 631 ECA form: 632 Event: alarm received or periodic time check 633 Condition: if DSCP == AFxy and 634 throughput < T% or packet loss > P% 635 Action: no: no action 636 yes: remark to AFx'y'; reconfigure queuing; 637 configure shaping to S pps; ... 639 The declarative policy is more abstract than its ECA counterpart, 640 since the declarative version expresses intent without defining 641 which specific network elements are affected and how the 642 configuration of those network elements should be changed. The 643 above ECA policy rule is written in a high-level form, but note 644 that it still is specifying how to monitor the Gold Service, how 645 to determine if the SLA is being violated, and which actions to 646 take. 648 The execution of the declarative example could result in one or 649 more ECA policy rules being triggered, such as the one above. 650 Similarly, an ECA policy rule could trigger additional ECA policy 651 rules to be evaluated. For example, the above ECA rule could be 652 rewritten so that if the condition was satisfied, then each of 653 the actions shown could be their own policy rules. This provides 654 additional flexibility through reusing policy rules and the 655 components of policy rules. 657 4. Related Work 659 4.1. Related Work within the IETF 661 4.1.1. I2RS Working Group 663 I2RS defines an interface that interacts with the routing 664 system using a collection of protocol-based control or 665 management interfaces. Users of I2RS interfaces are typically 666 management applications and controllers. SUPA does not directly 667 interface to the routing system. Rather, SUPA uses data 668 produced by I2RS (e.g., topological information) to construct 669 its policies. 671 4.1.2. L3SM Working Group 673 L3SM defines an L3 VPN service model that can be used for 674 communication between customers and network operators. This 675 model enables an orchestration application or customers to 676 request network services provided by L3 VPN technologies. The 677 implementation of network services is often guided by specific 678 policies, and SUPA provides a tool that can help with the 679 mapping of L3 VPN service requests to L3 VPN configurations of 680 network elements. 682 4.1.3. ALTO Working Group 684 The ALTO working group defined an architecture for exposing 685 topology information, more specifically the cost of paths 686 through an infrastructure, as defined in [RFC7285]. ALTO 687 services are able to provide network maps defined as groups of 688 endpoints, and can therefore represent any granularity of network, 689 from the physical to groups of networks following similar paths or 690 restraints. Although this model can represent different levels of 691 granularities, it is not clear if it could be adapted easily for 692 other purposes than providing cost maps in the context of ALTO. 693 The ALTO model is meant to be used outside of the trust domain of 694 an ISP by external clients. 696 SUPA does not generate data that is similar to ALTO. Rather, 697 SUPA could use ALTO data as part of its policies to configure 698 services and/or resources. 700 4.1.4. TEAS Working Group 702 The Traffic Engineering Architecture and Signaling (TEAS) 703 working group is responsible for defining MPLS- and GMPLS-based 704 Traffic Engineering architectures that enable operators to 705 control how specific traffic flows are treated within their 706 networks. It covers YANG models for a traffic engineering 707 database. In coordination with other working groups (I2RS) 708 providing YANG models for network topologies. 710 Both TEAS and SUPA use YANG data models. SUPA does not generate 711 traffic engineering (TE) data. However, SUPA could use TE data 712 as part of its policies for configuring resources and/or 713 services. SUPA could also define policies that define which 714 service, path, and link properties to use for a given customer, 715 and consequently, which protocol extensions to use. TEAS data 716 could also be used to enable operators to define how particular 717 traffic flows are treated in a more abstract (but still 718 consistent) manner. 720 4.1.5. BESS Working Group 722 The BGP Enabled Services (BESS) working group defines and 723 extends network services that are based on BGP. This includes 724 BGP/MPLS IP provider-provisioned L3VPNs, L2VPNs, BGP-enabled 725 VPN solutions for use in data center networking, and extensions 726 to BGP-enabled solutions to construct virtual topologies in 727 support of services such as Service Function Chaining. The 728 working group is also chartered to work on BGP extensions to 729 YANG models and data models for BGP-enabled services. 731 Both BESS and SUPA use YANG data models. SUPA could generate 732 BGP configurations by using data defined by BESS as part of 733 its policies for configuring resources and/or services. 735 SUPA could also define policies that govern different aspects 736 of services defined by BESS. 738 4.1.6. SFC Working Group 740 The Service Function Chaining (SFC) working group defines a 741 mechanism where traffic is classified; that classification is 742 then use to select an ordered set of services to pass the 743 traffic through. 745 Both SFC and SUPA use YANG data models. SUPA could define 746 policies that augment the functionality of SFC in several 747 different ways, including: (1) path selection based on context, 748 (2) which set of mechanisms to use to steer traffic through 749 which set of service functions, (3) simplify the definition of 750 dynamic service function chains (e.g., service paths that 751 change based upon a set of data that is discovered at runtime), 752 and (4) scalable mechanisms to monitor and control the 753 configuration of SFC components. 755 4.1.7. NVO3 Working Group 757 The NVO3 group proposes a way to virtualize the network edge 758 for data centers in order to be able to move virtual instances 759 without impacting their network configuration. This is realized 760 through a centrally controlled overlay layer-3 network. The 761 NVO3 work is not about defining policy information; rather, it 762 uses policy information to perform some functions. Both NVO3 and 763 SUPA use YANG data models. SUPA could define policies that define 764 how the logically centralized network virtualization management 765 entity (or entities) of NVO3 behave (e.g., the functions in the 766 network virtualization control plane). 768 4.1.8. ACTN BoF (IETF-90) 770 The ACTN proposed work, as described in [actn] framework, has 771 two main goals, the abstraction of multiple optical transport 772 domains into a single controller offering a common abstract 773 topology, and the splitting of that topology into abstract 774 client views that are usually a fraction of the complete 775 network. The ACTN work is therefore about unification of 776 several physical controllers into a virtual one, and also about 777 the segmentation, isolation and sharing of network resources. 778 The ACTN work is not about defining policy information. Both ACTN 779 and SUPA use YANG data models. SUPA could define policies that 780 define the behavior of the controller. 782 4.1.9. Previous IETF Policy Models 784 SUPA is technology-neutral, previous RFCs weren't. SUPA defines a 785 common structure from which both ECA and declarative policies can 786 be defined and combined; this was not possible in previous RFCs. 787 Previous RFCs do NOT define metadata, and do NOT enable policies 788 to formally define obligation, permission, and related concepts. 789 Finally, SUPA uses software patterns, which previous RFCs didn't. 791 4.2. Related Work outside the IETF 793 4.2.1. TM Forum 795 The TM Forum (a.k.a., the TeleManagement Forum) develops 796 standards and best practices, research, and collaborative 797 programs focused on digital business transformation. It 798 consists of three major programs: 800 1) Agile Business and IT 801 2) Customer Centricity (experience) 802 3) Open Digital Ecosystem 804 Of these, the ZOOM (Zero-touch Orchestration, Operations, and 805 Management) project, located in the Agile Business and IT 806 project, is the main sub-project in this area that is of 807 interest to SUPA. 809 Within ZOOM, the Foundational Studies project contains work on 810 an information model and management architecture that are 811 directly relevant to SUPA. The TMF Information Model, Policy, 812 and Security working groups are involved in this work. 814 The ZOOM information model updates the existing Shared 815 Information and Data (SID) information model to add support for 816 the management of physical and virtual infrastructure, event- 817 and data-driven systems, policy management (architecture and 818 model), metadata for describing and prescribing behavior that can 819 support changes at runtime, and access control. The policy 820 information model defines imperative (ECA), declarative (intent- 821 based), utility function, and promise policies. The work in 822 [ID.draft-strassner-supa-generic-policy-info-model] is based on 823 this work. It currently extends the ZOOM ECA model and provides 824 additional detail not currently present in ZOOM; the next version 825 of this draft will do the same for declarative policies. 827 There is currently no plan to use the utility function and 828 promise policies of ZOOM in SUPA. Finally, it should be noted 829 that the data model work planned for SUPA is not currently 830 planned for the ZOOM project. 832 4.2.2. MEF 834 The MEF (originally named the Metro Ethernet Forum) develops 835 architecture, service and management specifications related to 836 Carrier Ethernet (CE). The CE architecture includes the 837 definition of several interfaces specific to CE like the User 838 Network Interface (UNI) and External Network Network Interface 839 (ENNI). Specifications developed in this space include the 840 definitions of CE services, CE service attributes, Ethernet 841 Access Services, Class of Service, OAM and Management 842 interfaces, Service Activation and Test. The more recent vision of 843 the MEF is described as The Third Network, and includes plans to 844 develop Lifecycle Service Orchestration with APIs for existing 845 network, NFV, and SDN implementations enabling Agile, Assured, 846 and Orchestrated Services. This stage of the MEF activity is now 847 in early phases with focus on architectural work. 849 The MEF has developed a number of Information and Data Models, 850 and has recently started a project that used YANG to model and 851 manage the services defined by the MEF. While the MEF has created 852 rigorous definitions of these services, they are specific to 853 transport technology, and they do not include and rely on policies. 855 4.2.3. Open Daylight 857 Open Daylight network controller implements a number of models 858 through its service abstraction Layer (MD-SAL) based on draft 859 IETF Yang models. Open Daylight is an open source project. Two of 860 these are relevant to SUPA, and are described below. 862 4.2.3.1. Network Intent Composition (NIC) 864 The Network Intent Composition project aims at providing better 865 flexibility by using declarative policies. It does not cover 866 other types of policies, such as ECA policy rules. The intent- 867 based interface aims to provide a high level of abstraction, 868 primarily for use by an application developer. Its progress 869 has recently stalled. 871 4.2.3.2. Group Based Policy 873 The Group Based Policy project defines an application-centric 874 policy model for Open Daylight that separates information about 875 application connectivity requirements from information about 876 the underlying details of the network infrastructure. The model 877 is positioned as declarative, but uses a relational approach to 878 specifying policy. 880 4.2.4. Open Networking Foundation 882 The ONF created a group responsible of defining northbound 883 interfaces, but this hasn't lead to the publication of 884 standards in this area so far. A blog entry on the ONF web site 885 showed an interest in using the principle of intents at ONF, 886 but no details were provided on the status of this project. A 887 members-only whitepaper was recently published. 889 4.2.5. OpenStack 891 OpenStack software controls large pools of compute, storage, 892 and networking resources throughout a datacenter, managed 893 through a dashboard or via the OpenStack API. OpenStack works 894 with popular enterprise and open source technologies making it 895 ideal for heterogeneous infrastructure. Few of the below 896 mentioned OpenStack projects provides policy abstraction and 897 better flexibility to the user. 899 4.2.5.1. Group-Based Policy 901 The Group-Based Policy project for OpenStack Neutron is built 902 around entities assembled in Endpoints Groups (EPG) that 903 provide or consume Contracts. Such Contracts are hierarchical 904 entities containing policy rules. A first version was released 905 in January 2015, based on the Juno release. This type of 906 approach is more relational than declarative, but could be used 907 to describe a large amount of possible scenarios. It has the 908 advantage of providing a relatively simple policy model that 909 covers a large applicability. From an OpenStack point of view, 910 the scope of Group-Based Policies is limited to networking 911 within the Neutron module. 913 4.2.5.2. Congress 915 The Congress project within OpenStack provides a way to define 916 complex policies using extensions to the Datalog language. 917 Datalog is entirely declarative, and its evaluation is based on 918 first-order logic with restrictions. This gives it interesting 919 properties, such as providing the same result no matter the order 920 in which the statements are made. The language allows for the 921 definition of types and for active enforcement or verification 922 of the policies. 924 There is a significant body of knowledge and experience relating 925 to declarative languages and their implementation. Congress 926 policies aim at manipulating objects exposed by multiple 927 OpenStack modules, and is therefore larger in scope than network 928 element policies. 930 The declarative policies of SUPA are similar to those in Congress; 931 the primary difference relies in the characteristics and behavior 932 (in the sense of restrictions) of the underlying logic for 933 Congress vs. SUPA. SUPA's propositional logic statements are 934 simpler but more limited than Congress, while SUPA's first-order 935 logic statements are more complex but more powerful than those 936 of Congress. If desired, a Congress model could be easily added 937 to SUPA. 939 4.2.6. The NEMO Project (not a BoF yet) 941 The NEMO project is a research activity aimed at defining a 942 simple framework for "intent-based" networking. This project 943 concentrates on creating a domain-specific language and associated 944 API, not a model or even a rigorous definition of what a policy 945 rule is. 947 The NEMO syntax defines a very simple information model that has 948 three basic elements for network manipulation: nodes, links, and 949 flows. A policy rule is NOT defined in this model. Rather, policy 950 is defined as a command. The NEMO project has been successfully 951 demonstrated at IETF-91, along with a companion graphical user 952 interface. 954 NEMO declarative policies are different than SUPA declarative 955 policies. NEMO uses a flatter, simpler object model with fewer 956 objects to represent targets of policy. NEMO does not define a 957 policy model, and does not support ECA policies. NEMO uses a 958 condition-action paradigm to execute its declarative policies. In 959 contrast, SUPA uses a richer class model to represent ECA and 960 declarative policies. SUPA declarative policies are executed using 961 formal logic. SUPA has not proposed a language. 963 4.2.7. The Floodlight Project 965 The Floodlight is an OpenFlow-enabled SDN controller. It uses 966 another open source project called Indigo to support OpenFlow 967 and manage southbound devices. The Indigo agent also supports 968 an abstraction layer to make it easy to integrate with physical 969 and virtual switches. It supports configuration of an abstraction 970 layer so that it can configure OpenFlow in hybrid mode. 972 4.2.8. The ONOS Project 974 The ONOS is an SDN controller design for Service Provider networks. 975 It uses a distributed architecture, and supports abstraction for 976 both southbound and northbound interfaces. Its modules are managed 977 as OSGi bundles. It is an open source project. 979 ONOS announced an "application-intent framework", which is similar 980 in nature to SUPA's declarative policies. However, no object model 981 or language has been defined yet. 983 5. Conclusions: the Value of SUPA 985 SUPA) defines an interface to a network management function that 986 takes high-level, possibly network-wide policies as input and 987 creates element configuration snippets as output. SUPA expresses 988 policies using a generic policy information model, and produces 989 generic policy YANG data models. SUPA focuses on management 990 policies that control the configuration of network elements. 991 Management policies can be interpreted outside of network 992 elements, and the interpretation typically results in 993 configuration changes of collections of network elements. 995 Policies embedded in the configuration of network elements are 996 not in the scope of SUPA. In contrast to policies targeted by 997 SUPA, embedded policies are usually interpreted on network 998 elements in isolation, and often at timescales that require the 999 representation of embedded policies to be optimized for a 1000 specific purpose. 1002 The SUPA information model generalizes common concepts from 1003 multiple technology-specific data models, and makes it reusable. 1004 Conceptually, SUPA can be used to interface and manage existing 1005 and future data models produced by other IETF working groups. 1006 In addition, by defining an object-oriented information model 1007 with metdata, the characteristics and behavior of data models 1008 can be better defined. 1010 6. Security Considerations 1012 TBD. 1014 7. IANA Considerations 1016 This document has no actions for IANA. 1018 8. Contributors 1020 The following people all contributed to creating this document: 1022 Jun Bi, Tsinghua University 1023 Vikram Choudhary, Huawei Technologies 1024 Luis M. Contreras, Telefonica I+D 1025 Georgios Karagiannis, Huawei Technologies 1026 Hosnieh Rafiee, Huawei Technologies Duesseldorf GmbH 1027 Dan Romascanu, Avaya 1028 Jon Saperia, JDS Consulting 1029 J. Schoenwaelder, Jacobs University, Germany 1030 Qiong Sun, China Telecom 1031 Parviz Yegani, Juniper Networks 1032 Cathy Zhou, Huawei Technologies 1034 9. Acknowledgments 1036 This document has benefited from reviews, suggestions, comments 1037 and proposed text provided by the following members, listed in 1038 alphabetical order: J. Bi, Luis M. Contreras, G. Karagiannis, D. 1039 Romascanu, J. Saperia, J. Schoenwaelder, Q. Sun, P. Yegani, and 1040 C. Zhou. 1042 10. References 1044 10.1. Informative References 1046 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 1047 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., 1048 Perry, J., Waldbusser, S., "Terminology for Policy-Based 1049 Management", RFC 3198, November, 2001 1051 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for 1052 the Network Configuration Protocol (NETCONF)", RFC 6020, 1053 October 2010. 1055 [RFC6991] J. Schoenwaelder, "Common YANG Data Types", July 2013 1057 [RFC6241] R. Enns, M. Bjorklund, J. Schoenwaelder, A. Bierman, 1058 "Network Configuration Protocol (NETCONF)", June 2011 1060 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. 1061 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic 1062 Optimization (ALTO) Protocol", September 2014 1063 [SUPA-framework] C. Zhou, L. M. Contreras, Q. Sun, and P. 1064 Yegani, " The Framework of Simplified Use of Policy 1065 Abstractions (SUPA) ", IETF Internet draft, draft-zhou-supa- 1066 framework, February 2015. 1068 [SUPA-problem-statement] G. Karagiannis, Q. Sun, Luis M. 1069 Contreras, P. Yegani, JF Tremblay and J. Bi, "Problem Statement 1070 for Simplified Use of Policy Abstractions (SUPA)", IETF 1071 Internet draft, draft-karagiannis-supa-problem-statement, 1072 January 2015. 1074 [SUPA-gap-analysis] J. Bi, H.Rafiee, V,Choudhary, J.Strassner, 1075 D.Romascanu "Simplified Use of Policy Abstractions (SUPA) Gap 1076 Analysis", IETF Internet draft, draft-bi-supa-gap-analysis, May 1077 2015. 1079 [SUPA-DDC] Y. Cheng, and JF. Tremblay, "Use Cases for 1080 Distributed Data Center Applications in SUPA", IETF Internet 1081 draft, draft-cheng-supa-ddc-use-cases, January 2015 1083 [RaBe11] Raphael Romeikat, Bernhard Bauer, "Formal 1084 Specification of DomainSpecific ECA Policy Models", in Proc. 1085 2011 Fifth IEEE International Conference on Theoretical Aspects 1086 of Software Engineering, 2011 1088 [Stras02] John Strassner, "DEN-ng: Achieving Business-Driven 1089 Network Management" in Proc. IEEE Network Operations and 1090 Management Symposium (NOMS), 2002. 1092 [TR235] John Strassner, ed., "ZOOM Policy Architecture and 1093 Information Model Snapshot", TR245, part of the TM Forum ZOOM 1094 project, October 26, 2014 1096 Authors' Addresses 1098 Maxim Klyus, Ed. 1099 NetCracker 1100 Kozhevnicheskaya str.,7 Bldg. #1 1101 Moscow, Russia 1102 Phone: +7-916-8575717 1103 E-mail: klyus@netcracker.com 1105 John Strassner, Ed. 1106 Huawei Technologies 1107 2330 Central Expressway 1108 Santa Clara, CA 95138 USA 1109 Email: john.sc.strassner@huawei.com