idnits 2.17.00 (12 Aug 2021) /tmp/idnits14048/draft-liu-netconf-multiple-replies-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 4 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 (March 22, 2016) is 2244 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) ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: draft-ietf-i2rs-pub-sub-requirements has been published as RFC 7923 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 netconf B. Liu 3 Internet-Draft G. Zheng 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 23, 2016 M. Jethanandani 6 Cisco Systems 7 K. Watsen 8 Juniper Networks 9 March 22, 2016 11 Processing Multiple Replies for One Request in NETCONF 12 draft-liu-netconf-multiple-replies-02 14 Abstract 16 This document discusses several scenarios that multiple replies for a 17 single request are needed, with the ability to terminate the replies 18 at any time. Such scenarios are not well supported by current 19 NETCONF (Network Configuration) protocol. An extention at the 20 NETCONF messaging layer is needed to fulfill the requirement. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 23, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language and Terminology . . . . . . . . . . . . 3 58 3. Scenarios and Problems . . . . . . . . . . . . . . . . . . . 3 59 3.1. Bulk . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Persistent . . . . . . . . . . . . . . . . . 5 61 3.3. Long time . . . . . . . . . . . . . . . . . . 5 62 3.4. Datastore push updates . . . . . . . . . . . . . . . . . 5 63 4. Requriments for NETCONF . . . . . . . . . . . . . . . . . . . 6 64 5. Candidate Solutions . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Get-block Mechanism . . . . . . . . . . . . . . . . . . . 6 66 5.1.1. Design Requirements . . . . . . . . . . . . . . . . . 6 67 5.1.2. extention . . . . . . . . . . . . . . . . 7 68 5.2. Linked Replies . . . . . . . . . . . . . . . . . . . . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Examples of the Candidate Solutions . . . . . . . . 9 76 A.1. Example . . . . . . . . . . . . . . . . . . . 9 77 A.2. Linked-replies Example . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 The message procedures of NETCONF [RFC6241] are based on RPC (Remote 83 Procedure Call) interactions. A NETCONF client/server sends a 84 message to the counterpart and then receives a replying 85 message. 87 In some situations, it might need multiple messages for a 88 request. For example, the the message might be 89 very large that it needs to be fragmented into multiple small ones; 90 or some operations (e.g. ping) need persistent replies till such time 91 that a terminaing condition is encountered or when the operation is 92 cancelled. 94 This document discusses such kind of multiple replies scenarios, 95 analyzes the issues of current NETCONF protocol in supporting these 96 scenarios, and proposes several candidate solutions for discussion. 98 2. Requirements Language and Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 [RFC2119] when they appear in ALL CAPS. When these words are not in 104 ALL CAPS (such as "should" or "Should"), they have their usual 105 English meanings, and are not to be interpreted as [RFC2119] key 106 words. 108 Terminology: 110 CLI: Command Line interface 112 DOM: Document Object Model, which is a cross-platform and language- 113 independent convention for representing and interacting with objects 114 in HTML, XHTML and XML documents. Objects in the DOM tree may be 115 addressed and manipulated by using methods on the objects. 117 RPC: Remote Procedure Call 119 SAX: Simple API for XML, which is an event sequential access parser 120 API developed by the XML-DEV mailing list for XML documents. SAX 121 provides a mechanism for reading data from an XML document that is an 122 alternative to that provided by the DOM. Where the DOM operates on 123 the document as a whole, SAX parsers operate on each piece of the XML 124 document sequentially. 126 libxml: a software library for parsing XML documents. 128 : a capability and operation defined in this document to 129 handle large size messages. 131 3. Scenarios and Problems 133 This section discusses several scenarios where multiple replies might 134 be needed, and anylizes the problems of current NETCONF protocol in 135 supporting these scenarios. 137 3.1. Bulk 139 The message might be very large in following situations: 141 o retrieving a large amount of routes in a core router 143 o retrieving a large interface statistics list 145 o doing a full-synchronizing with a device 146 Current there are already some methods of processing bulk replies as 147 the following. However, there are some issues as analyzed below. 149 1) Stream-Oriented Handling 151 Stream-Oriented handling mainly includes the following two aspects: 153 o The server encapsulates the large size replying data in a message and streams it to the client through transport 155 protocol. 157 o The client parses the received content in a stream- 158 oriented way. More specifically, the client could utilize SAX 159 parsing to instantly parse the received content without waiting 160 for the whole message been transported. 162 The problems are: 164 o Stream-Oriented method lacks the capability of discontinuing large 165 size processing in the server. It would cause unnecessary 166 resource/performance cost in the devices if the NETCONF client has 167 already got the intended portion or just canceled by the 168 administrators. 170 o Another problem is the implementation of SAX parsing is more 171 complex than DOM parsing in the NETCONF client. More computing 172 burden will be taken to support SAX parsing. 174 2) Requesting a Portion of Data 176 The clients actively limit the search range of the data so that the 177 servers only need to reply with a part of the large size data. Thus 178 the clients could control the replies in a reasonable size. One 179 example is that the clients get a list of the content, and provide a 180 start offset and a max-count, to get a portion at a time. 182 The problems are: 184 o This method has an implication that the client needs to know the 185 list/index of the intended large size data in advance before it 186 starting the search request. It can't fit the scenarios of real- 187 time on-demand data retrieving. And there is no standard to 188 specify the list/index format in a uniform way. Thus it is only 189 suitable for private implementation, thus multi-vendor interaction 190 is not supported. 192 o More important, it is just an indirect way to solve the problem. 193 It could not fit the scenarios where the client just needs the 194 whole large size data in the server. 196 3.2. Persistent 198 One of the operations that CLI offers today is the ability to issue 199 an operation that might result in multiple responses being returned, 200 till such time that a terminaing condition is encountered or when the 201 operation is cancelled. An example of such an operation is when the 202 ping or a traceroute command is issued. In the former case, the 203 operation can continue sending responses back till it is cancelled, 204 while in the latter case there is usually a terminating condition 205 that stops the responses. 207 NETCONF protocol as defined today sends a single RPC request and 208 expects a single reply to that request. The "persistent" operation 209 defined above expects multiple responses for a single request, till 210 such time a terminating condition is encountered. 212 3.3. Long time 214 Some operations might take a long time to perform (e.g. network link 215 performance validation), so there could be multiple responses for the 216 request. For example, initial responses returns handle which the 217 client uses to monitor progress till the final result. The client 218 should be able to cancel the request at any time. 220 3.4. Datastore push updates 222 In [I-D.clemm-netconf-yang-push] and 223 [I-D.ietf-i2rs-pub-sub-requirements], it describes a scenario where 224 client applications need to request updates from a YANG datastore, 225 without requiring additional client requests. 226 [I-D.clemm-netconf-yang-push] proposes to extend notification 227 messaging to fulfill the requirement that a comprehensive 228 subsription/publication model could be well supported. 230 The datastore sub/pub might need specific data modeling and operation 231 extention. However, at the NETCONF message layer, this draft 232 considers multiple replies could be an alternative solution for sub/ 233 pub comparing with notification messaging extention. 235 [Open Question] Need more in-depth analysis and comparison of the two 236 alternatives. 238 4. Requriments for NETCONF 240 Given above mentioned multiple-replies scenarios and problems, the 241 requriments for NETCONF protocol could be summarized as a mechanism 242 with the following abilities: 244 o be able to generate and handle multiple messages for a 245 given message 247 o be able to terminate the at any time 249 o be able to cancel the request in pipeline scenarios 251 5. Candidate Solutions 253 (Editor notes: this section discusses possible solutions. The 254 fragmentation mechanism is from the draft 255 [I-D.liu-netconf-fragmentation]. The other one was proposed during 256 mailing list discussion by Juergen Schoenwaelder. We include both of 257 them for discussion and solution selection.) 259 5.1. Get-block Mechanism 261 This section proposes a method of extending the NETCONF protocol to 262 allow handling the replying data as multiple blocks. It 263 allows the NETCONF client to terminate the block data processing 264 momentarily by protocol interactions; and also allows the blocked 265 messages to be instantly parsed piece by piece. Specifically, the 266 mechanism is achieved by a newly defined capability and 267 relevant operations. 269 5.1.1. Design Requirements 271 Two essential requirements of the Get-block mechanism are: 273 o It needs to allow the NETCONF client to terminate the data 274 processing momentarily by protocol interactions. In the proposed 275 mechanisms in this draft, when the NETCONF server replies the 276 client an , it will wait the response from the client 277 that whether it needs to send the next block. So if the initiator 278 has got the intended portion, it could terminate the process 279 immediately. 281 o It needs to allow the NETCONF client to instantly parse the blocks 282 piece by piece through the more widely supported DOM parsing. So 283 in this document, it specifies that each block MUST be 284 in a complete XML form. 286 (Editor notes: this solution was originally designed for large size 287 fragmentation processing. However, the rationale of this solution 288 has the potential to fulfill the other scenarios.) 290 5.1.2. extention 292 o Function 294 The devices can only use operation when the Get-block 295 capability was announced. 297 The rules are: 299 A. There should be a Max-Size for each block. [Open 300 Question]Should there be a clear specification of the size? 301 E.g. 64K bytes. 303 B. When the message reaches the Max-Size, it is sent to the 304 client and the next message could be created in advance. 306 C. Different records from one same table could be put into 307 different messages 309 D. All of the fields in one record MUST be put into one message. 312 E. XML syntax MUST be complete in each block message, so that 313 each block could be parsed individually. 315 F. If the record(s) of the child node(s)/table(s) and the parent 316 node(s)/table(s) are replied in different blocks, the child 317 node/table block MUST include the path and index information 318 of all the ancestor node(s)/table(s) in a hierarchical mode. 320 o Parameters 322 : in operation, if the parameter 323 is conveyed, it means the operation is terminated. Then it 324 doesn't need to reply the remaining blocks. 326 o Successful Operation Reply 328 A message conveying a element indicates the 329 operation is successful. 331 If there exists a next block, then an set-id attribute MUST be 332 included in the messge. The attribute set-id is used 333 to identify different block sets. 335 o Exception Handling 337 After the NETCONF server replies a block, if there is no 338 corresponding Get-block request from the client in a reasonable 339 period (the time valued to be specified in the future), then the 340 server release the offset of the replying data and cannot use 341 operation anymore, and the remaining data needs to be 342 replied. 344 Please refer to Appendix A.1 for an example. 346 5.2. Linked Replies 348 Another solution is to change or augment NETCONF at some point in 349 time such that an can lead to a sequence of with a 350 suitable cancel mechanism. A simple approach is to add a linked- 351 replies capability. If a server announces "linked-replies" 352 capablility and the client supports it as well, the client can add an 353 additional parameter to an rpc to indicate the possible use of 354 linked-replies. 356 Please refer to Appendix A.2 for an example. 358 This would address the concern of large data retrievals but would 359 also allow long running asynchronous rpcs (the ping or traceroute 360 example). This approach may lead to better support for asynchronous 361 rpcs and rpcs that potentially return very large chunks of data than 362 trying to solve this problem without enhancements of the rpc layer. 363 Design details concerning data merging, error handling, how to send a 364 cancel for a given link-id (e.g., by sending a new 365 message with a matching link-id) and whether it is necessary to 366 negotiate linked rpc-reply sizes or whether it is good enough for the 367 server to decide freely as it likes etc. need further study. 369 6. Security Considerations 371 TBD. 373 7. IANA Considerations 375 This draft does not request any IANA action. 377 8. Acknowledgements 379 Gang Yan and Shouchuan Yang made significant contribution to form the 380 draft. Valuable comments were received from Andy Bierman, Juergen 381 Schoenwaelder, Balazs Lengyel, Martin Bjorklund, Chong Feng and some 382 other people in Netconf working group. 384 This document was produced using the xml2rfc tool [RFC2629]. 385 (initiallly prepared using 2-Word-v2.0.template.dot. ) 387 9. References 389 9.1. Normative References 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, 393 DOI 10.17487/RFC2119, March 1997, 394 . 396 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 397 DOI 10.17487/RFC2629, June 1999, 398 . 400 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 401 and A. Bierman, Ed., "Network Configuration Protocol 402 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 403 . 405 9.2. Informative References 407 [I-D.clemm-netconf-yang-push] 408 Clemm, A., Prieto, A., and E. Voit, "Subscribing to YANG 409 datastore push updates", draft-clemm-netconf-yang-push-02 410 (work in progress), October 2015. 412 [I-D.ietf-i2rs-pub-sub-requirements] 413 Voit, E., Clemm, A., and A. Prieto, "Requirements for 414 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 415 requirements-05 (work in progress), February 2016. 417 [I-D.liu-netconf-fragmentation] 418 Liu, B. and G. Zheng, "A NETCONF Extension for Data 419 Fragmentation", draft-liu-netconf-fragmentation-01 (work 420 in progress), October 2014. 422 Appendix A. Examples of the Candidate Solutions 424 A.1. Example 426 Example 1: Get the next block 427 429 430 431 433 434 435 436 437 438 439 440 442 446 447 448 449 450 root 451 superuser 452 Charlie Root 453 454 1 455 1 456 457 458 459 460 461 462 464 466 468 469 470 474 475 476 477 478 admin 479 commonuser 480 Jim Green 481 482 9 483 90 484 485 486 487 488 489 490 492 Example 2: Abandon the remaining blocks 493 495 497 498 499 501 503 504 506 Example 3: Following is an example of the rule f in Section 4.1.2. 507 The child eTable is in a different message with the parents 508 aTable->bTable->cTable->dTable. Then the path and index information 509 of all the ancestors MUST included in the search data. 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 A.2. Linked-replies Example 530 Here is what a new client might do if it wants to use linked replies: 532 533 535 The server can either simply send an rpc-reply or it starts sending 536 linked replies, e.g.: 538 539 541 542 544 545 547 Authors' Addresses 549 Bing Liu 550 Huawei Technologies 551 Q14, Huawei Campus, No.156 Beiqing Road 552 Hai-Dian District, Beijing, 100095 553 P.R. China 555 Email: leo.liubing@huawei.com 557 Guangying Zheng 558 Huawei Technologies 559 Huawei Nanjing R&D Center 560 101 Software Avenue, Yuhua District, Nanjing, Jiangsu, 210012 561 P.R. China 563 Email: zhengguangying@huawei.com 565 Mahesh Jethanandani 566 Cisco Systems 567 USA 569 Email: mjethanandani@gmail.com 570 Kent Watsen 571 Juniper Networks 573 Email: kwatsen@juniper.net