idnits 2.17.1 draft-zheng-netconf-fragmentation-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 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 (October 30, 2017) is 2363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netconf Guangying. Zheng 3 Internet-Draft Michael. Wang 4 Intended status: Informational Huawei 5 Expires: May 3, 2018 October 30, 2017 7 A NETCONF Extension for Data Fragmentation 8 draft-zheng-netconf-fragmentation-00 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 May 3, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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 4. Requesting a Portion of Data . . . . . . . . . . . . . . . . 4 58 5. Netconf Fragmentation Mechanism . . . . . . . . . . . . . . . 4 59 5.1. Fragmentation Requirements . . . . . . . . . . . . . . . 4 60 5.2. extention . . . . . . . . . . . . . . . . . . 5 61 6. YANG data model . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 Appendix A. Appendix A: Examples of the Candidate Solutions . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 NETCONF [RFC6241] is the next generation network management protocol 71 for configuring devices. It is becoming more and more popular, and 72 some NMS (Network Management System) only use NETCONF as its 73 southbound interface. The message procedures of NETCONF are based on 74 RPC (Remote Procedure Call) interactions. A NETCONF client/server 75 sends a message to the counterpart and then receives a replying 76 message. 78 In some situations, the message might be very large. For 79 example, when NMS is retrieving a large amount of routes in a core 80 router or doing a full-synchronizing with a device, the 81 data might exceed Mega-Byte amount. And also in some scenarios, the 82 client may retrieve a continuous stream of operational data from the 83 operational datastore [I-D.ietf-netmod-revised-datastores] to perform 84 network analytics. Then there comes the problem of how to handle the 85 large size data. This document briefly introduces two typical ways 86 of current handling on this issue; and analyzes the problems of them. 88 To fix the problems, in Section 4, this document proposes a method of 89 extending the NETCONF protocol to allow handling large size data as 90 fragmented messages. The fragmentation is done at the 91 NETCONF level, so it allows the NETCONF client to terminate the large 92 size data processing momentarily by protocol interactions; and also 93 allows the fragmented messages to be instantly parsed piece by piece. 94 Specifically, the fragmentation is achieved through a newly defined 95 capability and relevant operations. 97 2. Concept and Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2.1. Terminology 105 DOM: Document Object Model, which is a cross-platform and language- 106 independent convention for representing and interacting with objects 107 in HTML, XHTML and XML documents. Objects in the DOM tree may be 108 addressed and manipulated by using methods on the objects. 110 SAX: Simple API for XML, which is an event sequential access parser 111 API developed by the XML-DEV mailing list for XML documents. SAX 112 provides a mechanism for reading data from an XML document that is an 113 alternative to that provided by the DOM. Where the DOM operates on 114 the document as a whole, SAX parsers operate on each piece of the XML 115 document sequentially. 117 libxml: a software library for parsing XML documents. 119 : a capability and operation defined in this document to 120 handle large size 122 3. Current Large size Handling Methods and Problems 124 3.1. Stream-Oriented Handling 126 Stream-Oriented handling mainly includes the following two aspects: 128 o The server encapsulates the large size replying data in a message and streams it to the client through TCP protocol. 131 o The client parses the received content in a stream- 132 oriented way. More specifically, the client could utilize SAX to 133 instantly parse the received content without waiting for the whole 134 message been transported. 136 Problems: 138 o Stream-Oriented method lacks the capability of discontinuing 139 large size processing in the server. It would cause unnecessary 140 resource/performance cost in the devices if the NMS has already 141 got the intended portion or just canceled by the administrators. 143 o Another problem is the implementation of SAX parsing is more 144 complex than DOM parsing in the Netconf client. More computing 145 burden will be taken in Netconf client to support SAX parsing. 147 4. Requesting a Portion of Data 149 The clients actively limit the search range of the data so that the 150 servers only need to reply with a part of the large size data. Thus 151 the clients could control the replies in a reasonable size. One 152 example is that the clients get a list of the content, and provide a 153 start offset and a max-count, to get a portion at a time. 155 Problems: 157 o This method has an implication that the client needs to know the 158 list/index of the intended large size data in advance before it 159 starting the search request. It can't fit the scenarios of real- 160 time on-demand data retrieving. And there is no standard to 161 specify the list/index format in a uniform way. Thus it is only 162 suitable for private implementation, thus multi-vendor interaction 163 is not supported. 165 o More important, it is just an indirect way to solve the problem. 166 It could not fit the scenarios where the client just needs the 167 whole large size data in the server. 169 5. Netconf Fragmentation Mechanism 171 5.1. Fragmentation Requirements 173 this document proposes an RPC fragmentation mechanism to handle the 174 large size data. Two essential requirements of the fragmentation 175 are: 177 o It needs to allow the NETCONF client to terminate the large size 178 data processing momentarily by protocol interactions. In the 179 proposed mechanisms in this draft, when the NETCONF server replies 180 the client an fragmentation, it will wait the response 181 from the client that whether it needs to send the next 182 fragmentation. So if the initiator has got the intended portion, 183 it could terminate the large size process immediately. 185 o It needs to allow the NETCONF client to instantly parse the 186 fragmentations piece by piece through the more widely supported 187 DOM parsing. So in this document, it specifies that each fragmentation MUST be in a complete XML form. 190 5.2. extention 192 The CU Separation protocol SHOULD be able to supporting at least 193 hundreds of UP devices and tens of thousands of ports. For example, 194 the protocol field sizes corresponding to UP or port numbers SHALL be 195 large enough to support the minimum required numbers. This 196 requirement does not relate to the performance of the system as the 197 number of UPs or ports in the system grows. 199 o Function 201 The devices can only use operation when the Get-block 202 capability was announced. 204 The fragmentation rules are: 206 A. There should be a Max-Size for fragmentation. [Ope 207 Question]Should there be a clear specification of the size? E.g. 208 64K bytes. 210 B. When the message reaches the Max-Size, it is sent to the 211 client and the next message could be created in advance. 213 C. Different records from one same table could be put into 214 different messages 216 D. All of the fields in one record MUST be put into one message. 219 E. XML syntax MUST be complete in each fragmented message, so 220 that each fragmentation could be parsed individually. 222 F. If the record(s) of the child node(s)/table(s) and the parent 223 node(s)/table(s) are replied in different fragmentations, the 224 child node/table fragmentations MUST include the path and index 225 information of all the ancestor node(s)/table(s) in a hierarchical 226 mode. 228 o Parameters 230 : in operation, if the parameter is conveyed, it means the operation is 232 terminated. Then it doesn't need to reply the remaining 233 fragmentations. 235 o Successful Operation Reply 236 A message conveying a element indicates the 237 operation is successful. If there exists a next fragment, then an 238 set-id attribute MUST be included in the messge. The 239 attribute set-id is used to identify different fragment sets. 241 o Exception Handling 243 After the NETCONF server replies a fragment, if there is no 244 corresponding Get-block request from the client in a reasonable 245 period (the time valued to be specified in the future), then the 246 server release the offset of the replying data and cannot use operation anymore, and the remaining data needs to be replied. 249 Please refer to Appendix A.1 for an example. 251 6. YANG data model 253 file "ietf-netconf-fragmentation@2017-10-23.yang" 254 module ietf-netconf-fragmentation { 255 yang-version 1.1; 256 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-fragmentation"; 257 prefix fgm; 259 import ietf-netconf-datastores{ 260 prefix ncds; 261 } 263 import ietf-yang-types { 264 prefix yang; 265 } 267 import ietf-netconf { 268 prefix nc; 269 } 271 organization 272 "IETF NETCONF Working Group"; 273 contact 274 "WG Web: 276 WG List: 278 Author: Guangying Zheng 279 281 Author: Zitao Wang 282 "; 283 description 284 "This document introduces an extension to NETCONF (Network Configuration) protocol. 285 The extension allows NETCONF to handle large size data as fragmented RPC messages. 286 Specifically, this document defines a new get-block capability and relevant 287 operations to handle the fragmentations."; 289 revision 2017-10-23 { 290 description 291 "Initial revision."; 292 reference "draft-zheng-netconf-fragmentation-00"; 293 } 295 rpc get-block { 296 description 297 "Retrieve data from an NMDA datastore."; 298 input { 299 leaf source { 300 type ncds:datastore; 301 mandatory true; 302 description 303 "Datastore from which to retrieve data."; 304 } 306 choice filter-spec { 307 description 308 "The content filter specification for this request."; 310 anydata subtree-filter { 311 description 312 "This parameter identifies the portions of the 313 target datastore to retrieve."; 314 reference "RFC 6241, Section 6."; 315 } 316 leaf xpath-filter { 317 if-feature nc:xpath; 318 type yang:xpath1.0; 319 description 320 "This parameter contains an XPath expression 321 identifying the portions of the target 322 datastore to retrieve."; 323 } 324 } 325 } 326 } 327 rpc discard-fragmentation { 328 description 329 "Discard the netconf fragmentation, if the discard parameter is conveyed, 330 it means the operation is terminated. 332 Then it doesn't need to reply the remaining fragmentations."; 333 } 335 } 336 338 7. Security Considerations 340 TBD. 342 8. IANA Considerations 344 TBD. 346 9. Normative References 348 [I-D.ietf-netmod-revised-datastores] 349 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 350 and R. Wilton, "Network Management Datastore 351 Architecture", draft-ietf-netmod-revised-datastores-05 352 (work in progress), October 2017. 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 360 and A. Bierman, Ed., "Network Configuration Protocol 361 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 362 . 364 Appendix A. Appendix A: Examples of the Candidate Solutions 366 A.1. (RPC Fragmentation) Example: 368 Example 1: Get the next fragment 370 372 373 374 375 376 377 378 379 381 382 383 385 389 390 391 392 393 root 394 superuser 395 Charlie Root 396 397 1 398 1 399 400 401 402 403 404 405 407 409 411 412 413 417 418 419 420 421 admin 422 commonuser 423 Jim Green 424 425 9 426 90 427 428 429 430 431 432 433 435 Example 2: Abandon the remaining fragments 437 439 440 441 442 444 446 447 449 Authors' Addresses 451 Guangying Zheng 452 Huawei 453 101 Software Avenue, Yuhua District 454 Nanjing, Jiangsu 210012 455 China 457 Email: zhengguangying@huawei.com 459 Michael Wang 460 Huawei 461 101 Software Avenue, Yuhua District 462 Nanjing, Jiangsu 210012 463 China 465 Email: wangzitao@huawei.com