idnits 2.17.1 draft-ietf-supa-policy-based-management-framework-01.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 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 (March 13, 2017) is 2599 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6020bis' is mentioned on line 113, but not defined == Unused Reference: 'RFC2119' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-data-model' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-supa-generic-policy-info-model' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC3198' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC7285' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 601, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-supa-generic-policy-data-model-02 == Outdated reference: A later version (-03) exists of draft-ietf-supa-generic-policy-info-model-02 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Liu 3 Internet-Draft Huawei Technologies 4 Intended status: Informational C. Xie 5 Expires: September 14, 2017 China Telecom Beijing Research Institute 6 J. Strassner 7 G. Karagiannis 8 Huawei Technologies 9 M. Klyus 10 NetCracker 11 J. Bi 12 Tsinghua University 13 March 13, 2017 15 SUPA Policy-based Management Framework 16 draft-ietf-supa-policy-based-management-framework-01 18 Abstract 20 Simplified Use of Policy Abstractions (SUPA) defines base YANG data 21 models to encode policy, which will point to device-, technology-, 22 and service-specific YANG models developed in other working groups. 23 Policy rules within an operator's environment can be used to express 24 high-level, possibly network-wide policies to a network management 25 function (within a controller, an orchestrator, or a network 26 element). The network management function can then control the 27 configuration and/or monitoring of network elements and services. 28 This document describes the SUPA basic framework, its elements and 29 interfaces. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 14, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Framework for Generic Policy-based Management . . . . . . . . 4 68 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 9 71 3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 9 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 8.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 The rapid growth in the variety and importance of traffic flowing 84 over increasingly complex enterprise and service provider network 85 architectures makes the task of network operations and management 86 applications deploying new services much more difficult. In 87 addition, network operators want to deploy new services quickly and 88 efficiently. Two possible mechanisms for dealing with this growing 89 difficulty are the use of software abstractions to simplify the 90 design and configuration of monitoring and control operations, and 91 the use of programmatic control over the configuration and operation 92 of such networks. Policy-based management can be used to combine 93 these two mechanisms into an extensible framework. 95 Policy rules within an operator's environment can be used to express 96 high-level, possibly network-wide policies to a network management 97 function (within a controller, an orchestrator, or a network 98 element). The network management function can then control the 99 configuration and/or monitoring of network elements and services. 101 Simplified Use of Policy Abstractions (SUPA) will define a generic 102 policy information model (GPIM) [I-D.ietf-supa-generic-policy-info- 103 model] for use in network operations and management applications. 104 The GPIM defines concepts and terminology needed by policy management 105 independent of the form and content of the policy rule. The ECA 106 Policy Rule Information Model (EPRIM) [I-D.ietf-supa-generic-policy- 107 info-model] extends the GPIM to define how to build policy rules 108 according to the event-condition-action paradigm. 110 Both the GPIM and the EPRIM are targeted at controlling the 111 configuration and monitoring of network elements throughout the 112 service development and deployment lifecycle. The GPIM and the EPRIM 113 will both be translated into corresponding YANG [RFC6020][RFC6020bis] 114 modules that define policy concepts, terminology, and rules in a 115 generic and interoperable manner; additional YANG modules may also be 116 defined from the GPIM and/or EPRIM to manage specific functions. 118 The key benefit of policy management is that it enables different 119 network elements and services to be instructed to behave the same 120 way, even if they are programmed differently. Management 121 applications will benefit from using policy rules that enable 122 scalable and consistent programmatic control over the configuration 123 and monitoring of network elements and services. 125 2. Terminology 127 GPIM: Generic Policy Information Model, which defines concepts and 128 terminology needed by policy management independent of the form and 129 content of the policy rule. 131 EPRIM: ECA Policy Rule Information Model, which extends the GPIM to 132 define how to build policy rules according to the event-condition- 133 action paradigm. 135 GPDM: Generic Policy Data Models [I-D.ietf-supa-generic-policy-data- 136 model], are created from the GPIM. These YANG data model policies 137 are used to control the configuration of network elements that model 138 the service(s) to be managed using policy. 140 3. Framework for Generic Policy-based Management 142 This section briefly describes the design and operation of the SUPA 143 policy-based management framework. 145 3.1. Overview 147 Figure 1 shows a simplified functional architecture of how SUPA is 148 used to define policies for creating network element configuration 149 snippets. (Note from Editor: a "snippet" is a small piece of 150 information (e.g., part of a sentence that was cut out).) SUPA uses 151 the GPIM to define a consensual vocabulary that different actors can 152 use to interact with network elements and services. The EPRIM 153 defines a generic structure for imperative policies. The GPIM, and/ 154 or the combination of the GPIM and the EPRIM, is converted to generic 155 YANG data modules. 157 In one possible approach, SUPA Generic Policy and SUPA ECA Policy 158 YANG data modules together with the Resource and Service YANG data 159 models specified in IETF (which define the specific elements that 160 will be controlled by policies) are used by the Service Interface 161 Logic. This Service Interface Logic creates appropriate input 162 mechanisms for the operator to define policies (e.g., a web form or a 163 script) for creating and managing the network configuration. The 164 operator interacts with the interface, which is then translated to 165 configuration snippets. 167 Note that YANG models may not exist. In this case, the SUPA generic 168 policy YANG data modules serve as an extensible basis to develop new 169 YANG data models for the Service Interface Logic to create 170 appropriate input mechanisms for the operator to define policies. 171 This transfers the work specified by the Resource and Service YANG 172 data models specified in IETF into the Service Interface Logic, which 173 is then translated to configuration snippets. 175 +---------------------+ 176 +----------+ \| SUPA | 177 | IETF |---+----+ Information Models | 178 +----------+ | /| GPIM and EPRIM | 179 | +---------+-----------+ 180 Assignments | | Defines Policy Concepts 181 and Manage | \|/ 182 Content | +---------+-----------+ 183 | \| SUPA Generic | 184 +----+ & ECA Policy | 185 /| YANG Data modules | 186 +---------+-----------+ 187 * Possible Approach 188 +-----------------------------*-----------------------------+ 189 | Management System * | 190 | \*/ | 191 | Fills +---------+---------+ +-------------+ | 192 | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+ 193 | |Operator|--------+ Logic +--|Service YANG |----|IETF| 194 | +--------+ Runs /| (locally defined |\ | Data Models |\ | +----+ 195 | scripts |forms, scripts,...)| +-------------+ | 196 | +---------+---------+ | 197 | \|/ | 198 | +-------+--------+ | 199 | | Local Devices | | 200 | | and Management | | 201 | | Systems | | 202 | +----------------+ | 203 +-----------------------------------------------------------+ 205 Figure 1: SUPA Framework 207 Figure 1 is exemplary. The Operator actor shown in Figure 1 can 208 interact with SUPA in other ways not shown in Figure 1. In addition, 209 other actors (e.g., an application developer) that can interact with 210 SUPA are not shown for simplicity. 212 The EPRIM defines an Event-Condition-Action (ECA) policy as an 213 example of imperative policies. An ECA policy rule is activated when 214 its event clause is true; the condition clause is then evaluated and, 215 if true, signals the execution of one or more actions in the action 216 clause. This type of policy explicitly defines the current and 217 desired states of the system being managed. Imperative policy rules 218 require additional management functions, which are explained in 219 section 2.2 below. 221 Figure 2 shows how the SUPA Policy Model is used to create policy 222 data models step by step and how the policy rules are used to 223 communicate among various network management functions located on 224 different layers. 226 The Generic Policy Information Model (GPIM) is used to construct 227 policies. The GPIM defines generic policy concepts, as well as two 228 types of policies: ECA policy rules and declarative policy 229 statements. 231 A set of Generic Policy Data Models (GPDM) are then created from the 232 GPIM. These YANG data model policies are then used to control the 233 configuration of network elements that model the service(s) to be 234 managed using policy. 236 SUPA designed YANG data models can be the input for management 237 functions, and automatically generate interfaces and data stores. 238 During the run time, components communicate with the data instances 239 for management and monitoring. 241 + 243 | SUPA Policy Model 244 | 245 | +----------------------------------+ 246 | | Generic Policy Information Model | 247 | +----------------------------------+ 248 | D D 249 | D +-------------v-------------+ 250 +----------------------+ | D | ECAPolicyRule Information | 251 | OSS/BSS/Orchestrator <--+ | D | Model | 252 +----------^-----------+ | | D +---------------------------+ 253 C | | D D 254 C | | +----+D+------------------------+D+---+ 255 C +-----+ D SUPA Policy Data Model D | 256 +----------v-----------+ | | ----v-----------------------+ D | 257 | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | 258 +----------^-----------+ | | ----------------------------+ D | 259 C +-----+ D D | 260 C | | | +--------v-----------------v--+ | 261 +----------v-----------+ | | | | ECA PolicyRule Data Model | | 262 | Network Element <--+ | | +-----------------------------+ | 263 +----------------------+ | +-------------------------------------+ 264 | 265 | 267 Figure 2: SUPA Policy Model Framework 269 In Figure 2: 271 The double-headed arrow with Cs means communication; 273 The arrow with Ds means derived from. 275 The components within this framework are: 277 SUPA Policy Model: represents one or more policy modules that contain 278 the following entities: 280 Generic Policy Information Model: a model for defining policy rules 281 that are independent of data repository, data definition, query, 282 implementation languages, and protocol. This model is abstract and 283 is used for design; it MUST be turned into a data model for 284 implementation. 286 Generic Policy Data Model: a model of policy rules that are dependent 287 on data repository, data definition, query, implementation languages, 288 and protocol. 290 ECA Policy Rule Information Data Model (EPRIM): represents a policy 291 rule as a statement that consists of an event clause, a condition 292 clause, and an action clause. This type of Policy Rule explicitly 293 defines the current and desired states of the system being managed. 294 This model is abstract and is used for design; it MUST be turned into 295 a data model for implementation. 297 ECA Policy Rule Data Model: a model of policy rules, derived from 298 EPRIM, that consist of an event clause, a condition clause, and an 299 action clause. 301 EMS/NMS/Controller: represents one or more entities that are able to 302 control the operation and management of a network infrastructure 303 (e.g., a network topology that consists of Network Elements). 305 Network Service and Resource Data Models: models of the service as 306 well as physical and virtual network topology including the resource 307 attributes (e.g., data rate or latency of links) and operational 308 parameters needed to support service deployment over the network 309 topology. 311 Network Element (NE), which can interact with local or remote 312 EMS/NMS/Controller in order to exchange information, such as 313 configuration information, policy enforcement capabilities, and 314 network status. 316 Relationship between Policy, Service and Resource models can be 317 illustrated by the figure below. 319 +---------------+ +----------------+ 320 | Policy | (1) | Service | 321 | |*******************| | 322 | ( SUPA ) |*******************| ( L3SM, ... ) | 323 +---------------+ +----------------+ 324 ** /*\ 325 ** * 326 ** * 327 (2) ** * (3) 328 ** * 329 ** * 330 ** * 331 +-------------------+ 332 | Resource | 333 | | 334 | (Inventory, ... ) | 335 +-------------------+ 337 Figure 3: Relationship between Policy, Service and Resource models 339 In Figure 3: 341 (1) policy manages and can adjust service behavior as necessary 342 (1:1..n) 343 (2) policy manages and can adjust resource behavior as necessary 344 (1:1..n) 345 (3) resource hosts service; changing resources may change service 346 behavior as necessary 348 Policies are used to control the management of resources and 349 services, while data from resources and services are used to select 350 and/or modify policies during runtime. More importantly, policies 351 can be used to manage how resources are allocated and assigned to 352 services. This enables a single policy to manage one or multiple 353 services and resources as well as their dependencies. (1:1..n) in (1) 354 and (2) below figure 3 shows one policy rule is able to manages and 355 can adjust one or multiple services/resources. Line (1) and (2) 356 connecting policy to resource and policy to service are same, and 357 line (3) connecting resource to service is different as it's 358 navigable only from resource to service. 360 3.2. Operation 362 SUPA can be used to define various types of policies, including 363 policies that affect services and/or the configuration of individual 364 or groups of network elements. SUPA can be used by a centralized 365 and/or distributed set of entities for creating, managing, 366 interacting with, and retiring policy rules. 368 The SUPA scope is limited to policy information and data models. 369 SUPA will not define network resource data models or network service 370 data models; both are out of scope. Instead, SUPA will make use of 371 network resource data models defined by other WGs or SDOs. 373 Declarative policies that specify the goals to be achieved but not 374 how to achieve those goals (also called "intent-based" policies) are 375 out of scope for the initial phase of SUPA. 377 3.3. The GPIM and the EPRIM 379 The GPIM provides a common vocabulary for representing concepts that 380 are common to expressing different types of policy, but which are 381 independent of language, protocol, repository, and level of 382 abstraction. Hence, the GPIM defines concepts and vocabulary needed 383 by policy management systems independent of the form and content of 384 the policy. The ERPIM is a more specific model that refines the GPIM 385 to specify policy rules in an event-condition-action form. 387 This enables different policies at different levels of abstraction to 388 form a continuum, where more abstract policies can be translated into 389 more concrete policies, and vice-versa. For example, the information 390 model can be extended by generalizing concepts from an existing data 391 model into the GPIM; the GPIM extensions can then be used by other 392 data models. 394 3.4. Creation of Generic YANG Modules 396 An information model is abstract. As such, it cannot be directly 397 instantiated (i.e., objects cannot be created directly from it). 398 Therefore, both the GPIM and the combination of the GPIM and the 399 EPRIM, are translated to generic YANG modules. 401 SUPA will provide guidelines for translating the GPIM (or the 402 combination of the GPIM and the EPRIM) into concrete YANG data models 403 that define how to manage and communicate policies between systems. 404 Multiple imperative policy YANG data models may be instantiated from 405 the GPIM (or the combination of the GPIM and the EPRIM). In 406 particular, SUPA will specify a set of YANG data models that will 407 consist of a base policy model for representing policy management 408 concepts independent of the type or structure of a policy, and as 409 well, an extension for defining policy rules according to the ECA 410 paradigm.(Note from Editor: This means that policies can be defined 411 using the GPIM directly, or using the combination of the GPIM and the 412 EPRIM. If you use only the GPIM, you get a technology- and vendor- 413 independent information model that you are free to map to the data 414 model of your choice; note that the structure of a policy is NOT 415 defined. If you use the GPIM and the EPRIM, you get a technology- 416 and vendor-independent information model that defines policies as an 417 event-condition-action (i.e., imperative) rule.) 419 The process of developing the GPIM, EPRIM and the derived/translated 420 YANG data models is realized following the sequence shown below. 421 After completing this process and if the implementation of the YANG 422 data models requires it, the GPIM and EPRIM and the derived/ 423 translated YANG data models are updated and synchronized. 425 (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1') 427 Where, (1)=GPIM; (2)=EPRIM; (3)=YANG data models; (4)= 428 Implementation; (3')= update of YANG data models; (2')=update of 429 EPRIM; (1') = update of GPIM 431 The YANG module derived from the GPIM contains concepts and 432 terminology for the common operation and administration of policy- 433 based systems, as well as an extensible structure for policy rules of 434 different paradigms. The YANG module derived from the EPRIM extends 435 the generic nature of the GPIM to represent policies using an event- 436 condition-action structure. 438 The above sequence allows for the addition of new, as well as the 439 editing of existing model elements in the GPIM and EPRIM. In 440 practice, the implementation sequence may be much simpler. 441 Specifically, it is unlikely that the GPIM will need to be changed. 442 In addition, changes to the EPRIM will likely be focused on fine- 443 tuning the behavior offered by a specific set of model elements. 445 4. Security Considerations 447 TBD 449 5. IANA Considerations 451 This document has no actions for IANA. 453 6. Contributors 455 The following people all contributed to creating this document, 456 listed in alphabetical order: 458 Ying Chen, China Unicom 459 Luis M. Contreras, Telefonica I+D 460 Dan Romascanu, Avaya 461 J. Schoenwaelder, Jacobs University, Germany 462 Qiong Sun, China Telecom 464 7. Acknowledgements 466 This document has benefited from reviews, suggestions, comments and 467 proposed text provided by the following members, listed in 468 alphabetical order: Andy Bierman, Benoit Claise, Joel Halpern, 469 Jonathan Hansford, Bert Wijnen, Tianran Zhou. 471 Part of the initial draft of this document was picked up from 472 previous documents, and this section lists the acknowledgements from 473 them. 475 From "SUPA Value Proposition" [I-D.klyus-supa-value-proposition] 477 The following people all contributed to creating this document, 478 listed in alphabetical order: 480 Vikram Choudhary, Huawei Technologies 481 Luis M. Contreras, Telefonica I+D 482 Dan Romascanu, Avaya 483 J. Schoenwaelder, Jacobs University, Germany 484 Qiong Sun, China Telecom 485 Parviz Yegani, Juniper Networks 487 This document has benefited from reviews, suggestions, comments and 488 proposed text provided by the following members, listed in 489 alphabetical order: H. Rafiee, J. Saperia and C. Zhou. 491 The authors of "SUPA Value Proposition" [I-D.klyus-supa-value- 492 proposition] were: 494 Maxim Klyus, Ed. , NetCracker 495 John Strassner, Ed. , Huawei Technologies 496 Will(Shucheng) Liu, Huawei Technologies 497 Georgios Karagiannis, Huawei Technologies 498 Jun Bi, Tsinghua University 500 The initial draft of this document merged one document, and this 501 section lists the acknowledgements from it. 503 From "Problem Statement for Simplified Use of Policy Abstractions 504 (SUPA)" [I-D.karagiannis-supa-problem-statement] 506 The authors of this draft would like to thank the following persons 507 for the provided valuable feedback and contributions: Diego Lopez, 508 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 509 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon 510 Perreault, Fernando Gont, Jose Saldana, Tom Taylor, Kostas 511 Pentikousis, Juergen Schoenwaelder, John Strassner, Eric Voit, Scott 512 O. Bradner, Marco Liebsch, Scott Cadzow, Marie-Jose Montpetit. Tina 513 Tsou, Will Liu and Jean-Francois Tremblay contributed to an early 514 version of this draft. 516 The authors of "Problem Statement for Simplified Use of Policy 517 Abstractions (SUPA)" [I-D.karagiannis-supa-problem-statement] were: 519 Georgios Karagiannis, Huawei Technologies 520 Qiong Sun, China Telecom 521 Luis M. Contreras, Telefonica 522 Parviz Yegani, Juniper 523 John Strassner, Huawei Technologies 524 Jun Bi, Tsinghua University 526 From "The Framework of Simplified Use of Policy Abstractions (SUPA)" 527 [I-D.zhou-supa-framework] 529 The authors of this draft would like to thank the following persons 530 for the provided valuable feedback: Diego Lopez, Jose Saldana, 531 Spencer Dawkins, Jun Bi, Xing Li, Chongfeng Xie, Benoit Claise, Ian 532 Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Mohamed 533 Boucadair, Jean Francois Tremblay, Tom Taylor, Tina Tsou, Georgios 534 Karagiannis, John Strassner, Raghav Rao, Jing Huang. 536 The authors of "The Framework of Simplified Use of Policy 537 Abstractions (SUPA)" [I-D.zhou-supa-framework] were: 539 Cathy Zhou, Huawei Technologies 540 Luis M. Contreras, Telefonica 541 Qiong Sun, China Telecom 542 Parviz Yegani, Juniper 544 8. References 546 8.1. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, 550 DOI 10.17487/RFC2119, March 1997, 551 . 553 8.2. Informative References 555 [I-D.ietf-supa-generic-policy-data-model] 556 Halpern, J. and J. Strassner, "Generic Policy Data Model 557 for Simplified Use of Policy Abstractions (SUPA)", draft- 558 ietf-supa-generic-policy-data-model-02 (work in progress), 559 October 2016. 561 [I-D.ietf-supa-generic-policy-info-model] 562 Strassner, J., Halpern, J., and S. Meer, "Generic Policy 563 Information Model for Simplified Use of Policy 564 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 565 model-02 (work in progress), January 2017. 567 [I-D.karagiannis-supa-problem-statement] 568 Karagiannis, G., Strassner, J., Qiong, Q., Contreras, L., 569 Yegani, P., and J. Bi, "Problem Statement for Simplified 570 Use of Policy Abstractions (SUPA)", draft-karagiannis- 571 supa-problem-statement-07 (work in progress), June 2015. 573 [I-D.klyus-supa-value-proposition] 574 Klyus, M., Strassner, J., (Will), S., Karagiannis, G., and 575 J. Bi, "SUPA Value Proposition", draft-klyus-supa-value- 576 proposition-00 (work in progress), March 2016. 578 [I-D.zhou-supa-framework] 579 Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The 580 Framework of Simplified Use of Policy Abstractions 581 (SUPA)", draft-zhou-supa-framework-02 (work in progress), 582 May 2015. 584 [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, 585 M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, 586 J., and S. Waldbusser, "Terminology for Policy-Based 587 Management", RFC 3198, DOI 10.17487/RFC3198, November 588 2001, . 590 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 591 the Network Configuration Protocol (NETCONF)", RFC 6020, 592 DOI 10.17487/RFC6020, October 2010, 593 . 595 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 596 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 597 "Application-Layer Traffic Optimization (ALTO) Protocol", 598 RFC 7285, DOI 10.17487/RFC7285, September 2014, 599 . 601 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 602 RFC 7950, DOI 10.17487/RFC7950, August 2016, 603 . 605 Authors' Addresses 607 Will(Shucheng) Liu 608 Huawei Technologies 609 Bantian, Longgang District 610 Shenzhen 518129 611 P.R. China 613 Email: liushucheng@huawei.com 615 Chongfeng Xie 616 China Telecom Beijing Research Institute 617 China Telecom Information Technology Innovation Park 618 Beijing 102209 619 P.R. China 621 Email: xiechf.bri@chinatelecom.cn 623 John Strassner 624 Huawei Technologies 625 2330 Central Expressway 626 Santa Clara 95138 627 CA USA 629 Email: john.sc.strassner@huawei.com 631 Georgios Karagiannis 632 Huawei Technologies 633 Hansaallee 205 634 Dusseldorf 40549 635 Germany 637 Email: Georgios.Karagiannis@huawei.com 639 Maxim Klyus 640 NetCracker 641 Kozhevnicheskaya str.,7 Bldg. #1 642 Moscow 643 Russia 645 Email: klyus@netcracker.com 646 Jun Bi 647 Tsinghua University 648 Network Research Center, Tsinghua University 649 Beijing 100084 650 P.R. China 652 Email: junbi@tsinghua.edu.cn