idnits 2.17.1 draft-klyus-supa-value-proposition-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 92 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (Mar 21, 2016) is 2930 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) == Unused Reference: 'RFC2119' is defined on line 936, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-strassner-supa-generic-policy-info-model-04 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 21, 2016 W. Liu 5 G. Karagiannis 6 Huawei Technologies 7 J. Bi 8 Tsinghua University 9 Mar 21, 2016 11 SUPA Value Proposition 12 draft-klyus-supa-value-proposition-00 14 Abstract 16 Simplified Use of Policy Abstractions (SUPA) defines a set of rules 17 that define how services are designed, delivered, and operated 18 within an operator's environment independent of any one particular 19 service or networking device. SUPA expresses policy rules using a 20 generic policy information model, which serves as a unifying 21 influence to enable different data model implementations to be 22 simultaneously developed. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet 30 Engineering Task Force (IETF), its areas, and its working 31 groups. Note that other groups may also distribute working 32 documents as Internet-Drafts. 34 Internet-Drafts are working documents of the Internet 35 Engineering Task Force (IETF). Note that other groups may also 36 distribute working documents as Internet-Drafts. The list of 37 current Internet-Drafts is at 38 http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other 42 documents at any time. It is inappropriate to use Internet- 43 Drafts as reference material or to cite them other than as 44 "work in progress." 46 Copyright Notice 48 Copyright (c) 2015 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 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described 58 in Section 4.e of the Trust Legal Provisions and are provided 59 without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................3 64 1.1. Problem Statement.........................................4 65 1.2. Proposed Solution.........................................4 66 1.3. Value of the SUPA Approach ...............................5 67 2. Framework for Generic Policy-based Management..................6 68 2.1. Overview..................................................6 69 2.2. Operation.................................................8 70 2.3. The GPIM and the EPRIM ...................................9 71 2.4. Creation of Generic YANG Modules .........................9 72 3. Application of Generic Policy-based Management................10 73 3.1. ECA Examples.............................................10 74 4. Related Work..................................................11 75 4.1. Related Work within the IETF.............................11 76 4.1.1. I2RS Working Group..................................11 77 4.1.2. L3SM Working Group..................................11 78 4.1.3. ALTO Working Group..................................12 79 4.1.4. TEAS Working Group..................................12 80 4.1.5. BESS Working Group..................................12 81 4.1.6. SFC Working Group...................................13 82 4.1.7. NVO3 Working Group..................................13 83 4.1.8. ACTN BoF (IETF-90)..................................13 84 4.1.9. Previous IETF Policy Models.........................14 85 4.2. Related Work outside the IETF............................14 86 4.2.1. TM Forum............................................14 87 4.2.2. MEF.................................................15 88 4.2.3. Open Daylight.......................................15 89 4.2.4. Open Networking Foundation..........................16 90 4.2.5. OpenStack...........................................16 91 4.2.6. The NEMO Project (Not a BoF Yet)....................17 92 4.2.7. The Floodlight Project..............................17 93 4.2.8. The ONOS Project....................................17 94 5. Conclusions - Value of SUPA...................................17 95 6. Security Considerations.......................................18 96 7. IANA Considerations...........................................18 97 8. Contributors..................................................18 98 9. Acknowledgments...............................................18 99 10. References...................................................19 100 10.1. Informative References..................................19 101 Authors' Addresses ..............................................20 103 1. Introduction 105 The rapid growth in the variety and importance of traffic flowing 106 over increasingly complex enterprise and service provider network 107 architectures makes the task of network operations and management 108 applications and deploying new services much more difficult. In 109 addition, network operators want to deploy new services quickly 110 and efficiently. Two possible mechanisms for dealing with this 111 growing difficulty are the use of software abstractions to 112 simplify the design and configuration of monitoring and control 113 operations and the use of programmatic control over the 114 configuration and operation of such networks. Policy-based 115 management can be used to combine these two mechanisms into an 116 extensible framework. 118 Policy rules can be used to express high-level network operator 119 requirements directly, or from a set of management applications, 120 to a network management or element system. The network management 121 or element system can then control the configuration and/or 122 monitoring of network elements and services. 124 Simplified Use of Policy Abstractions (SUPA) will define a generic 125 policy information model (GPIM) [SUPA-info-model] for use in network 126 operations and management applications. The GPIM defines concepts 127 and terminology needed by policy management indepednent of the form 128 and content of the policy rule. The ECA Policy Rule Information 129 Model (EPRIM) [SUPA-info-model] extends the GPIM to define how to 130 build policy rules according to the event-condition-action paradigm. 132 Both the GPIM and the EPRIM are targeted at controlling the 133 configuration and monitoring of network elements throughout the 134 service development and deployment lifecycle. The GPIM and the EPRIM 135 will both be translated into corresponding YANG [RFC6020] modules 136 that define policy concepts, terminology, and rules in a generic and 137 interoperable manner; additional YANG modules may also be defined 138 from the GPIM and/or EPRIM to manage specific functions. 140 The key benefit of policy management is that it enables different 141 network elements and services to be instructed to behave the same 142 way, even if they are programmed differently. Management 143 applications will benefit from using policy rules that enable 144 scalable and consistent programmatic control over the 145 configuration and monitoring of network elements and services. 147 1.1. Problem Statement 149 Network operators must construct networks of increasing size 150 and complexity in order to improve their availability and 151 quality, as more and more business services depend on them. 153 Currently, different technologies and network elements require 154 different forms of the same policy that governs the production of 155 network configuration snippets. The power of policy management is 156 its applicability to many different types of systems, services, 157 and networking devices. This provides significant improvements in 158 configuration agility, error detection, and uptime for operators. 160 Many different types of actors can be identified that can use a 161 policy management system, including applications, end-users, 162 developers, network administrators, and operators. Each of these 163 actors typically has different skills and uses different concepts 164 and terminologies. For example, an operator may want to express 165 that only Platinum and Gold users can use streaming and interactive 166 multimedia applications. As a second example, an operator may want 167 to define a more concrete policy rule that looks at the number of 168 dropped packets. If, for example, this number exceeds a certain 169 threshold value, then the applied queuing, dropping and 170 scheduling algorithms could be changed in order to reduce the 171 number of dropped packets. The power of SUPA is that both of these 172 examples may be abstracted. For example, in the latter example, 173 different thresholds and algorithms could be defined for different 174 classes of service. 176 1.2. Proposed Solution 178 SUPA enables network operators to express policies to control 179 network configuration and monitoring data models in a generic 180 manner. The configuration and monitoring processes are independent 181 of device, as well as domain or type of application, and result in 182 configuration according to YANG data models. 184 Both of the examples in section 1.1 can be referred to as "policy 185 rules", but they take very different forms, since they are defined 186 at different levels of abstraction and likely authored by different 187 actors. The first example described a very abstract policy rule, and 188 did not contain any technology-specific terms, while the second 189 example included more concrete policy rules and likely used 190 technical terms of a general (e.g., IP address range and port 191 numbers) as well as vendor-specific nature (e.g., specific 192 algorithms implemented in a particular device). Furthermore, 193 these two policy rules could affect each other. For example, 194 Gold and Platinum users might need different device 195 configurations to give the proper QoS markings to their 196 streaming multimedia traffic. This is very difficult to do if a 197 common policy framework does not exist. 199 Note that SUPA is not limited to any one type of technology. 200 While the above two policies could be considered "QoS" 201 policies, other examples include: 203 - network elements must not accept passwords for logins 205 - all SNMP agents in this network must drop all SNMP traffic 206 unless it is originating from, or targeting, the 207 management network 209 - Periodically perform workload consolidation if average CPU 210 utilization falls below X% 212 The above three examples are not QoS related; this emphasizes the 213 utility of the SUPA approach in being able to provide policies 214 to control different types of network element configuration and/or 215 monitoring snippets. 217 There are many types of policies. SUPA differentiates between 218 "management policies" and "embedded policies". Management 219 policies are used to control the configuration of network 220 elements. Management policies can be interpreted externally to 221 network elements, and the interpretation typically results in 222 configuration changes of collections of network elements. In 223 contrast, "embedded policies" are policies that are embedded 224 in the configuration of network elements, and are usually 225 interpreted on network elements in isolation. Since embedded 226 policies are interpreted in the network device, they are 227 typically composed in a very specific fashion to run at 228 near-realtime timescales. 230 1.3. Value of the SUPA Approach 232 SUPA will achieve an optimization and reduction in the amount of 233 work required to define and implement policy-based data models in 234 the IETF. This is due to the generic and extensible framework 235 provided by SUPA. 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 (i.e., management 241 policies). Hence, SUPA policies can be used to define the behavior 242 of and interaction between embedded policies. 244 Since the GPIM defines common policy terminology and concepts, it 245 can be used to both define more specific policies as part of a 246 data model as well as derive a (more abstract) information model 247 from a (more specific) data model. 249 This latter approach may be of use in discovering common structures 250 that occur in data models that have been designed in isolation of 251 each other. 253 The SUPA policy framework defines a set of consistent, flexible, 254 and scalable mechanisms for monitoring and controlling resources 255 and services. It may be used to create a management and operations 256 interface that can enable existing IETF data models, such as those 257 from I2RS and L3SM, to be managed in a unified way that is 258 independent of application domain, technology and vendor. Resource 259 and service management become more effective, because policy 260 defines the context that different operations, such as configuration 261 and monitoring, are applied to. 263 2. Framework for Generic Policy-based Management 265 This section briefly describes the design and operation of the 266 SUPA policy-based management framework. 268 2.1. Overview 270 Figure 1 shows a simplified functional architecture of how SUPA is 271 used to define policies for creating network element configuration 272 and monitoring snippets. SUPA uses the GPIM to define a consensual 273 vocabulary that different actors can use to interact with network 274 elements and services. The EPRIM defines a generic structure for 275 imperative policies. The GPIM, as well as the combination of the 276 GPIM and EPRIM, are converted to generic YANG data modules. The 277 IETF produces the modules, and IANA is used to register the module 278 and changes to it. 280 In the preferred approach, SUPA generic policy data modules are 281 then used to create vendor- and technology-specific data models. 282 These define the specific elements that will be controlled by 283 policies. The Policy Interface uses this information to create 284 appropriate input mechanisms for the operator to define policies 285 (e.g., a web form or a script) for creating and managing the 286 network configuration. The operator interacts with the interface, 287 which is then translated to configuration snippets. Note that the 288 policy interface is NOT being designed in SUPA. 290 In one of possibly several alternate approaches (shown with 291 asterisks in Figure 1), the SUPA generic policy YANG data modules 292 contain enough information for the Policy Interface to create 293 appropriate input mechanisms for the operator to define policies. 294 This transfers the work of building vendor- and technology-specific 295 data models to the SUPA Data Model-Specific Translation Function. 296 In either case, the output may then either be used as is, or goals 297 through a subsequent set of transformations before it is ready to 298 be consumed by the target device or management system. 300 +---------------------+ 301 +----------+ \| SUPA Generic Policy | 302 | IETF |---+----| Information Model | 303 +----------+ | /| | 304 | +---------+-----------+ 305 | | 306 Assignments | | Defines Policy Concepts 307 and Manage | | 308 Content | \|/ 309 | +---------+-----------+ Preferred 310 | \| SUPA GPIM and EPRIM | Approach 311 +----| Generic YANG |------------+ 312 /| Data Modules | | 313 +---------+-----------+ | 314 * | 315 * Possible | 316 * Approach | 317 * | 318 +--------------------------------+------------------------+---------+ 319 | Management System * | | 320 | * | | 321 | \*/ \|/ | 322 | Fills +----------+----------+ +--------|------+ | 323 | +--------+ Forms \| Policy Interface |/ |Technology and | | 324 | |Operator|----------| (locally defined +----|Vendor-specific| | 325 | +--------+ Runs /| forms, scripts,...) |\ | Data Models | | 326 | Scripts +----------+----------+ +-------+-------+ | 327 | /| \ | 328 | | | 329 | | Produces Policy Rules | 330 | | | 331 | \|/ | 332 | +----------+--------+ | 333 | | Policy Management | | 334 | | Functions | | 335 | +----------+--------+ | 336 | | | 337 | | | 338 | +---------------------+ | 339 | Optional Additional | | | 340 | Transformation \|/ \|/ | 341 | +---------------+-------+ +-------+--------+ | 342 | Local SUPA | YANG-to-device and/or | \| Local Devices | | 343 | Execution | Technology-Specific +-----+ and Management | | 344 | Environment | Translation Functions | /| Systems | | 345 | +-----------------------+ +----------------+ | 346 | | 347 +-------------------------------------------------------------------+ 349 Figure 1. SUPA Framework 351 Figure 1 is exemplary. The Operator actor shown in Figure 1 can 352 interact with SUPA in other ways not shown in Figure 1. In addition, 353 other actors (e.g., an application developer) that can interact with 354 SUPA are not shown for simplicity. 356 The EPRIM defines an Event-Condition-Action (ECA) policy as an 357 example of imperative policies. An ECA policy rule is activated 358 when its event clause is true; the condition clause is then 359 evaluated and, if true, signals the execution of one or more 360 actions in the action clause. Imperative policy rules require 361 additional management functions, which is explained in section 362 2.2 below. 364 2.2. Operation 366 SUPA can be used to define various types of policies, including 367 policies that affect services and/or the configuration of 368 individual or groups of network elements. SUPA can be used by a 369 centralized and/or distributed set of entities for creating, 370 managing, interacting with, and retiring policy rules. 372 The duties of the Policy Management Function (PMF) depend on the 373 type and nature of policies being used. For example, imperative 374 (e.g., ECA) policies require conflict detection and resolution, 375 while declarative policies do not. A short exemplary list of 376 functions that are common to many types of policies include: 378 o policy creation, update, delete, and view functions 379 (typically in conjunction with policy repositories) 380 o policy storage, search, and retrieval (typically uses 381 distributed repositories that the PMF communicates with) 382 o policy distribution (typically uses a message bus; note that 383 this involves requesting and responding to requests for 384 policy decisions as well as distributing policies and 385 informing interested entities of policy results) 386 o making policy decisions (this SHOULD include more than the 387 simple Policy Decision Point function defined in [RFC3198]) 388 o executing policy decisions (this SHOULD include more than the 389 simple Policy Enforcement Point functions defined in [RFC3198]) 390 o validating that the execution of the policy produced what 391 was expected (this is NOT defined in [RFC3198]). 393 An exemplary architecture that illustrates these concepts is shown 394 in [TR235]. 396 The SUPA scope is limited to policy information and data models. 397 SUPA will not define network resource data models or network 398 service data models; both are out of scope. Instead, SUPA will make 399 use of network resource data models defined by other WGs or SDOs. 401 Declarative policies that specify the goals to achieve but not 402 how to achieve those goals (also called "intent-based" policies) 403 are out of scope for the initial phase of SUPA. 405 2.3. The GPIM and the EPRIM 407 The GPIM provides a common vocabulary for representing concepts 408 that are common to expressing different types of policy, but 409 which are independent of language, protocol, repository, and 410 level of abstraction. 412 This enables different policies at different levels of abstraction 413 to form a continuum, where more abstract policies can be translated 414 into more concrete policies, and vice-versa. For example, the 415 information model can be extended by generalizing concepts from an 416 existing data model into the GPIM; the GPIM extensions can then be 417 used by other data models. 419 The SUPA working group develops models for expressing policy at 420 different levels of abstraction. Specifically, two models are 421 envisioned (both of which are contained in the Generic Policy 422 Information Model block in Figure 1: 424 (i) a generic model (the GPIM) that defines concepts and vocabulary 425 needed by policy management systems independent of the form and 426 content of the policy 428 (ii) a more specific model (the EPRIM) that refines the GPIM to 429 specify policy rules in an event-condition-action form 431 2.4. Creation of Generic YANG Modules 433 An information model is abstract. As such, it cannot be directly 434 instantiated (i.e., objects cannot be created directly from it). 435 Therefore, both the GPIM, as well as the combination of the GPIM 436 and the EPRIM, are translated to generic YANG modules. 438 SUPA will provide guidelines for translating the GPIM (or the 439 combination of the GPIM and the EPRIM) into concrete YANG data models 440 that define how to manage and communicate policies between systems. 441 Multiple imperative policy YANG data models may be instantiated 442 from the GPIM (or the combination of the GPIM and the EPRIM). In 443 particular, SUPA will specify a set of YANG data models that will 444 consist of a base policy model for representing policy management 445 concepts independent of the type or structure of a policy, and as 446 well, an extension for defining policy rules according to the ECA 447 paradigm. 449 The process of developing the GPIM, EPRIM and the derived/translated 450 YANG data models is realized following the sequence shown below. 451 After completing this process and if the implementation of the YANG 452 data models requires it, the GPIM and EPRIM and the 453 derived/translated YANG data models are updated and synchronized. 455 (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1') 457 Where, (1)=GPIM; (2)=EPRIM; (3)YANG data models; 458 (4) Implementation; (3')= update of YANG data models; 459 (2')=update of EPRIM; (1') = update of GPIM 461 The YANG module derived from the GPIM contains concepts and 462 terminology for the common operation and administration of 463 policy-based systems, as well as an extensible structure for 464 policy rules of different paradigms. The YANG module derived from 465 the EPRIM extends the generic nature of the GPIM to represent 466 policies using an event-condition-action structure. 468 3. Application of Generic Policy-based Management 470 This section provides examples of how SUPA can be used to define 471 different types of policies. Examples applied to various domains, 472 including system management, operations management, access control, 473 routing, and service function chaining, are also included. 475 3.1. ECA Examples 477 ECA policies are rules that consist of an event clause, a condition 478 clause, and an action clause. 480 Network Service Management Example 482 Event: too many interface alarms received from an 483 L3VPN service 484 Condition: alarms resolve to the same interface within a 485 specified time period 486 Action: if error rate exceeds x% then put L3VPN service 487 to Error State and migrate users to one or more 488 new L3VPNs 490 Security Management Example 492 Event: anomalous traffic detected in network 493 Condition: determine the severity of the traffic 494 Action: apply one or more actions to affected NEs based 495 on the type of the traffic detected (along with 496 other factors, such as the type of resource 497 being attacked if the traffic is determined to 498 be an attack) 500 Traffic Management Examples 502 Event: edge link close to being overloaded by 503 incoming traffic 504 Condition: if link utilization exceeds Y% or if link 505 utilization average is increasing over a 506 specified time period 507 Action: change routing configuration to other peers 508 that have better metrics 510 Event: edge link close to be overloaded by 511 outgoing traffic 512 Condition: if link utilization exceeds Z% or if link 513 utilization average is increasing over a 514 specified time period 515 Action: reconfigure affected nodes to use source-based 516 routing to balance traffic across multiple links 518 Service Management Examples 520 Event: alarm received or periodic time period check 521 Condition: CPU utilization level comparison 522 Action: no violation: no action 523 violation: 524 1) determine workload profile in time interval 525 2) determine complementary workloads (e.g., 526 whose peaks are at different times in day) 527 3) combine workloads (e.g., using integer 528 programming) 530 Event: alarm received or periodic time check 531 Condition: if DSCP == AFxy and 532 throughput < T% or packet loss > P% 533 Action: no: no action 534 yes: remark to AFx'y'; reconfigure queuing; 535 configure shaping to S pps; ... 537 Note: it is possible to construct an ECA policy rule that is 538 directly tied to configuration parameters. 540 4. Related Work 542 4.1. Related Work within the IETF 544 4.1.1. I2RS Working Group 546 I2RS defines an interface that interacts with the routing 547 system using a collection of protocol-based control or 548 management interfaces. Users of I2RS interfaces are typically 549 management applications and controllers. SUPA does not directly 550 interface to the routing system. Rather, SUPA uses data 551 produced by I2RS (e.g., topological information) to construct 552 its policies. 554 4.1.2. L3SM Working Group 556 L3SM defines an L3 VPN service model that can be used for 557 communication between customers and network operators. This 558 model enables an orchestration application or customers to 559 request network services provided by L3 VPN technologies. The 560 implementation of network services is often guided by specific 561 policies, and SUPA provides a tool that can help with the 562 mapping of L3 VPN service requests to L3 VPN configurations of 563 network elements. 565 4.1.3. ALTO Working Group 567 The ALTO working group defined an architecture for exposing 568 topology information, more specifically the cost of paths 569 through an infrastructure, as defined in [RFC7285]. ALTO 570 services are able to provide network maps defined as groups of 571 endpoints, and can therefore represent any granularity of network, 572 from the physical to groups of networks following similar paths or 573 restraints. Although this model can represent different levels of 574 granularities, it is not clear if it could be adapted easily for 575 other purposes than providing cost maps in the context of ALTO. 576 The ALTO model is meant to be used outside of the trust domain of 577 an ISP by external clients. 579 SUPA does not generate data that is similar to ALTO. Rather, 580 SUPA could use ALTO data as part of its policies to configure 581 services and/or resources. 583 4.1.4. TEAS Working Group 585 The Traffic Engineering Architecture and Signaling (TEAS) 586 working group is responsible for defining MPLS- and GMPLS-based 587 Traffic Engineering architectures that enable operators to 588 control how specific traffic flows are treated within their 589 networks. It covers YANG models for a traffic engineering 590 database. In coordination with other working groups (I2RS) 591 providing YANG models for network topologies. 593 Both TEAS and SUPA use YANG data models. SUPA does not generate 594 traffic engineering (TE) data. However, SUPA could use TE data 595 as part of its policies for configuring resources and/or 596 services. SUPA could also define policies that define which 597 service, path, and link properties to use for a given customer, 598 and consequently, which protocol extensions to use. TEAS data 599 could also be used to enable operators to define how particular 600 traffic flows are treated in a more abstract (but still 601 consistent) manner. 603 4.1.5. BESS Working Group 605 The BGP Enabled Services (BESS) working group defines and 606 extends network services that are based on BGP. This includes 607 BGP/MPLS IP provider-provisioned L3VPNs, L2VPNs, BGP-enabled 608 VPN solutions for use in data center networking, and extensions 609 to BGP-enabled solutions to construct virtual topologies in 610 support of services such as Service Function Chaining. The 611 working group is also chartered to work on BGP extensions to 612 YANG models and data models for BGP-enabled services. 614 Both BESS and SUPA use YANG data models. SUPA could generate 615 BGP configurations by using data defined by BESS as part of 616 its policies for configuring resources and/or services. 618 SUPA could also define policies that govern different aspects 619 of services defined by BESS. 621 4.1.6. SFC Working Group 623 The Service Function Chaining (SFC) working group defines a 624 mechanism where traffic is classified; that classification is 625 then use to select an ordered set of services to pass the 626 traffic through. 628 Both SFC and SUPA use YANG data models. SUPA could define 629 policies that augment the functionality of SFC in several 630 different ways, including: (1) path selection based on context, 631 (2) which set of mechanisms to use to steer traffic through 632 which set of service functions, (3) simplify the definition of 633 dynamic service function chains (e.g., service paths that 634 change based upon a set of data that is discovered at runtime), 635 and (4) scalable mechanisms to monitor and control the 636 configuration of SFC components. 638 4.1.7. NVO3 Working Group 640 The NVO3 group proposes a way to virtualize the network edge 641 for data centers in order to be able to move virtual instances 642 without impacting their network configuration. This is realized 643 through a centrally controlled overlay layer-3 network. The 644 NVO3 work is not about defining policy information; rather, it 645 uses policy information to perform some functions. Both NVO3 and 646 SUPA use YANG data models. SUPA could define policies that define 647 how the logically centralized network virtualization management 648 entity (or entities) of NVO3 behave (e.g., the functions in the 649 network virtualization control plane). 651 4.1.8. ACTN BoF (IETF-90) 653 The ACTN proposed work, as described in [actn] framework, has 654 two main goals, the abstraction of multiple optical transport 655 domains into a single controller offering a common abstract 656 topology, and the splitting of that topology into abstract 657 client views that are usually a fraction of the complete 658 network. The ACTN work is therefore about unification of 659 several physical controllers into a virtual one, and also about 660 the segmentation, isolation and sharing of network resources. 661 The ACTN work is not about defining policy information. Both ACTN 662 and SUPA use YANG data models. SUPA could define policies that 663 define the behavior of the controller. 665 4.1.9. Previous IETF Policy Models 667 SUPA is technology-neutral, previous RFCs weren't. SUPA defines a 668 common structure from which ECA policies can be defined; this was 669 not possible in previous RFCs. Previous RFCs do NOT define metadata, 670 and do NOT enable policies to formally define obligation, 671 permission, and related concepts. Finally, SUPA uses software 672 patterns, which previous RFCs didn't. 674 A more complete analysis is in Appendix A of [SUPA-info-model]. 676 4.2. Related Work outside the IETF 678 4.2.1. TM Forum 680 The TM Forum (a.k.a., the TeleManagement Forum) develops standards 681 and best practices, research, and collaborative programs focused on 682 digital business transformation. It consists of three major 683 programs: 685 1) Agile Business and IT 686 2) Customer Centricity (experience) 687 3) Open Digital Ecosystem 689 Of these, the ZOOM (Zero-touch Orchestration, Operations, and 690 Management) project, located in the Agile Business and IT project, 691 is the main sub-project in this area that is of interest to SUPA. 693 Within ZOOM, the Foundational Studies project contains work on 694 an information model and management architecture that are 695 directly relevant to SUPA. The TMF Information Model, Policy, 696 and Security working groups are involved in this work. 698 The ZOOM information model updates the existing Shared 699 Information and Data (SID) information model to add support for 700 the management of physical and virtual infrastructure, event- 701 and data-driven systems, policy management (architecture and 702 model), metadata for describing and prescribing behavior that can 703 support changes at runtime, and access control. The policy 704 information model defines imperative (ECA), declarative (intent- 705 based), utility function, and promise policies. The work in 706 [SUPA-info-model] is based on, but extends and enhances, the 707 ZOOM ECA model and provides additional detail not currently 708 present in ZOOM. 710 There is currently no plan to use the utility function and 711 promise policies of ZOOM in SUPA. Finally, it should be noted 712 that the data model work planned for SUPA is not currently 713 planned for the ZOOM project. 715 4.2.2. MEF 717 The MEF (originally named the Metro Ethernet Forum) develops 718 architecture, service and management specifications related to 719 Carrier Ethernet (CE). The CE architecture includes the definition 720 of several interfaces specific to CE like the User Network Interface 721 (UNI) and External Network Network Interface (ENNI). Specifications 722 developed in this space include the definitions of CE services, CE 723 service attributes, Ethernet Access Services, Class of Service, OAM 724 and Management interfaces, Service Activation and Test. The more 725 recent vision of the MEF is described as The Third Network, and 726 includes plans to develop Lifecycle Service Orchestration with APIs 727 for existing network, NFV, and SDN implementations enabling Agile, 728 Assured, and Orchestrated Services. This stage of the MEF activity 729 is now in early phases with focus on architectural work. 731 The MEF has developed a number of Information and Data Models, and 732 has recently started a project that uses YANG to model and manage 733 the services defined by the MEF. While the MEF has created rigorous 734 definitions of these services, they are specific to transport 735 technology, and they do not currently include and rely on policies. 737 4.2.3. Open Daylight 739 Open Daylight network controller implements a number of models 740 through its service abstraction Layer (MD-SAL) based on draft 741 IETF Yang models. Open Daylight is an open source project. Two of 742 these could be relevant to SUPA in the future (since they both are 743 focused on declarative policies, which are currently out of scope 744 for SUPA) and are described below. 746 4.2.3.1. Network Intent Composition (NIC) 748 The Network Intent Composition project aims at providing better 749 flexibility by using declarative policies. It does not cover 750 other types of policies, such as ECA policy rules. The intent- 751 based interface aims to provide a high level of abstraction, 752 primarily for use by an application developer. Its progress 753 has recently stalled. 755 4.2.3.2. Group Based Policy 757 The Group Based Policy project defines an application-centric 758 policy model for Open Daylight that separates information about 759 application connectivity requirements from information about 760 the underlying details of the network infrastructure. The model 761 is positioned as declarative, but uses a relational approach to 762 specifying policy. It does not cover other types of policies, 763 such as ECA policy rules. 765 4.2.4. Open Networking Foundation 767 The ONF created a group responsible of defining northbound 768 interfaces, but this hasn't lead to the publication of 769 standards in this area so far. A blog entry on the ONF web site 770 showed an interest in using the principle of intents at ONF, 771 but no details were provided on the status of this project. A 772 members-only whitepaper was recently published. 774 4.2.5. OpenStack 776 OpenStack software controls large pools of compute, storage, 777 and networking resources throughout a datacenter, managed 778 through a dashboard or via the OpenStack API. OpenStack works 779 with popular enterprise and open source technologies making it 780 ideal for heterogeneous infrastructure. Few of the below 781 mentioned OpenStack projects provides policy abstraction and 782 better flexibility to the user. 784 4.2.5.1. Group-Based Policy 786 The Group-Based Policy project for OpenStack Neutron is built 787 around entities assembled in Endpoints Groups (EPG) that 788 provide or consume Contracts. Such Contracts are hierarchical 789 entities containing policy rules. A first version was released 790 in January 2015, based on the Juno release. This type of 791 approach is more relational than declarative, but could be used 792 to describe a large amount of possible scenarios. It has the 793 advantage of providing a relatively simple policy model that 794 covers a large applicability. From an OpenStack point of view, 795 the scope of Group-Based Policies is limited to networking 796 within the Neutron module. Note that other types of policies, such 797 as ECA policies, are not covered in Group-Based Policy. 799 4.2.5.2. Congress 801 The Congress project within OpenStack provides a way to define 802 complex policies using extensions to the Datalog language. 803 Datalog is entirely declarative, and its evaluation is based on 804 first-order logic with restrictions. This gives it interesting 805 properties, such as providing the same result no matter the order 806 in which the statements are made. The language allows for the 807 definition of types and for active enforcement or verification 808 of the policies. However, it does not cover ECA policies. 810 There is a significant body of knowledge and experience relating 811 to declarative languages and their implementation. Congress 812 policies aim at manipulating objects exposed by multiple 813 OpenStack modules, and is therefore larger in scope than network 814 element policies. 816 4.2.6. The NEMO Project (not a BoF yet) 818 The NEMO project is a research activity aimed at defining a 819 simple framework for "intent-based" networking. This project 820 concentrates on creating a domain-specific language and associated 821 API, not a model or even a rigorous definition of what a policy 822 rule is. NEMO does not define ECA policies. 824 The NEMO syntax defines a very simple information model that has 825 three basic elements for network manipulation: nodes, links, and 826 flows. A policy rule is NOT defined in this model. Rather, policy 827 is defined as a command. The NEMO project has been successfully 828 demonstrated at IETF-91, along with a companion graphical user 829 interface. 831 NEMO declarative policies use a flatter, simpler object model with 832 fewer objects to represent targets of policy. NEMO uses a condition- 833 action paradigm to execute its declarative policies. In contrast, 834 SUPA uses a richer class model to represent ECA policies. However, 835 SUPA has not proposed a language. 837 4.2.7. The Floodlight Project 839 The Floodlight is an OpenFlow-enabled SDN controller. It uses 840 another open source project called Indigo to support OpenFlow 841 and manage southbound devices. The Indigo agent also supports 842 an abstraction layer to make it easy to integrate with physical 843 and virtual switches. It supports configuration of an abstraction 844 layer so that it can configure OpenFlow in hybrid mode. 846 4.2.8. The ONOS Project 848 The ONOS is an SDN controller design for Service Provider networks. 849 It uses a distributed architecture, and supports abstraction for 850 both southbound and northbound interfaces. Its modules are managed 851 as OSGi bundles. It is an open source project. ONOS announced an 852 "application-intent framework". However, no object model or 853 language has been defined yet. 855 5. Conclusions: the Value of SUPA 857 SUPA can be used to define high-level, possibly network-wide 858 policies to create interoperable network element configuration 859 snippets. SUPA expresses policies and associated concepts using a 860 generic policy information model, and produces generic policy YANG 861 data modules. SUPA focuses on management policies that control the 862 configuration of network elements. Management policies can be 863 interpreted outside of network elements, and the interpretation 864 typically results in configuration changes to collections of 865 network elements. 867 Policies embedded in the configuration of network elements are not 868 in the scope of SUPA. In contrast to policies targeted by SUPA, 869 embedded policies are usually interpreted on network elements in 870 isolation, and often at timescales that require the representation 871 of embedded policies to be optimized for a specific purpose. 873 The SUPA information model generalizes common concepts from multiple 874 technology-specific data models, and makes it reusable. 875 Conceptually, SUPA can be used to interface and manage existing and 876 future data models produced by other IETF working groups. In 877 addition, by defining an object-oriented information model with 878 metdata, the characteristics and behavior of data models can be 879 better defined. 881 6. Security Considerations 883 TBD. 885 7. IANA Considerations 887 This document has no actions for IANA. 889 8. Contributors 891 The following people all contributed to creating this document, 892 listed in alphabetical order: 894 Vikram Choudhary, Huawei Technologies 895 Luis M. Contreras, Telefonica I+D 896 Dan Romascanu, Avaya 897 J. Schoenwaelder, Jacobs University, Germany 898 Qiong Sun, China Telecom 899 Parviz Yegani, Juniper Networks 901 9. Acknowledgments 903 This document has benefited from reviews, suggestions, comments 904 and proposed text provided by the following members, listed in 905 alphabetical order: H. Rafiee, J. Saperia and C. Zhou. 907 The initial draft of this document merged one document, and this 908 section lists the acknowledgements from it. 910 From Problem Statement for Simplified Use of Policy Abstractions 911 (SUPA)" [Karagiannis2015] 912 The authors of this draft would like to thank the following 913 persons for the provided valuable feedback and contributions: 914 Diego Lopez, Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit 915 Claise, Ian Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet 916 Ersue, Simon Perreault, Fernando Gont, Jose Saldana, Tom Taylor, 917 Kostas Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, 918 Scott O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. 919 Tina Tsou, Will Liu and Jean-Francois Tremblay contributed to an 920 early version of this draft. 922 The authors of "Problem Statement for Simplified Use of Policy 923 Abstractions (SUPA)" [Karagiannis2015] were: 925 Georgios Karagiannis 926 Qiong Sun 927 Luis M. Contreras 928 Parviz Yegani 929 John Strassner 930 Jun Bi 932 10. References 934 10.1. Normative References 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, March 1997. 939 10.2. Informative References 941 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., 942 Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., 943 Perry, J., Waldbusser, S., "Terminology for Policy-Based 944 Management", RFC 3198, November, 2001 946 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 947 Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. 949 [RFC7285] R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. 950 Roome, S. Shalunov, R. Woundy "Application-Layer Traffic 951 Optimization (ALTO) Protocol", September 2014 953 [SUPA-info-model] J. Strassner, J. Halpern, J. Coleman, "Generic 954 Policy Information Model for Simplified Use of Policy Abstractions 955 (SUPA)", IETF Internet draft, draft-strassner-supa-generic-policy- 956 info-model-04, February 2016 958 [TR235] J. Strassner, ed., "ZOOM Policy Architecture and 959 Information Model Snapshot", TR245, part of the TM Forum ZOOM 960 project, October 26, 2014 962 [Karagiannis2015] G. Karagiannis, ed., "Problem Statement for 963 Simplified Use of Policy Abstractions (SUPA)", IETF Internet draft, 964 draft-karagiannis-supa-problem-statement-07, June 5, 2015 966 Authors' Addresses 968 Maxim Klyus, Ed. 969 NetCracker 970 Kozhevnicheskaya str.,7 Bldg. #1 971 Moscow, Russia 972 E-mail: klyus@netcracker.com 974 John Strassner, Ed. 975 Huawei Technologies 976 2330 Central Expressway 977 Santa Clara, CA 95138 USA 978 Email: john.sc.strassner@huawei.com 980 Will(Shucheng) Liu 981 Huawei Technologies 982 Bantian, Longgang District, Shenzhen 518129 983 P.R. China 984 Email: liushucheng@huawei.com 986 Georgios Karagiannis 987 Huawei Technologies 988 Hansaallee 205, 40549 Dusseldorf 989 Germany 990 Email: Georgios.Karagiannis@huawei.com 992 Jun Bi 993 Tsinghua University 994 Network Research Center, Tsinghua University 995 Beijing 100084 996 P.R. China 997 Email: junbi@tsinghua.edu.cn