idnits 2.17.00 (12 Aug 2021) /tmp/idnits997/draft-bw-supa-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 == Line 88 has weird spacing: '...l event poli...' -- The document date (April 6, 2016) is 2229 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.bw-supa-declarative-policy-data-model' is defined on line 170, but no explicit reference was found in the text == Unused Reference: 'I-D.chen-supa-eca-data-model' is defined on line 175, but no explicit reference was found in the text == Unused Reference: 'I-D.klyus-supa-proposition' is defined on line 180, but no explicit reference was found in the text == Unused Reference: 'I-D.xia-sdnrg-nemo-language' is defined on line 185, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 190, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-xia-sdnrg-nemo-language-03 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUPA T. Zhou 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track B. Wijnen, Ed. 5 Expires: October 8, 2016 Consultant 6 April 6, 2016 8 Architecture/Framework for SUPA 9 draft-bw-supa-architecture-00 11 Abstract 13 This document describes the architecture and framework for the Simple 14 Use of Policy Abtractions (SUPA). It also gives an overview of the 15 SUPA components. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 8, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Position of the policy engine . . . . . . . . . . . . . . . . 2 53 3. policy engine framework . . . . . . . . . . . . . . . . . . . 2 54 4. Policy Data Model . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Information Model . . . . . . . . . . . . . . . . . . . . . . 4 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 9. Informative References . . . . . . . . . . . . . . . . . . . 4 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 2. Position of the policy engine 66 A network can be modeled with multiple layers. Policies can be 67 applied to all the layers to achieve requirements from various type 68 of actors. 70 device-level: policy can only be accessed and enforced on one 71 device. The policy controls the dynamic behaviours, e.g. QoS, 72 decapsulation, encapsulation, and forwarding. 74 network-level: policy can be configured to communicate with 75 multiple network elements. The policy controls the adjustment of 76 technique related network solutions, e.g. L3VPN, L2VPN. 78 service-level: policies are abstracted to be technique 79 independent, and provided for the higher level users. The 80 customer facing policy is provided to reduce the operation on 81 service level agreement, generic VPN service, unified tunnel 82 services. 84 3. policy engine framework 86 Figure 1 depicts the policy engine framework. 88 higher level event policy operations 89 ^ + 90 | | 91 | | 92 +-------+------------v-------+ 93 | <------+ 94 | Policy Engine | concrete policy DM 95 | | 96 +-------^------------+-------+ 97 | | 98 | | 99 + v 100 lower level event policy execution 102 Figure 1: Figure 1 The policy engine framework 104 The policy engine is configured with concrete policy DMs, so that it 105 can deal with assigned policies. The concrete policy DM can generate 106 data-store and northbound interface for the policy engine. One or 107 more standard protocols should be selected (e.g., NETCONF, RESTCONF) 108 for policy operations to communicate with the Policy Engine. The 109 policy engine runs with monitoring the lower level events from the 110 southbound. The policy engine execute policies by doing actions or 111 decomposing the policy to lower level policies. Higher level events 112 may be generated by the policy engine, so that policy engine or 113 applications sitting on a higher level can consume. 115 4. Policy Data Model 117 The policy data model describes in detail about the protocol 118 operations and data-store content. It serves as an "API contract" 119 honored by the policy engine, and is essential to the model driven 120 policy API. The well defined policy model structure facilitates both 121 flexibility and extensibility. 123 generic policy model: defines a generic policy header and the 124 policy body structure. The generic policy header contains 125 information on, e.g. name, identifier, life cycle, which can be 126 shared by all the specific policy models. The generic policy body 127 could be a ordered list of policy rules. But the details on how 128 the policy rule like is extended by the specific policy model, 129 e.g. Event Condition Action (ECA) policy model. 131 specific policy model: inherits from the generic policy model with 132 specific extensions on the policy rule. For example the ECA 133 policy model extends the policy rule with Event-Condition-Action 134 definition. 136 concrete policy model: is rendered based on the specific model by 137 SDOs, vendors or operators. It represents concrete technique and 138 vendor implementation. For example, a concrete Event, like time 139 event, packet-in. 141 5. Information Model 143 How the information model can help data model generation? What 144 should be defined in the Information Model (IM), what in the Data 145 Model (DM)? 147 The IM document can have more words introducing what an item is 148 and why we need an item. The IM helps other DM creation rather 149 than YANG both in and outside IETF. 151 The DM document should be more on how to represent informations in 152 for example YANG 154 6. Security Considerations 156 To do 158 7. IANA Considerations 160 This memo includes no request to IANA. 162 8. Acknowledgements 164 The authors would like to thanks the valuable comments made by:. 166 This document was produced using the xml2rfc tool [RFC2629]. 168 9. Informative References 170 [I-D.bw-supa-declarative-policy-data-model] 171 Zhou, T., Xia, Y., and B. Wijnen, "A YANG Data Model for 172 Declarative Policy", draft-bw-supa-declarative-policy- 173 data-model-00 (work in progress), December 2015. 175 [I-D.chen-supa-eca-data-model] 176 Chen, M., Contreras, L., Hayashi, M., and T. Tsou, "ECA 177 Policy YANG Data Model", draft-chen-supa-eca-data-model-05 178 (work in progress), October 2015. 180 [I-D.klyus-supa-proposition] 181 Klyus, M. and J. Strassner, "SUPA Value Proposition", 182 draft-klyus-supa-proposition-02 (work in progress), July 183 2015. 185 [I-D.xia-sdnrg-nemo-language] 186 Xia, Y., Jiang, S., Zhou, T., and S. Hares, "NEMO (NEtwork 187 MOdeling) Language", draft-xia-sdnrg-nemo-language-03 188 (work in progress), October 2015. 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, 192 DOI 10.17487/RFC2119, March 1997, 193 . 195 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 196 DOI 10.17487/RFC2629, June 1999, 197 . 199 Authors' Addresses 201 Tianran Zhou 202 Huawei Technologies Co., Ltd 203 Q14, Huawei Campus, No.156 Beiqing Road 204 Hai-Dian District, Beijing, 100095 205 P.R. China 207 Email: zhoutianran@huawei.com 209 Bert Wijnen (editor) 210 Consultant 211 Schagen 33 212 3461 GL Linschoten 213 The Netherlands 215 Email: bertietf@bwijnen.net