diff options
Diffstat (limited to 'doc/rfc/rfc8328.txt')
-rw-r--r-- | doc/rfc/rfc8328.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc8328.txt b/doc/rfc/rfc8328.txt new file mode 100644 index 0000000..0b8297d --- /dev/null +++ b/doc/rfc/rfc8328.txt @@ -0,0 +1,843 @@ + + + + + + +Independent Submission W. Liu +Request for Comments: 8328 Huawei Technologies +Category: Informational C. Xie +ISSN: 2070-1721 China Telecom + J. Strassner + G. Karagiannis + Huawei Technologies + M. Klyus + + J. Bi + Tsinghua University + Y. Cheng + China Unicom + D. Zhang + Huawei Technologies + March 2018 + + + Policy-Based Management Framework for + the Simplified Use of Policy Abstractions (SUPA) + +Abstract + + The Simplified Use of Policy Abstractions (SUPA) policy-based + management framework defines base YANG data models to encode policy. + These models point to device-, technology-, and service-specific YANG + data models developed elsewhere. Policy rules within an operator's + environment can be used to express high-level, possibly network-wide, + policies to a network management function (within a controller, an + orchestrator, or a network element). The network management function + can then control the configuration and/or monitoring of network + elements and services. This document describes the SUPA basic + framework, its elements, and interfaces. + + + + + + + + + + + + + + + + + + +Liu, et al. Informational [Page 1] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8328. + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2.2. Abbreviations and Definitions . . . . . . . . . . . . . . 4 + 3. Framework for Generic Policy-Based Management . . . . . . . . 5 + 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.3. The GPIM and the EPRIM . . . . . . . . . . . . . . . . . 10 + 3.4. Creation of Generic YANG Modules . . . . . . . . . . . . 10 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 6.2. Informative References . . . . . . . . . . . . . . . . . 12 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + + + + +Liu, et al. Informational [Page 2] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + +1. Introduction + + Traffic flows over increasingly complex enterprise and service + provider networks are becoming more and more important. Meanwhile, + the rapid growth of this variety makes the task of network operations + and management applications deploying new services much more + difficult. Moreover, network operators want to deploy new services + quickly and efficiently. Two possible mechanisms for dealing with + this growing difficulty are 1) the use of software abstractions to + simplify the design and configuration of monitoring and control + operations and 2) the use of programmatic control over the + configuration and operation of such networks. Policy-based + management can be used to combine these two mechanisms into an + extensible framework. + + There is a set of policy rules within an operator's environment that + defines how services are designed, delivered, and operated. + + The SUPA (Simplified Use of Policy Abstractions) data model + represents a high-level, possibly network-wide policy, which can be + input to a network management function (within a controller, an + orchestrator, or a network element). The network management function + can then control the configuration and/or monitoring of network + elements and services according to such policies. + + SUPA defines a Generic Policy Information Model (GPIM) [SUPA-INFO] + for use in network operations and management applications. The GPIM + defines concepts and terminology needed by policy management + independent of the form and content of the policy rule. The Event- + Condition-Action (ECA) Policy Rule Information Model (EPRIM) + [SUPA-INFO] extends the GPIM by defining how to build policy rules + according to the ECA paradigm. + + Both the GPIM and the EPRIM are targeted at controlling the + configuration and monitoring of network elements throughout the + service development and deployment life cycle. The GPIM and the + EPRIM can both be translated into corresponding YANG [RFC6020] + [RFC7950] modules that define policy concepts, terminology, and rules + in a generic and interoperable manner; additional YANG modules may + also be derived from the GPIM and/or EPRIM to manage specific + functions. + + The key benefit of policy management is that it enables different + network elements and services to be instructed to behave the same + way, even if they are programmed differently. Management + applications will benefit from using policy rules that enable + scalable and consistent programmatic control over the configuration + and monitoring of network elements and services. + + + +Liu, et al. Informational [Page 3] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + Some typical and useful instances for authors to understand the + applicability of SUPA, such as SNMP blocking upon load of link + reaching a threshold and virtual matching migration upon the changing + of user location, are described in [SUPA-APP]. + +2. Terminology + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2.2. Abbreviations and Definitions + + SUPA: The Simplified Use of Policy Abstractions is a policy-based + management framework that defines a data model to be used to + represent high-level, possibly network-wide policies. This data + model can be input to a network management function (within a + controller, an orchestrator, or a network element). + + YANG: An acronym for "Yet Another Next Generation". YANG is a data + modeling language used to model configuration and state data + manipulated by the Network Configuration Protocol (NETCONF), NETCONF + remote procedure calls, and NETCONF notifications [RFC6020] + + ECA: Event-Condition-Action is a shortcut for referring to the + structure of active rules in event-driven architecture and active + database systems. + + EMS: An Element Management System is software used to monitor and + control network elements (devices) in telecommunications. + + NMS: A Network Management System is a set of hardware and/or software + tools that allow an IT professional to supervise the individual + components of a network within a larger network management framework. + + OSS: An Operations/Operational Support System is a computer system + used by telecommunications service providers to manage their networks + (e.g., telephone networks). + + BSS: A Business Support System is used to support various end-to-end + telecommunication services. + + + + + + +Liu, et al. Informational [Page 4] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + GPIM: A Generic Policy Information Model defines concepts and + terminology needed by policy management independent of the form and + content of the policy rule. + + EPRIM: An ECA Policy Rule Information Model extends the GPIM by + defining how to build policy rules according to the ECA paradigm. + + GPDM: Generic Policy Data Models [SUPA-DATA] are created from the + GPIM. These YANG data model policies are used to control the + configuration of network elements that model the service(s) to be + managed. The relationship between the information model (IM) and + data model (DM) can be founded in [RFC3444]. + + Declarative Policy: Policies that specify the goals to be achieved + but not how to achieve those goals (also called "intent-based" + policies). Please note that declarative policies are out of scope + for the initial phase of SUPA. + +3. Framework for Generic Policy-Based Management + + This section briefly describes the design and operation of the SUPA + policy-based management framework. + +3.1. Overview + + Figure 1 shows a simplified functional architecture of how SUPA is + used to define policies for creating snippets of network element + configurations. SUPA uses the GPIM to define a consensual vocabulary + that different actors can use to interact with network elements and + services. The EPRIM defines a generic structure for imperative + policies. The GPIM, and/or the combination of the GPIM and the + EPRIM, is converted to generic YANG modules. + + In one possible approach (shown with asterisks in Figure 1), SUPA + Generic Policy and SUPA ECA Policy YANG modules together with the + Resource and Service YANG data models specified in the IETF (which + define the specific elements that will be controlled by policies) are + used by the Service Interface Logic. This Service Interface Logic + creates appropriate input mechanisms for the operator to define + policies (e.g., a web form or a script) for creating and managing the + network configuration. The operator interacts with the interface, + and the policies input by operators are then translated into + configuration snippets. + + Note that the Resource and Service YANG data models may not exist. + In this case, the SUPA generic policy YANG modules serve as an + extensible basis to develop new YANG data models for the Service + Interface Logic. This transfers the work specified by the Resource + + + +Liu, et al. Informational [Page 5] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + and Service YANG data models specified in the IETF into the Service + Interface Logic. + + +---------------------+ + +----------+ \| SUPA | + | IETF |---+----+ Information Models | + +----------+ | /| GPIM and EPRIM | + | +---------+-----------+ + Assignments | | Defines Policy Concepts + and Managed | \|/ + Content | +---------+-----------+ + | \| SUPA Generic | + +----+ & ECA Policy | + /| YANG modules | + +---------+-----------+ + * Possible Approach + +-----------------------------*-----------------------------+ + | Management System * | + | \*/ | + | Fills +---------+---------+ +-------------+ | + | +--------+ Forms \| Service Interface |/ |Resource and |/ | +----+ + | |Operator|--------+ Logic +--|Service YANG |----|IETF| + | +--------+ Runs /| (locally defined |\ | data models |\ | +----+ + | scripts |forms, scripts,...)| +-------------+ | + | +---------+---------+ | + | \|/ | + | +-------+--------+ | + | | Local Devices | | + | | and Management | | + | | Systems | | + | +----------------+ | + +-----------------------------------------------------------+ + + Figure 1: SUPA Framework + + Figure 1 shows the SUPA Framework at a high level of abstraction. + The operator actor can interact with SUPA in other ways not shown in + Figure 1. In addition, other actors (e.g., an application developer) + that can interact with SUPA are not shown for simplicity. + + The EPRIM defines an ECA policy as an example of imperative policies. + An ECA policy rule is activated when its event clause is true; the + condition clause is then evaluated and, if true, signals the + execution of one or more actions in the action clause. This type of + policy explicitly defines the current and desired states of the + system being managed. Imperative policy rules require additional + management functions, which are explained in Section 3.2. + + + + +Liu, et al. Informational [Page 6] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + Figure 2 shows how the SUPA Policy Model is used to create policy + data models step-by-step and how the policy rules are used to + communicate among various network management functions located on + different layers. + + The GPIM is used to construct policies. The GPIM defines generic + policy concepts as well as two types of policies: ECA policy rules + and declarative policy statements. + + A set of Generic Policy Data Models (GPDM) are then created from the + GPIM. These YANG data model policies are then used to control the + configuration of network elements that model the service(s) to be + managed. + + Resource and Service YANG Data Models: Models of the service as well + as physical and virtual network topology including the resource + attributes (e.g., data rate or latency of links) and operational + parameters needed to support service deployment over the network + topology. + + | SUPA Policy Model + | + | +----------------------------------+ + | | Generic Policy Information Model | + | +----------------------------------+ + | D D + | D +-------------v-------------+ + +----------------------+ | D | ECA Policy Rule | + | OSS/BSS/Orchestrator <--+ | D | Information Model | + +----------^-----------+ | | D +---------------------------+ + C | | D D + C | | +----+D+------------------------+D+---+ + C +-----+ D SUPA Policy Data Model D | + +----------v-----------+ | | ----v-----------------------+ D | + | EMS/NMS/Controller <--------+ | Generic Policy Data Model | D | + +----------^-----------+ | | ----------------------------+ D | + C +-----+ D D | + C | | | +---------v-----------------v--+ | + +----------v-----------+ | | | | ECA Policy Rule Data Model | | + | Network Element <--+ | | +------------------------------+ | + +----------------------+ | +-------------------------------------+ + | + | +Legend: +The double-headed arrow with Cs = "communication" +The arrow with Ds = "derived from" + + Figure 2: SUPA Policy Model Framework + + + +Liu, et al. Informational [Page 7] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + SUPA Policy Model: This model represents one or more policy modules + that contain the following entities: + + Generic Policy Information Model: A model for defining policy + rules that are independent of data repository, data definition, + query, implementation language, and protocol. This model is + abstract and is used for design; it MUST be turned into a data + model for implementation. + + Generic Policy Data Model: A model of policy rules that are + dependent on data repository, data definition, query, + implementation language, and protocol. + + ECA Policy Rule Information Model (EPRIM): This model represents + a policy rule as a statement that consists of an event clause, + a condition clause, and an action clause. This type of policy + rule explicitly defines the current and desired states of the + system being managed. This model is abstract and is used for + design; it MUST be turned into a data model for implementation. + + ECA Policy Rule Data Model: A model of policy rules, derived from + EPRIM, where each policy rule consists of an event clause, a + condition clause, and an action clause. + + EMS/NMS/Controller: This represents one or more entities that are + able to control the operation and management of a network + infrastructure (e.g., a network topology that consists of + network elements). + + Network Element (NE): An element that can interact with the local + or remote EMS/NMS/Controller in order to exchange information, + such as configuration information, policy-enforcement + capabilities, and network status. + + Relationships among Policy, Service, and Resource models are + illustrated in Figure 3. + + + + + + + + + + + + + + + +Liu, et al. Informational [Page 8] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + +---------------+ +----------------+ + | Policy | (1) | Service | + | |*******************| | + | ( SUPA ) |*******************| ( L3SM, ... ) | + +---------------+ +----------------+ + ** /*\ + ** * + ** * + (2) ** * (3) + ** * + ** * + ** * + +-------------------+ + | Resource | + | | + | (Inventory, ... ) | + +-------------------+ + + Figure 3: Relationship among Policy, Service, and Resource Models + + In Figure 3: + + (1) The policy manages and can adjust service behavior as necessary + (1:1..n). In addition, data from resources and services are + used to select and/or modify policies during runtime. + + (2) The policy manages and can adjust resource behavior as necessary + (1:1..n). + + (3) Resource hosts service; changing resources may change service + behavior as necessary. + + Policies are used to control the management of resources and + services, while data from resources and services are used to select + and/or modify policies during runtime. More importantly, policies + can be used to manage how resources are allocated and assigned to + services. This enables a single policy to manage one or multiple + services and resources as well as their dependencies. The use of + (1:1..n) in point (1) and (2) above show that one policy rule is able + to manage and can adjust one or multiple services/resources. Lines + (1) and (2) (connecting policy to resource and policy to service) are + the same, and line (3) (connecting resource to service) is different + as it's navigable only from resource to service. + + + + + + + + +Liu, et al. Informational [Page 9] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + +3.2. Operation + + SUPA can be used to define various types of policies, including + policies that affect services and/or the configuration of individual + network elements or groups of network elements. SUPA can be used by + a centralized and/or distributed set of entities for creating, + managing, interacting with, and retiring policy rules. + + The SUPA scope is limited to policy information and data models. + SUPA does not define network resource data models or network service + data models; both are out of scope. Instead, SUPA makes use of + network resource data models defined by other working groups or + Standards Development Organizations (SDOs). + + Declarative policies are out of scope for the initial phase of SUPA. + +3.3. The GPIM and the EPRIM + + The GPIM provides a shared vocabulary for representing concepts that + are common to different types of policies, but which are independent + of language, protocol, repository, and level of abstraction. Hence, + the GPIM defines concepts and vocabulary needed by policy management + systems independent of the form and content of the policy. The EPRIM + is a more specific model that refines the GPIM to specify policy + rules in an ECA form. + + This enables different policies at different levels of abstraction to + form a continuum, where more abstract policies can be translated into + more concrete policies and vice versa. For example, the information + model can be extended by generalizing concepts from an existing data + model into the GPIM; the GPIM extensions can then be used by other + data models. + +3.4. Creation of Generic YANG Modules + + An information model is abstract. As such, it cannot be directly + instantiated (i.e., objects cannot be created directly from it). + Therefore, both the GPIM and the combination of the GPIM and the + EPRIM are translated into generic YANG modules. + + SUPA will provide guidelines for translating the GPIM (or the + combination of the GPIM and the EPRIM) into concrete YANG data models + that define how to manage and communicate policies between systems. + Multiple imperative policy YANG data models may be instantiated from + the GPIM (or the combination of the GPIM and the EPRIM). In + particular, SUPA will specify a set of YANG data models that will + consist of a base policy model for representing policy management + concepts independent of the type or structure of a policy; it will + + + +Liu, et al. Informational [Page 10] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + also specify an extension for defining policy rules according to the + ECA paradigm. (Note: This means that policies can be defined using + the GPIM directly, or using the combination of the GPIM and the + EPRIM. If you use only the GPIM, you get a technology- and vendor- + independent information model that you are free to map to the data + model of your choice; note that the structure of a policy is NOT + defined. If you use the GPIM and the EPRIM, you get a technology- + and vendor-independent information model that defines policies as an + ECA policy rule (i.e., imperative).) + + The process of developing the GPIM, the EPRIM, and the derived/ + translated YANG data models is realized following the sequence shown + below. After completing this process and, if the implementation of + the YANG data models requires it, the GPIM and EPRIM and the derived/ + translated YANG data models are updated and synchronized. + + (1)=>(2)=>(3)=>(4)=>(3')=>(2')=>(1') + + Where: + (1)=GPIM + (2)=EPRIM + (3)=YANG data models + (4)=Implementation + (3')=update of YANG data models + (2')=update of EPRIM + (1')=update of GPIM + + The YANG module derived from the GPIM contains concepts and + terminology for the common operation and administration of policy- + based systems as well as an extensible structure for policy rules of + different paradigms. The YANG module derived from the EPRIM extends + the generic nature of the GPIM by representing policies using an ECA + structure. + + The above sequence allows for the addition of new model elements, as + well as the editing of existing ones, in the GPIM and EPRIM. In + practice, the implementation sequence may be much simpler. + Specifically, it is unlikely that the GPIM will need to be changed. + In addition, changes to the EPRIM will likely be focused on fine- + tuning the behavior offered by a specific set of model elements. + + + + + + + + + + + +Liu, et al. Informational [Page 11] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + +4. Security Considerations + + This informational document presents the framework and workflow of + SUPA as well as an explanation on the relationship of policy, service + and resources. This document does not introduce any new security + issues, and the framework has no security impact on the Internet. + The same considerations are relevant as those for the base NETCONF + protocol (see Section 9 in [RFC6241]). + +5. IANA Considerations + + This document has no IANA actions. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +6.2. Informative References + + [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between + Information Models and Data Models", RFC 3444, + DOI 10.17487/RFC3444, January 2003, + <https://www.rfc-editor.org/info/rfc3444>. + + [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", RFC 6020, + DOI 10.17487/RFC6020, October 2010, + <https://www.rfc-editor.org/info/rfc6020>. + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <https://www.rfc-editor.org/info/rfc6241>. + + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + <https://www.rfc-editor.org/info/rfc7950>. + + + + + +Liu, et al. Informational [Page 12] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + [SUPA-APP] Cheng, Y., Liu, D., Fu, B., Zhang, D., and N. Vadrevu, + "Applicability of SUPA", Work in Progress, + draft-cheng-supa-applicability-01, March 2017. + + [SUPA-DATA] + Halpern, J., Strassner, J., and S. Van der Meer, "Generic + Policy Data Model for Simplified Use of Policy + Abstractions (SUPA)", Work in Progress, draft-ietf-supa- + generic-policy-data-model-04, June 2017. + + [SUPA-FRAME] + Zhou, C., Contreras, L., Sun, Q., and P. Yegani, "The + Framework of Simplified Use of Policy Abstractions + (SUPA)", Work in Progress, draft-zhou-supa-framework-02, + May 2015. + + [SUPA-INFO] + Strassner, J., Halpern, J., and S. Meer, "Generic Policy + Information Model for Simplified Use of Policy + Abstractions (SUPA)", Work in Progress, draft-ietf-supa- + generic-policy-info-model-03, May 2017. + + [SUPA-STATE] + Karagiannis, G., Strassner, J., Sun, Q., Contreras, L., + Yegani, P., and J. Bi, "Problem Statement for Simplified + Use of Policy Abstractions (SUPA)", Work in Progress, + draft-karagiannis-supa-problem-statement-07, June 2015. + + [SUPA-VALUE] + Klyus, M., Strassner, J., Liu, W., Karagiannis, G., and J. + Bi, "SUPA Value Proposition", Work in Progress, + draft-klyus-supa-value-proposition-00, March 2016. + + + + + + + + + + + + + + + + + + + +Liu, et al. Informational [Page 13] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + +Acknowledgements + + This document has benefited from reviews, suggestions, comments, and + proposed text provided by the following members, listed in + alphabetical order: Andy Bierman, Marc Blanchet, Mohamed Boucadair, + Scott O. Bradner, Scott Cadzow, Zhen Cao, Vikram Choudhary, Benoit + Claise, Spencer Dawkins, Mehmet Ersue, Ian Farrer, Fernando Gont, + Joel Halpern, Jonathan Hansford, Jing Huang, Xing Li, Marco Liebsch, + Diego R. Lopez, Johannes Merkle, Marie-Jose Montpetit, Kostas + Pentikousis, Simon Perreault, Hosnieh Rafiee, Raghav Rao, Jose + Saldana, Jon Saperia, Tom Taylor, Jean Francois Tremblay, Tina Tsou, + Eric Voit, Gunter Wang, Yangyang Wang, Bert Wijnen, and Tianran Zhou. + + Part of the initial draft of this document was picked up from + previous documents: [SUPA-VALUE], [SUPA-STATE], and [SUPA-FRAME]. We + appreciatively acknowledge the authors, contributors, and + acknowledged parties of those documents. + +Contributors + + The following people contributed to the creation of this document, + listed in alphabetical order: + + Luis M. Contreras, Telefonica I+D + Dan Romascanu, Avaya + Juergen Schoenwaelder, Jacobs University, Germany + Qiong Sun, China Telecom + Parviz Yegani, Huawei Technologies + Cathy Zhou, Huawei Technologies + +Authors' Addresses + + Will (Shucheng) Liu + Huawei Technologies + Bantian, Longgang District + Shenzhen 518129 + China + + Email: liushucheng@huawei.com + + + Chongfeng Xie + China Telecom + China Telecom Information Technology Innovation Park + Beijing 102209 + China + + Email: xiechf.bri@chinatelecom.cn + + + +Liu, et al. Informational [Page 14] + +RFC 8328 SUPA Policy-Based Management Framework March 2018 + + + John Strassner + Huawei Technologies + 2330 Central Expressway + Santa Clara, CA 95138 + United States of America + + Email: john.sc.strassner@huawei.com + + + Georgios Karagiannis + Huawei Technologies + Hansaallee 205 + Dusseldorf 40549 + Germany + + Email: Georgios.Karagiannis@huawei.com + + + Maxim Klyus + + Email: xmaruto@gmail.com + + + Jun Bi + Tsinghua University + Network Research Center, Tsinghua University + Beijing 100084 + China + + Email: junbi@tsinghua.edu.cn + + + Ying Cheng + China Unicom + No.21 Financial Street, XiCheng District + Beijing 100033 + China + + Email: chengying10@chinaunicom.cn + + + Dacheng Zhang + Huawei Technologies + Beijing + China + + Email: dacheng.zhang@huawei.com + + + + +Liu, et al. Informational [Page 15] + |