idnits 2.17.1 draft-zheng-netconf-inline-action-capability-02.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 2 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 -- The document date (November 4, 2018) is 1999 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) == Missing Reference: 'RFC8174' is mentioned on line 99, but not defined -- Looks like a reference, but probably isn't: '1' on line 298 -- Looks like a reference, but probably isn't: '10' on line 298 == Unused Reference: 'I-D.ietf-netconf-nmda-netconf' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC6021' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC6242' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC6470' is defined on line 430, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group W. Zheng 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: May 8, 2019 November 4, 2018 7 Inline Action Capability for NETCONF 8 draft-zheng-netconf-inline-action-capability-02 10 Abstract 12 NETCONF provides mechanism to install configuration of network 13 devices. In many cases, it is required that the same configuration 14 repeats on many interfaces. In the absence of protocol semantics for 15 performing operations with group-specific scope, this results in 16 either a significant amount of signaling traffic and configuration 17 template applying on a periodic basis or large packet size between a 18 given network management system and a network devices. This document 19 defines optimizations to the NETCONF protocol operations for 20 performing operations with group-specific scope with the use of a 21 group identifier. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 8, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Inline-Action Capability . . . . . . . . . . . . . . . . . . 3 60 2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 3 63 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . 3 64 2.5. Modifications to Existing Operations . . . . . . . . . . 3 65 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. NETCONF Capability URN . . . . . . . . . . . . . . . . . 9 68 5. Normative References . . . . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 NETCONF provides mechanism to install configuration of network 74 devices. In many cases, it is required that the same configuration 75 repeats on many interfaces, e.g., configure multiple VLAN ranges on 76 the same Trunk interface. In the absence of protocol semantics for 77 performing operations with group-specific scope, using configuration 78 template to replicate multiple copies on the same interface result in 79 either a significant amount of signaling traffic(e.g, multiple data 80 retrieval for vlan tag configuration on the interface) on a periodic 81 basis or large packet size (e.g,edit-config operation related to 82 protocol message) between a given network management system and a 83 network devices. 85 This document defines optimizations to the NETCONF protocol 86 operation(i.e., inline action operation) for performing bulk 87 operations with group-specific scope with the use of a group 88 identifier and allows NETCONF protocol operation work together with 89 inline action operation that apply to different conceptual node in 90 the underlying data model in one transaction. 92 1.1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 2. Inline-Action Capability 102 2.1. Description 104 The :inline-action capability indicates that the device supports 105 Inline-action operation within protocol operation on specific 106 datastore. In other words, the device supports 107 operation which is included in existing protocol operations. 109 2.2. Dependencies 111 None. 113 2.3. Capability Identifier 115 The :inline-action capability is identified by the following 116 capability string: 118 urn:ietf:params:netconf:capability:inline-action:1.1 120 2.4. New Operations 122 None. 124 2.5. Modifications to Existing Operations 126 The :inline-action:1.1 capability modifies the protocol operation to 127 accept attribute value within operation attribute. 129 As described in [RFC6241], "operation" attribute is defined in a 130 element within subtree and identify the point in the 131 configuration to perform the operation and MAY appear on multiple 132 elements throughout the subtree. In this document, two new 133 "operation" attribute values are added as follows: 135 record-split: The range constrait of the configuration data 136 identified by the element containing this attribute is split at 137 the corresponding level in the configuration datastore identified 138 by the parameter. 140 record-merge: The range constrait of the configuration data 141 identified by the element containing this attribute is merged at 142 the corresponding level in the configuration datastore identified 143 by the parameter. 145 In addition, the record-merge and record-split operation attributes 146 and other "operation" attributes MUST apply to the different 147 conceptual nodes In the underlying data model. 149 As described in [RFC6241], the config subtree is expressed as a 150 hierarchy of configuration data as defined by one of the device's 151 data models. The contents MUST follow the constraints of that data 152 model, as defined by its capability definition. If inline action 153 capability is supported, the config subtree may contain a schema node 154 with the name "input" and a schema node with the name "output" 155 connected to a specific container or list data node containing 156 recrod-merge element in a datastore. 158 Excample: 159 container interfaces { 160 list trunk-interface { 161 key "name"; 162 config true; 163 leaf name { 164 type string; 165 } 166 container vlan-id-ranges{ 167 list vlan-id-range{ 168 key "group-id"; 169 leaf group-id { 170 type string; 171 description 172 "Specified VLAN group ID."; 173 } 174 leaf lower-vlan-id { 175 type uint32 { 176 range "1..4094"; 177 } 178 mandatory true; 179 description 180 "Start outer VLAN ID."; 181 } 182 leaf upper-vlan-id { 183 type uint16 { 184 range "1..4094"; 185 } 186 description 187 "End outer VLAN ID."; 188 } 189 action range-merge { 190 input { 191 leaf lower-vlan-id { 192 type uint32 { 193 range "1..4094"; 194 } 195 mandatory true; 196 description 197 "Start outer VLAN ID."; 198 } 199 leaf upper-vlan-id { 200 type uint16 { 201 range "1..4094"; 202 } 203 description 204 "End outer VLAN ID."; 205 } 206 } 207 } 208 } 209 } 210 } 211 } 213 Suppose we configure trunk interface with multiple discrete vlan tag 214 ranges from the running configuration and without inline action 215 capability, edit-config with configuration template will be used to 216 merge them as one record with extra computation in the client app. 218 220 221 222 223 224 none 225 226 227 228 229 Ethernet0/0 230 231 232 0 233 1 234 3 235 236 237 2 238 5 239 6 240 241 242 3 243 7 244 8 245 246 247 4 248 9 249 10 250 251 252 0 253 1 254 10 255 256 257 258 259 260 261 262 263 If inline-action capability supported, bulk operation in one protocol 264 message will be used to merge multiple records with different vlan 265 tag range will into one record: 267 269 270 271 272 273 none 274 275 276 277 278 Ethernet0/0 279 280 281 282 283 284 1 285 10 286 287 288 289 290 291 292 293 294 295 296 298 Suppose we have a trunk interface with vlan tag range [1,10], we 299 delete one vlan tag from this trunk interface,without inline action 300 capability, edit-config with configuration template will be used to 301 split valn tag range into multiple records with extra computation in 302 the client app. 304 306 307 308 309 310 none 311 312 313 314 315 Ethernet0/0 316 317 318 0 319 4 320 4 321 322 323 0 324 1 325 3 326 327 328 1 329 4 330 10 331 332 333 334 335 336 337 338 340 If inline-action capability supported, bulk operation in one protocol 341 message will be used to split one record with vlan tag range into two 342 records: 344 346 347 348 349 350 none 351 352 353 354 355 Ethernet0/0 356 357 358 1 359 10 360 361 362 363 4 364 4 365 366 367 368 369 370 371 372 373 374 375 377 3. Security Considerations 379 This document does not introduce any security vulnerability besides 380 on defined in [RFC6241]. 382 4. IANA Considerations 384 4.1. NETCONF Capability URN 386 IANA has created and now maintains a registry "Network Configuration 387 Protocol (NETCONF) Capability URNs" that allocates NETCONF capability 388 identifiers. Additions to the registry require IETF Standards 389 Action. 391 IANA has added the following capabilities to the registry: 393 Index 394 Capability Identifier 395 ------------------------ 396 :inline-action:1.1 397 urn:ietf:params:netconf:capability:inline-action:1.1 399 5. Normative References 401 [I-D.ietf-netconf-nmda-netconf] 402 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 403 and R. Wilton, "NETCONF Extensions to Support the Network 404 Management Datastore Architecture", draft-ietf-netconf- 405 nmda-netconf-08 (work in progress), October 2018. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, 409 DOI 10.17487/RFC2119, March 1997, 410 . 412 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 413 the Network Configuration Protocol (NETCONF)", RFC 6020, 414 DOI 10.17487/RFC6020, October 2010, 415 . 417 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 418 RFC 6021, DOI 10.17487/RFC6021, October 2010, 419 . 421 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 422 and A. Bierman, Ed., "Network Configuration Protocol 423 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 424 . 426 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 427 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 428 . 430 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 431 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 432 February 2012, . 434 Authors' Addresses 435 Walker Zheng 436 Huawei 437 101 Software Avenue, Yuhua District 438 Nanjing, Jiangsu 210012 439 China 441 Email: zhengguangying@huawei.com 443 Qin Wu 444 Huawei 445 101 Software Avenue, Yuhua District 446 Nanjing, Jiangsu 210012 447 China 449 Email: bill.wu@huawei.com