idnits 2.17.00 (12 Aug 2021) /tmp/idnits8194/draft-zheng-netmod-integrate-operations-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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 128 has weird spacing: '...RP data then ...' -- The document date (July 2, 2014) is 2880 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: 'RFC6020' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 381, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Zheng 2 Internet Draft X. Ji 3 Intended status: Standard Track Huawei Technologies 4 Expires: January 3, 2015 July 2, 2014 6 Integrating Operations in YANG Models 7 draft-zheng-netmod-integrate-operations-00.txt 9 Abstract 11 This document introduces an extension to YANG. The extension allows 12 operation methods to be directly integrated in YANG models. 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute working 21 documents as Internet-Drafts. The list of current Internet-Drafts is 22 at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on January 3, 2015. 31 Copyright Notice 33 Copyright (c) 2011 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction .................................................. 3 49 2. Requirements Language and Terminology ......................... 3 50 3. Scenarios and Requirements of Operation Extension in Data Models3 51 3.1. Scenarios of Complex Operations .......................... 3 52 3.2. Scenario of Operation Authorization ...................... 6 53 3.3. The Requirements for Operation Extension in Data Models .. 6 54 4. Solution for Operation Extension in Data Models ............... 6 55 4.1. General Idea ............................................. 6 56 4.2. Usage Example ............................................ 7 57 5. Security Considerations ....................................... 9 58 6. IANA Considerations ........................................... 9 59 7. References .................................................... 9 60 7.1. Normative References ..................................... 9 61 7.2. Informative References .................................. 10 62 8. Acknowledgments .............................................. 10 63 Authors' Addresses .............................................. 11 65 1. Introduction 67 YANG is a data modeling language used to model data manipulated by 68 the NETCONF Protocol. YANG provides the capability to describe 69 configuration/state data in a tree structure; and it has been proven 70 that YANG is an efficient language to model data for network 71 configuration. 73 However, along with management requirements of modern NMS becoming 74 more and more sophisticate, the capability of only describing the 75 data structure in the model seems to be insufficient in some 76 scenarios. In a nutshell, these scenarios require some operations to 77 be integrated in the model as well. 79 This document firstly describes the scenarios and then introduces a 80 YANG model extension which allows operation method to be directly 81 integrated in YANG models. 83 2. Requirements Language and Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in 88 [RFC2119] when they appear in ALL CAPS. When these words are not in 89 ALL CAPS (such as "should" or "Should"), they have their usual 90 English meanings, and are not to be interpreted as [RFC2119] key 91 words. 93 Terminology: 95 3. Scenarios and Requirements of Operation Extension in Data Models 97 In some datastore operation scenarios, the operations triggered from the 98 NETCONF client might be a set of combined operations or a complex single 99 operation within the NETCONF agent, which may change the datastores. And 100 sometimes the datastore change might not be from client but from the agent 101 itself. These operations need to manipulate the data in running datastore 102 or candidate datastore, and thus they need the capability a 103 well as a unified authorization system to control the influence to the data 104 stores caused by them. 106 3.1. Scenarios of Complex Operations 108 The complex operations on data model such as batch creating or 109 converting dynamic data to configuration data, are targeting the 110 running datastore or candidate datastore. Thus, the target datastore, 111 error-option, confirmed-commit, validation and other attributes of 112 operation need to be specified. The following are some 113 examples. 115 o Scenario 1: converting the device's dynamic ARP to static ARP 117 The ARP data model contains static configuration attributes and 118 dynamic non-configuration attributes; both of them are needed by ARP 119 service. The difference between these two groups of attributes is 120 that the static ARP is configured by the client while the dynamic ARP 121 is learn from network peers. To accelerate the speed of dynamic ARP 122 learning after rebooting device, or to simplify the configuration of 123 the static ARP, the dynamic ARP entries need to be converted to 124 static ARP entries when the network is stable. 126 Current solution 1: 128 The client gets the dynamic ARP data then uses these data as 129 static ARP configuration and add them to the NETCONF agent by 130 using operation. 132 Problems of solution 1: 134 - There are too many data communications between client and 135 server, thus the performance is low. 136 - The configured ARP by dynamic ARP from client is duplicated 137 with the dynamic ARP in the device, thus the device has to 138 process the duplication. 140 Current solution 2: 142 According to [RFC6020]/[RFC6241] RPC definition, define a new 143 non-standard RPC to convert dynamic ARP to static ARP directly. 145 Problems of solution 2: 147 The new RPC cannot use the existing attributes of 148 operation, such as target datastore, error-option, confirmed 149 commit and validate. The NETCONF agent has to implement these 150 operation attributes itself, which makes the agent 151 more complex. 153 o Scenario 2: batch operations on data model 154 In some situations, batch merge operations on the list of one module 155 might be needed to reduce the communication data size. 157 Current solutions: 159 1) Use with filter to get the data from the device, 160 and then add all merge operations to and send it to 161 the device. 163 2) According to [RFC6020]/[RFC6241] RPC definition, define a non- 164 standard RPC to do the batch merge operation. 166 Problems of current solutions 168 1) Solution 1 impacts the operation efficiency between host and 169 device significantly. 171 2) Solution 2 has the same issues with Use Case 1's solution 2. 173 o Scenario 3: maintaining operations on data models 175 The data model of one module is usually hierarchical. Sometimes it 176 needs maintaining operations on the sub nodes, such as resting the 177 running services. 179 Current solution: 181 According to [RFC6020]/[RFC6241] RPC definition, define a non- 182 standard RPC to do maintaining operations. 184 Problems of current solution: 186 1) When defining the RPC operation, all the key attributes of 187 parents path should appear in the input parameter of the RPC, 188 otherwise the instance of the sub node could not be located. The 189 additional key parameters make the input parameter definition 190 redundant. 192 2) The scope of sub nodes that the new defined RPC would impact 193 is not clear, thus users have to refer other documents to do 194 authorization rather than just referring the RPC definition 195 itself. 197 3.2. Scenario of Operation Authorization 199 The user-defined non-standard RPC operations might impact the 200 datastores, which need additional authorization. 202 Current solution: 204 When the user-defined RPC operation impact the datastores (either 205 directly manipulate the datastores or impact the datastores as a 206 side effect of the protocol operation), then the server MUST 207 intercept the access operation and make sure the user is 208 authorized to perform the requested access operation on the 209 targeted data as defined in [RFC6536] Section 3.4.5. 211 Problems of Current Solution: 213 1) Because the scope of datastores that the RPC operation would 214 impact is not defined exactly, there is a risk that invocation of 215 non-standard protocol operations might have undocumented side 216 effects ([RFC6536] Section 3.7.2). 218 2) An administrator needs to set access control rules to make the 219 configuration datastore protected from user-defined non-standard 220 protocol operation's side effects. But, the rules definition has 221 to depend on the relevant documents not directly on model 222 definition, thus it is not the same as the data node access 223 control rule definition, which makes the authorization management 224 more complex. 226 3.3. The Requirements for Operation Extension in Data Models 228 The user-defined non-standard operation should overload the standard 229 operations of , , and so on, so that 230 the new operation could inherit the capabilities of the base standard 231 operations. 233 The user-defined non-standard operations should be able to clearly 234 define the scope of the datastores that the operations are allowed to 235 impact in terms of build-in RPC semantics rather than outside 236 documents. 238 4. Solution for Operation Extension in Data Models 240 4.1. General Idea 242 1) The operations to data nodes should be defined on the data model 243 hierarchy tree as a part of the data model attributes; the data 244 node's sub-statement of the operations should also be defined as 245 well.. 247 2) The operations that will effect or side effect datastores should 248 be specified which base standard RPC operations are inherited. 250 3) When the data model operations are delivered by NETONCF, they MUST 251 be in the format of the base protocol RPC operations; and the 252 operations definition should be presented as a "Method" attribute of 253 data node; the base protocol RPC operation capabilities should be 254 inherited. 256 4) The operation access control rules should depend on the impact to 257 data models by the operations defined in the model. 259 4.2. Usage Example 261 This example is based on the ARP conversion scenario described in 262 Section 3.1. 264 Operation is defined as a "method" substatement in the YANG model: 266 module arp { 268 namespace "http://example.com/network"; 270 prefix "arp"; 272 container arp-records { 274 list arpList { 276 leaf ipAddr { 278 type string 280 } 282 leaf macAddr { 284 type string 286 } 288 leaf styleType { 290 type string; 292 } 294 method convert-arp { 296 base edit-config 298 description "A method to convert dynamic arp to static 299 arp"; 301 input { 303 leaf source-arptype { 305 type string; 307 } 309 leaf dest-arptype { 311 type string; 313 } 315 } 317 } 319 } 321 } 323 Corresponding NETCONF operation is as the following: 325 331 333 335 337 338 340 342 344 dynamic 346 dynamic 348 350 352 354 356 358 5. Security Considerations 360 TBD 362 6. IANA Considerations 364 This document requires no IANA registration. 366 7. References 368 7.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 374 Network Configuration Protocol (NETCONF)", RFC 6020, 375 October 2010. 377 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, 378 "Network Configuration Protocol (NETCONF)", RFC 6241, June 379 2011. 381 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, 382 July 2013. 384 7.2. Informative References 386 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 387 Protocol (NETCONF) Access Control Model", RFC 6536, March 388 2012. 390 8. Acknowledgments 392 Many valuable comments were received from Gang Yan to improve the 393 draft. Bing Liu also participated in forming this draft. 395 This document was prepared using 2-Word-v2.0.template.dot. 397 Authors' Addresses 399 Guangying Zheng 400 Huawei Nanjing R&D Center 401 Huawei Technologies Co., Ltd 402 101 Software Avenue, Yuhua District, Nanjing, Jiangsu 403 P.R.China. 210012 405 Email: zhengguangying@huawei.com 407 Xiaofeng Ji 408 Q14-4-B Building 409 Huawei Technologies Co., Ltd 410 Zhong-Guan-Cun Environmental Protection Park, No.156 Beiqing Rd. 411 Hai-Dian District, Beijing 412 P.R. China. 100095 414 Email: jixiaofeng@huawei.com