idnits 2.17.1 draft-karagiannis-supa-problem-statement-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 5, 2015) is 3246 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-cheng-supa-ddc-use-cases-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Karagiannis 3 Internet Draft J. Strassner 4 Intended status: Informational Huawei Technologies 5 Expires: December 5, 2015 Q. Sun 6 China Telecom 7 Luis M. Contreras 8 Telefonica 9 P. Yegani 10 Juniper Networks 11 J.Bi 12 Tsinghua University 13 June 5, 2015 15 Problem Statement for Simplified Use of Policy Abstractions (SUPA) 16 draft-karagiannis-supa-problem-statement-07 18 Abstract 20 The increase in complexity of modern networks makes it challenging to 21 deploy new services and to keep networks up to date whilst 22 maintaining stability and availability for critical business 23 services. This is a major challenge that network operators (service 24 providers, SME, etc) face today. The operators aim of streamlining 25 both operations and the deployment of new services, is being met by 26 increasingly relying on (1) software abstractions to simplify the 27 design and configuration of monitoring and control operations and (2) 28 the use of programmatic control over the configuration and operation 29 of such networks. 30 In this context, providing network operators with a generic policy- 31 based management model that can be used to express policies on top 32 of arbitrary configuration data models is essential. 34 In particular, SUPA addresses the needs of operators and application 35 developers to use a generic policy-based management model for 36 defining and representing multiple types of policy rules. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .2 71 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . .3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Use Case: Distributed Data Centers (DDCs) . . . . . . . . . 5 74 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 8.1 Normative References . . . . . . . . . . . . . . . . . . 7 80 8.2 Informative References . . . . . . . . . . . . . . . . . 7 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 Network operators are faced with networks of increasing size and 86 complexity while trying to improve their quality and availability, as 87 more and more business services depend on them. Software abstractions 88 to simplify the design and configuration of monitoring and control 89 operations and the use of programmatic control, often called 90 software-defined, are considered by many network operators as an 91 essential tool toward the management of that complexity. 93 Providing means to network operators to (1) express policies on top 94 of arbitrary configuration data models and (2) represent multiple 95 types of policy rules, enable significant improvements in 96 configuration agility, error detection and uptime for operators. 97 This document describes the problems that need to be addressed in 98 order to equip service providers with the means, such as a generic 99 policy-based management model used to represent multiple types of 100 policy rules to quickly and dynamically manage their offering of 101 network services. 103 1.1 Motivation 105 The rapid growth in the variety and importance of traffic flowing 106 over increasingly complex enterprise and service provider network 107 makes the task of network operations and management applications and 108 of deploying new services much more difficult. 110 This is a significant challenge that network operators (service 111 providers, SME, etc) face today. 113 Several mechanisms can be used to deal with this challenge. The main 114 ones are: (1) the use of software abstractions to simplify the design 115 and configuration of monitoring and control operations and (2) the 116 use of programmatic control over the configuration and operation of 117 such networks. By combining these mechanisms can (1) provide 118 additional and significant benefits in design and deployment agility 119 and (2) be used to define a generic policy-based management model. 121 In particular, the power of policy management is its applicability to 122 many different types of systems. Many different types of actors can 123 be identified that can use a policy management system, including 124 applications, end-users, developers, network administrators and 125 operators. Each of these actors, typically, has different skills and 126 uses different concepts and terminologies. For example, an operator 127 may want to express that only Platinum and Gold users can use 128 streaming and interactive multimedia applications. As a second 129 example, an operator may want to define a more concrete policy rule 130 that looks at the number of dropped packets. If, for example, this 131 number exceeds a certain threshold value, then the applied queuing, 132 dropping and scheduling algorithms could be changed in order to 133 reduce the number of dropped packets. 135 Both examples can be referred to as "policy rules", but they take 136 very different forms, since they are at very different levels of 137 abstraction and likely authored by different actors. The first 138 example described a very abstract policy rule, and did not contain 139 any technology-specific terms, while the second example included a 140 more concrete policy rule and likely used technical terms of a 141 general (e.g., IP address range, port numbers) as well as vendor- 142 specific nature (e.g., specific algorithms implemented in a 143 particular device). Furthermore, these two policy rules could affect 144 each other. For example, Gold and Platinum users might need different 145 device configurations to give the proper QoS markings to their 146 streaming multimedia traffic. This is very difficult to do if a 147 common policy framework does not exist. 149 It needs to be mentioned that there are ongoing policy modeling 150 efforts in IETF. However, all these policy modeling models can be 151 characterized as being technology specific. This means that the IETF 152 needs to reinvent the wheel in different colors (i.e., policy models 153 that apply for a specific technology) several times. 155 SUPA will address these challenges by: 157 (1) developing an information model fragment for defining 158 standardized policy rules at different levels of abstraction, 159 (2) specifying how to map this information fragment into 160 corresponding YANG [RFC6020] and [RFC6991], data models to 161 define interoperable implementations that can exchange and 162 modify generic policies using protocols such as NETCONF/RESTCONF 163 on the interface north of the controller (or other similar 164 management entity) and south of the service manager. 166 Specifically, three information model fragments are envisioned: 168 (a) a generic policy information model (GPIM) that defines concepts 169 needed by policy management independent of the form and content of 170 the policy 172 (b) a more specific information model that refines the generic 173 information model to specify how to build policy rules of the 174 event-condition-action (ECA) paradigm 176 (c) a more specific information model that refines the generic 177 information model to specify how to build policy rules that 178 declaratively specify what goals to achieve (but not how to 179 achieve those goals); this is often called "intent-based" policy 181 2. Terminology 183 Some of definitions are based on [RaBe11] and/or [Stras02]. 185 Network Service: the composition of network functions as defined 186 by its functional and behavioral specification. A network service 187 is characterized by performance, dependability, and security 188 specifications. Furthermore, a network service is delivered by 189 network service endpoints, which may be aggregations of multiple 190 lower-layer technology specific endpoints. 192 Network Element: a physical or virtual entity that implements one or 193 more network function(s). NEs can interact with local or remote 194 network controllers in order to exchange information, such as 195 configuration information and status. 197 Service specific abstraction: an abstract view of the service 198 topology, associated with a specific network service type, e.g., 199 inter-datacenter communication services 201 Policy: a definite goal, course, or method of action to guide and 202 determine present and future decisions. Policies are implemented or 203 executed within a particular context. 205 SUPA policy: a means to monitor and control the changing and/or 206 maintaining of the state of one or more managed entities. 208 Policy-based management: the usage of policy rules to manage one or 209 more entities. 211 Information Model: a representation of managed objects and their 212 relationships that is independent of data repository, language, and 213 protocol. 215 Data Model: a representation of managed objects and their 216 relationships that is dependent on data repository, language, and/or 217 protocol (typically all three). 219 Policy Rule: A container that uses metadata to define how the content 220 is interpreted, and hence, how the behavior that it governs is 221 defined separates the content of the policy from its representation 222 provides a convenient control point for OAMP operations. 224 Policy condition: a representation of the necessary state and/or 225 prerequisites that define whether a policy rule's actions should be 226 performed. 228 Policy action: defines what is to be done to enforce a policy rule 229 when its conditions are met. 231 Event Condition Action policy: reactive behavior of a system that 232 correlates a set of events, a set of conditions, and a set of 233 actions. Conditions are evaluated on the occurrence of an event and 234 which determine whether the policy is applicable or not for that 235 particular situation. Furthermore, the actions are only executed only 236 if the conditions are met. 238 Goal (Intent) policy rule (also called a declarative policy rule, or 239 an intent-based policy rule): a declarative statement that 240 defines what the policy should do, but not how to implement the 241 policy. 243 Model Mapping: a translation from one type of model to another type 244 of model. Model mapping changes the representation and/or level of 245 abstraction used to another representation and/or level of 246 abstraction. The most common form of model mapping is from an 247 information model to a data model; another important form is from a 248 vendor-neutral data model to a vendor-specific data model. 250 3. Use Case: Distributed Data Centers (DDCs) 252 Large scale Distributed Data Centers (DDCs) can provide various 253 services and usually consist of many internal and external links 254 where various VPNs are built upon. The Service provisioning and 255 network connectivity configurations could be complex and dynamic, for 256 which manual configuration is not onerous and error-prone. 257 The SUPA generic policy management models can be used to support the 258 dynamic and automated resource usage and simplify and automate the 259 service/network deployment/configuration of various VPN scenarios in 260 the DDC environment. A more detailed description of this use case is 261 provided in [ID.draft-cheng-supa-ddc-use-cases]. 263 4. Requirements 265 In order to satisfy the challenges mentioned in Section 1.1 and the 266 goal of the DDC use case briefly described in section 3, the 267 following requirements need to be addressed: 269 o) Specify a generic and non-technology specific policy information 270 model. 272 o) Specify a more specific information model that defines how to 273 build policy rules of the event-condition-action (ECA) paradigm. 275 o) Specify a more specific information model that defines how to 276 build policy rules that declaratively specify what goals (what 277 intents) to achieve using the Goal (Intent) policy paradigm. 279 o) Specify how to map the above mentioned information models into 280 corresponding YANG standardized data models to 281 define interoperable implementations that can exchange and modify 282 generic policies using protocols such as NETCONF/RESTCONF on the 283 interface north of the controller (or other similar management 284 entity) and south of the service manager. 286 5. Security Considerations 288 Security is a key aspect of any protocol that allows state 289 installation and extracting detailed configuration states of network 290 elements. This places additional security requirements on SUPA (e.g., 291 authorization, and authentication of network services) that needs 292 further investigation. Moreover, policy interpretation can lead to 293 corner cases and side effects that should be carefully examined, 294 e.g., in case policy rules are conflicting with each other. 296 6. IANA Considerations 298 This document has no actions for IANA. 300 7. Acknowledgements 302 The authors of this draft would like to thank the following 303 persons for the provided valuable feedback and contributions: 304 Diego Lopez, Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit 305 Claise, Ian Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet 306 Ersue, Simon Perreault, Fernando Gont, Jose Saldana, Tom Taylor, 307 Kostas Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, 308 Scott O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. 310 Tina Tsou, Will Liu and Jean-Francois Tremblay contributed to an 311 early version of this draft. 313 8. References 315 8.1. Normative References 317 8.2. Informative References 319 [ID.draft-cheng-supa-ddc-use-cases] Y. Cheng, JF. Tremblay, J. Bi, 320 L. M. Contreras, "Use Case for Distributed Data Center in SUPA", IETF 321 Internet draft (Work in progress), draft-cheng-supa-ddc-use-cases-07, 322 May 8, 2015 324 [RFC6020] M. Bjorklund, "YANG - A Data Modeling Language for the 325 Network Configuration Protocol (NETCONF)", RFC 6020, 326 October 2010. 328 [RFC6991] J. Schoenwaelder, "Common YANG Data Types", RFC 6991, 329 July 2013. 331 [RaBe11] Raphael Romeikat, Bernhard Bauer, "Formal Specification of 332 DomainSpecific ECA Policy Models", in Proc. 2011 Fifth IEEE 333 International Conference on Theoretical Aspects of Software 334 Engineering, 2011 336 [Stras02] John Strassner, "DEN-ng: Achieving Business-Driven Network 337 Management" in Proc. IEEE Network Operations and Management Symposium 338 (NOMS), 2002. 340 Authors' Addresses 342 Georgios Karagiannis 343 Huawei Technologies 344 Hansaallee 205, 345 40549 Dusseldorf, 346 Germany 347 Email: Georgios.Karagiannis@huawei.com 349 Qiong Sun 350 China Telecom 351 No.118 Xizhimennei street, Xicheng District 352 Beijing 100035 353 P.R. China 354 Email: sunqiong@ctbri.com.cn 356 Luis M. Contreras 357 Telefonica I+D 358 Ronda de la Comunicacion, Sur-3 building, 3rd floor 359 Madrid 28050 360 Spain 361 Email: luismiguel.contrerasmurillo@telefonica.com 362 URI: http://people.tid.es/LuisM.Contreras/ 363 Parviz Yegani 364 JUNIPER NETWORKS 365 1133 Innovation Way 366 Sunnyvale, CA 94089 367 Email: pyegani@juniper.net 369 John Strassner 370 Huawei Technologies 371 2330 Central Expressway 372 Santa Clara, CA 95138 USA 373 Email: john.sc.strassner@huawei.com 375 Jun Bi 376 Tsinghua University 377 Network Research Center, Tsinghua University 378 Beijing 100084 379 China 380 EMail: junbi@tsinghua.edu.cn