idnits 2.17.1 draft-zheng-netconf-fragmentation-01.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 21 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 (June 20, 2018) is 2134 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netconf G. Zheng 3 Internet-Draft M. Wang 4 Intended status: Informational Huawei 5 Expires: December 22, 2018 June 20, 2018 7 A NETCONF Extension for Data Fragmentation 8 draft-zheng-netconf-fragmentation-01 10 Abstract 12 This document introduces an extension to NETCONF (Network 13 Configuration) protocol. The extension allows NETCONF to handle 14 large size data as fragmented RPC messages. Specifically, this 15 document defines a new capability and relevant operations 16 to handle the fragmentations. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 22, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 3 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Current Large size Handling Methods and Problems . . . . . . 3 56 3.1. Stream-Oriented Handling . . . . . . . . . . . . . . . . 3 57 3.2. Requesting a Portion of Data . . . . . . . . . . . . . . 4 58 3.3. Using tools to extract data respectively . . . . . . . . 4 59 4. Netconf Fragmentation Mechanism . . . . . . . . . . . . . . . 5 60 4.1. Fragmentation Requirements . . . . . . . . . . . . . . . 5 61 4.2. extention . . . . . . . . . . . . . . . . . . 5 62 5. YANG data model . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 66 Appendix A. Appendix A: Examples of the Candidate Solutions . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 NETCONF [RFC6241] is the next generation network management protocol 72 for configuring devices. It is becoming more and more popular, and 73 some NMS (Network Management System) only use NETCONF as its 74 southbound interface. The message procedures of NETCONF are based on 75 RPC (Remote Procedure Call) interactions. A NETCONF client/server 76 sends a message to the counterpart and then receives a replying 77 message. 79 In some situations, the message might be very large. For 80 example, when NMS is retrieving a large amount of routes in a core 81 router or doing a full-synchronizing with a device, the 82 data might exceed Mega-Byte amount. And also in some scenarios, the 83 client may retrieve a continuous stream of operational data from the 84 operational datastore [I-D.ietf-netmod-revised-datastores] to perform 85 network analytics. Then there comes the problem of how to handle the 86 large size data. This document briefly introduces two typical ways 87 of current handling on this issue; and analyzes the problems of them. 89 To fix the problems, in Section 4, this document proposes a method of 90 extending the NETCONF protocol to allow handling large size data as 91 fragmented messages. The fragmentation is done at the 92 NETCONF level, so it allows the NETCONF client to terminate the large 93 size data processing momentarily by protocol interactions; and also 94 allows the fragmented messages to be instantly parsed piece by piece. 95 Specifically, the fragmentation is achieved through a newly defined 96 capability and relevant operations. 98 2. Concept and Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2.1. Terminology 106 DOM: Document Object Model, which is a cross-platform and language- 107 independent convention for representing and interacting with objects 108 in HTML, XHTML and XML documents. Objects in the DOM tree may be 109 addressed and manipulated by using methods on the objects. 111 SAX: Simple API for XML, which is an event sequential access parser 112 API developed by the XML-DEV mailing list for XML documents. SAX 113 provides a mechanism for reading data from an XML document that is an 114 alternative to that provided by the DOM. Where the DOM operates on 115 the document as a whole, SAX parsers operate on each piece of the XML 116 document sequentially. 118 libxml: a software library for parsing XML documents. 120 : a capability and operation defined in this document to 121 handle large size 123 3. Current Large size Handling Methods and Problems 125 3.1. Stream-Oriented Handling 127 Stream-Oriented handling mainly includes the following two aspects: 129 o The server encapsulates the large size replying data in a message and streams it to the client through TCP protocol. 132 o The client parses the received content in a stream- 133 oriented way. More specifically, the client could utilize SAX to 134 instantly parse the received content without waiting for the whole 135 message been transported. 137 Problems: 139 o Stream-Oriented method lacks the capability of discontinuing 140 large size processing in the server. It would cause unnecessary 141 resource/performance cost in the devices if the NMS has already 142 got the intended portion or just canceled by the administrators. 144 o Another problem is the implementation of SAX parsing is more 145 complex than DOM parsing in the Netconf client. More computing 146 burden will be taken in Netconf client to support SAX parsing. 148 3.2. Requesting a Portion of Data 150 The clients actively limit the search range of the data so that the 151 servers only need to reply with a part of the large size data. Thus 152 the clients could control the replies in a reasonable size. One 153 example is that the clients get a list of the content, and provide a 154 start offset and a max-count, to get a portion at a time. 156 Problems: 158 o This method has an implication that the client needs to know the 159 list/index of the intended large size data in advance before it 160 starting the search request. It can't fit the scenarios of real- 161 time on-demand data retrieving. And there is no standard to 162 specify the list/index format in a uniform way. Thus it is only 163 suitable for private implementation, thus multi-vendor interaction 164 is not supported. 166 o More important, it is just an indirect way to solve the problem. 167 It could not fit the scenarios where the client just needs the 168 whole large size data in the server. 170 3.3. Using tools to extract data respectively 172 In this way, it mainly includes the following two steps: 174 o The client can request the complete data via some RPCs, i.e. 175 , , , etc. 177 o The user step-by-step read the received data via corresponding 178 tools, for example, for XML data, the XPATH's position() function 179 can help to do this work. 181 Problems: 183 o The client still request the complete large seize data, and it 184 may incur significant latency. In the extreme situation, the 185 may be discarded. 187 o Different encoding format request different tools, and there is 188 no standard to process the received data in a uniform way. Thus 189 it is only suitable for private implementation, thus multi-vendor 190 interaction is not supported. 192 4. Netconf Fragmentation Mechanism 194 4.1. Fragmentation Requirements 196 this document proposes an RPC fragmentation mechanism to handle the 197 large size data. Two essential requirements of the fragmentation 198 are: 200 o It needs to allow the NETCONF client to terminate the large size 201 data processing momentarily by protocol interactions. In the 202 proposed mechanisms in this draft, when the NETCONF server replies 203 the client an fragmentation, it will wait the response 204 from the client that whether it needs to send the next 205 fragmentation. So if the initiator has got the intended portion, 206 it could terminate the large size process immediately. 208 o It needs to allow the NETCONF client to instantly parse the 209 fragmentations piece by piece through the more widely supported 210 DOM parsing. So in this document, it specifies that each fragmentation MUST be in a complete XML form. 213 4.2. extention 215 o Function 217 The devices can only use operation when the Get-block 218 capability was announced. 220 The fragmentation rules are: 222 A. There should be a Max-Size for fragmentation. [Ope 223 Question]Should there be a clear specification of the size? E.g. 224 64K bytes. 226 B. When the message reaches the Max-Size, it is sent to the 227 client and the next message could be created in advance. 229 C. Different records from one same table could be put into 230 different messages 232 D. All of the fields in one record MUST be put into one message. 235 E. XML syntax MUST be complete in each fragmented message, so 236 that each fragmentation could be parsed individually. 238 F. If the record(s) of the child node(s)/table(s) and the parent 239 node(s)/table(s) are replied in different fragmentations, the 240 child node/table fragmentations MUST include the path and index 241 information of all the ancestor node(s)/table(s) in a hierarchical 242 mode. 244 o Parameters 246 : in operation, if the parameter is conveyed, it means the operation is 248 terminated. Then it doesn't need to reply the remaining 249 fragmentations. 251 o Successful Operation Reply 253 A message conveying a element indicates the 254 operation is successful. If there exists a next fragment, then an 255 set-id attribute MUST be included in the messge. The 256 attribute set-id is used to identify different fragment sets. 258 o Exception Handling 260 After the NETCONF server replies a fragment, if there is no 261 corresponding Get-block request from the client in a reasonable 262 period (the time valued to be specified in the future), then the 263 server release the offset of the replying data and cannot use operation anymore, and the remaining data needs to be replied. 266 Please refer to Appendix A.1 for an example. 268 5. YANG data model 270 file "ietf-netconf-fragmentation@2018-06-20.yang" 271 module ietf-netconf-fragmentation { 272 yang-version 1.1; 273 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-fragmentation"; 274 prefix fgm; 276 import ietf-datastores{ 277 prefix ds; 278 } 280 import ietf-yang-types { 281 prefix yang; 282 } 284 import ietf-netconf { 285 prefix nc; 286 } 287 organization 288 "IETF NETCONF Working Group"; 289 contact 290 "WG Web: 292 WG List: 294 Author: Guangying Zheng 295 297 Author: Zitao Wang 298 "; 299 description 300 "This document introduces an extension to NETCONF (Network Configuration) protocol. 301 The extension allows NETCONF to handle large size data as fragmented RPC messages. 302 Specifically, this document defines a new get-block capability and relevant 303 operations to handle the fragmentations."; 305 revision 2018-06-20 { 306 description 307 "Initial revision."; 308 reference "draft-zheng-netconf-fragmentation-01"; 309 } 311 rpc get-block { 312 description 313 "Retrieve data from an NMDA datastore."; 314 input { 315 leaf source { 316 type identityref { 317 base ds:datastore; 318 } 319 mandatory true; 320 description 321 "Datastore from which to retrieve data."; 322 } 324 choice filter-spec { 325 description 326 "The content filter specification for this request."; 328 anydata subtree-filter { 329 description 330 "This parameter identifies the portions of the 331 target datastore to retrieve."; 332 reference "RFC 6241, Section 6."; 333 } 334 leaf xpath-filter { 335 if-feature nc:xpath; 336 type yang:xpath1.0; 337 description 338 "This parameter contains an XPath expression 339 identifying the portions of the target 340 datastore to retrieve."; 341 } 342 } 343 } 344 } 345 rpc discard-fragmentation { 346 description 347 "Discard the netconf fragmentation, if the discard parameter is conveyed, 348 it means the operation is terminated. 349 Then it doesn't need to reply the remaining fragmentations."; 350 } 352 } 353 355 6. Security Considerations 357 TBD. 359 7. IANA Considerations 361 TBD. 363 8. Normative References 365 [I-D.ietf-netmod-revised-datastores] 366 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 367 and R. Wilton, "Network Management Datastore 368 Architecture", draft-ietf-netmod-revised-datastores-10 369 (work in progress), January 2018. 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, 373 DOI 10.17487/RFC2119, March 1997, 374 . 376 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 377 and A. Bierman, Ed., "Network Configuration Protocol 378 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 379 . 381 Appendix A. Appendix A: Examples of the Candidate Solutions 383 A.1. (RPC Fragmentation) Example: 385 Example 1: Get the next fragment 387 389 390 391 392 393 394 395 396 397 398 399 401 405 406 407 408 409 root 410 superuser 411 Charlie Root 412 413 1 414 1 415 416 417 418 419 420 421 423 425 427 428 429 433 434 435 436 437 admin 438 commonuser 439 Jim Green 440 441 9 442 90 443 444 445 446 447 448 449 451 Example 2: Abandon the remaining fragments 453 455 456 457 458 460 462 463 465 Authors' Addresses 467 Guangying Zheng 468 Huawei 469 101 Software Avenue, Yuhua District 470 Nanjing, Jiangsu 210012 471 China 473 Email: zhengguangying@huawei.com 474 Michael Wang 475 Huawei 476 101 Software Avenue, Yuhua District 477 Nanjing, Jiangsu 210012 478 China 480 Email: wangzitao@huawei.com