RFC 8328
Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA)
📚 RFC 8328: Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA) 🎀
okay bestie, this one is the SUPA framework doc 💖 it's Informational, meaning it's published for info and is NOT a standards-track spec 🧚 it was an Independent Submission (so not from an IETF working group), dated March 2018, and it's been assigned ISSN 2070-1721 ✨
the author squad is giving team-project energy 👑: W. Liu (Huawei Technologies), C. Xie (China Telecom), J. Strassner, G. Karagiannis (Huawei Technologies), M. Klyus, J. Bi (Tsinghua University), Y. Cheng (China Unicom), and D. Zhang (Huawei Technologies) 🫶
the title block doesn't say it obsoletes or updates any other RFC, so this one stands on its own 🦋
Abstract ✨
okay so the big idea 🔥 SUPA is a policy-based management framework that defines base YANG data models for encoding policy 💅 those models point out to device, technology, and service specific YANG data models that live somewhere else 🌸
policy rules inside an operator's environment can express high-level, possibly network-wide policies to a network management function (that could sit in a controller, an orchestrator, or a network element) 💜 that function then controls the configuration and/or monitoring of network elements and services 🧚 this doc describes the SUPA basic framework, its elements, and its interfaces 💖
Status of This Memo ✨
ok this part is the legal-ish bit but it's important 🙈
- this doc is not an Internet Standards Track spec, it's published for informational purposes 🌈
- it's an independent contribution to the RFC Series, not tied to any other RFC stream 🦋
- the RFC Editor picked to publish it at its own discretion and makes no statement about its value for implementation or deployment 💀
- docs approved by the RFC Editor aren't candidates for any Internet Standard level, see Section 2 of RFC 7841 💅
- for current status, errata, or feedback, check
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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication 🎀 please read those carefully, since they spell out your rights and restrictions 🫶
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 . . . . . . . . . . . . . . . . . . . . . . . 141. Introduction 🦋
okay so traffic flows over enterprise and service provider networks are getting more and more complex, and it's giving "very important" 💅 meanwhile all that variety makes it way harder for network ops and management apps to deploy new services 😭 operators also want to ship new services quickly and efficiently 🚀
there are two possible mechanisms for this growing difficulty 🧚 1) software abstractions to simplify designing and configuring monitoring and control operations, and 2) programmatic control over how these networks are configured and operated 💖 policy-based management can mash those two together into an extensible framework 🌈
there's a set of policy rules inside an operator's environment that defines how services get designed, delivered, and operated 👑
the SUPA data model represents a high-level, possibly network-wide policy 🎀 it can be input to a network management function (within a controller, an orchestrator, or a network element) 💜 that function then controls the configuration and/or monitoring of network elements and services according to those policies 🫶
SUPA defines a Generic Policy Information Model (GPIM) [SUPA-INFO] for network ops and management apps 🌸 the GPIM has the concepts and terminology policy management needs, no matter what form or content the policy rule takes 🦋 the Event-Condition-Action (ECA) Policy Rule Information Model (EPRIM) [SUPA-INFO] builds on the GPIM by showing how to build policy rules with the ECA paradigm ✨
both the GPIM and the EPRIM target controlling the configuration and monitoring of network elements across the whole service development and deployment life cycle 💅 they can both be translated into corresponding YANG [RFC6020] [RFC7950] modules that define policy concepts, terminology, and rules in a generic, interoperable way 🧚 extra YANG modules can also be derived from the GPIM and/or EPRIM to manage specific functions 🌈
the key benefit of policy management? it lets different network elements and services be told to behave the same way, even if they're programmed differently 😭💖 management apps get to use policy rules that give scalable, consistent programmatic control over configuration and monitoring 🔥
some typical examples that help authors understand where SUPA applies, like SNMP blocking when a link load hits a threshold, and virtual matching migration when a user's location changes, 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 doc are to be read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they show up in all capitals, just like here 🦋
2.2. Abbreviations and Definitions ✨
SUPA: the Simplified Use of Policy Abstractions, a policy-based management framework that defines a data model for representing high-level, possibly network-wide policies 💅 that data model can be input to a network management function (within a controller, an orchestrator, or a network element) 🧚
YANG: short for "Yet Another Next Generation" 🌈 it's a data modeling language used to model configuration and state data that gets manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications [RFC6020] 💖
ECA: Event-Condition-Action, a shortcut for the structure of active rules in event-driven architectures and active database systems 🔥
EMS: an Element Management System, software used to monitor and control network elements (devices) in telecoms 🎀
NMS: a Network Management System, a set of hardware and/or software tools that lets an IT pro supervise the individual components of a network inside a bigger network management framework 🫶
OSS: an Operations/Operational Support System, a computer system telecom service providers use to manage their networks (e.g., telephone networks) 🌸
BSS: a Business Support System, used to support various end-to-end telecom services 👑
GPIM: a Generic Policy Information Model, which defines the concepts and terminology policy management needs, independent of the form and content of the policy rule 🦋
EPRIM: an ECA Policy Rule Information Model, which extends the GPIM by showing how to build policy rules with 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 the network elements that model the service(s) being 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 them (also called "intent-based" policies) 💖 heads up though, 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 💜
(part 2 is coming next, bestie, so stay tuned 🎀✨)
3.1. Overview ✨
okay so Figure 1 is the whole SUPA vibe in one picture 🦋 It shows how SUPA gets used to define policies for making little snippets of network element configurations. SUPA uses the GPIM as a shared vocabulary so different actors can talk to network elements and services without confusion 💬 The EPRIM gives you a generic structure for imperative policies 🎀 And the GPIM, or the GPIM and the EPRIM together, gets converted into generic YANG modules ✨
In one possible approach (the one drawn with asterisks in Figure 1), the SUPA Generic Policy and SUPA ECA Policy YANG modules get used together with the Resource and Service YANG data models from the IETF 💅 Those data models are what define the specific elements that policies will control. The Service Interface Logic uses all of that to make input mechanisms for the operator, like a web form or a script 🧚 The operator uses that interface to create and manage the network configuration, and the policies they put in get translated into configuration snippets 🌸
Quick caveat, bestie: the Resource and Service YANG data models might not exist yet 😭 If they don't, the SUPA generic policy YANG modules work as an extensible base for building new YANG data models for the Service Interface Logic. That basically moves the work that the IETF's Resource and Service YANG data models would have covered into the Service Interface Logic itself 🫶
+---------------------+
+----------+ \| 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 🦋 The operator can also interact with SUPA in ways that aren't drawn in Figure 1 ✨ And other actors, like an application developer, can interact with SUPA too, but they're left out of the picture to keep things simple 💖
The EPRIM defines an ECA policy as its example of an imperative policy 🔥 Here's how it works: an ECA policy rule gets activated when its event clause is true. Then the condition clause gets evaluated, and if that's true, it signals one or more actions in the action clause to run ⚡ This type of policy explicitly defines the current and desired states of the system being managed, which is so iconic 👑 Imperative policy rules also need some extra management functions, and those get explained in Section 3.2 🎀
Figure 2 shows how the SUPA Policy Model is used to build policy data models step by step 🧚 It also shows how policy rules help different network management functions talk to each other across different layers 🌈
The GPIM is what you use to construct policies 💅 It defines generic policy concepts plus two types of policies: ECA policy rules and declarative policy statements 🫶
After that, a set of Generic Policy Data Models (GPDM) gets created from the GPIM 🌸 These YANG data model policies are then used to control the configuration of the network elements that model the service or services being managed 💜
Resource and Service YANG Data Models are models of the service, plus the physical and virtual network topology. They cover resource attributes (like the data rate or latency of links) and the operational parameters needed to support deploying the service over that 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
Now the SUPA Policy Model itself 💖 It represents one or more policy modules, and those contain the following entities:
- Generic Policy Information Model: A model for defining policy rules that don't depend on data repository, data definition, query, implementation language, or protocol 🌈 It's abstract and used for design. It MUST be turned into a data model for implementation 🫶
- Generic Policy Data Model: A model of policy rules that does depend 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 made up 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. The model is abstract and used for design, and it MUST be turned into a data model for implementation 💅
- ECA Policy Rule Data Model: A model of policy rules that's derived from EPRIM, where each policy rule has an event clause, a condition clause, and an action clause 🎀
- EMS/NMS/Controller: This stands for one or more entities that can control the operation and management of a network infrastructure, like a network topology made up of network elements 👑
- Network Element (NE): An element that can interact with a local or remote EMS/NMS/Controller to exchange information, such as configuration information, policy-enforcement capabilities, and network status 🦋
Relationships among the Policy, Service, and Resource models are illustrated in Figure 3 🌸
+---------------+ +----------------+
| 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). On top of that, data from resources and services gets used to select and/or modify policies during runtime 🔥
(2) The policy manages and can adjust resource behavior as necessary (1:1..n) 💜
(3) The resource hosts the service, so changing resources may change service behavior as necessary 🍓
Policies control the management of resources and services, while data from resources and services gets used to select and/or modify policies during runtime 🫶 Even better, policies can manage how resources get allocated and assigned to services 👑 That means a single policy can manage one or multiple services and resources, plus their dependencies 🧚 The (1:1..n) notation in points (1) and (2) above means one policy rule can manage and adjust one or multiple services or resources 💖 Lines (1) and (2), which connect policy to resource and policy to service, work the same way. Line (3), which connects resource to service, is different, because it's navigable only from resource to service 🦋
3.2. Operation 💅
SUPA can be used to define different types of policies, including policies that affect services, the configuration of individual network elements, or groups of network elements 🎀 It can be used by a centralized set of entities, a distributed set, or both, 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 the 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
okay so the GPIM is basically the shared vocab bestie 📚✨ It gives you a common set of concepts that show up across all kinds of policies, and it doesn't care what language, protocol, repository, or level of abstraction you're using 💅 So it defines the concepts and vocab policy management systems need, no matter what the policy looks like. The EPRIM is the more specific one 🎀 It refines the GPIM so policy rules come out in an ECA form.
This lets policies at different levels of abstraction form a continuum 🌈 Abstract policies can get translated into more concrete ones, and back again, no cap. For example, you can extend the information model by generalizing concepts from an existing data model into the GPIM, and then other data models can use those GPIM extensions 🦋
3.4. Creation of Generic YANG Modules
ok so an information model is abstract 🙃 That means you can't directly instantiate it (you can't create objects straight from it). So both the GPIM and the GPIM + EPRIM combo get translated into generic YANG modules 🧚
SUPA is gonna 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). Specifically, SUPA will specify a set of YANG data models: a base policy model for representing policy management concepts independent of the type or structure of a policy, plus an extension for defining policy rules according to the ECA paradigm.
Note: This means 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 follows the sequence shown below. After completing this process, and if implementing the YANG data models requires it, the GPIM, the EPRIM, and the derived/translated YANG data models get 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 GPIMThe YANG module derived from the GPIM holds concepts and terminology for the common operation and administration of policy-based systems, plus 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 sequence above allows for adding new model elements, as well as editing existing ones, in the GPIM and EPRIM. In practice, though, the implementation sequence may be much simpler 🙌 Specifically, it's unlikely that the GPIM will need to change. And changes to the EPRIM will likely focus on fine-tuning the behavior offered by a specific set of model elements 🫶
4. Security Considerations 🚨
This informational document presents the framework and workflow of SUPA, as well as an explanation of the relationship between 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>.
[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.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
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📦 where this page comes from
- ietf: rfc8328 2018-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms