Netconf G. Zheng
Internet-Draft M. Wang
Intended status: Informational Huawei
Expires: December 22, 2018 June 20, 2018

A NETCONF Extension for Data Fragmentation
draft-zheng-netconf-fragmentation-01

Abstract

This document introduces an extension to NETCONF (Network Configuration) protocol. The extension allows NETCONF to handle large size data as fragmented RPC messages. Specifically, this document defines a new <get-block> capability and relevant operations to handle the fragmentations.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 22, 2018.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

NETCONF [RFC6241] is the next generation network management protocol for configuring devices. It is becoming more and more popular, and some NMS (Network Management System) only use NETCONF as its southbound interface. The message procedures of NETCONF are based on RPC (Remote Procedure Call) interactions. A NETCONF client/server sends a <rpc> message to the counterpart and then receives a replying <rpc-reply> message.

In some situations, the <rpc-reply> message might be very large. For example, when NMS is retrieving a large amount of routes in a core router or doing a full-synchronizing with a device, the <rpc-reply> data might exceed Mega-Byte amount. And also in some scenarios, the client may retrieve a continuous stream of operational data from the operational datastore [I-D.ietf-netmod-revised-datastores] to perform network analytics. Then there comes the problem of how to handle the large size data. This document briefly introduces two typical ways of current handling on this issue; and analyzes the problems of them.

To fix the problems, in Section 4, this document proposes a method of extending the NETCONF protocol to allow handling large size data as fragmented <rpc-reply> messages. The fragmentation is done at the NETCONF level, so it allows the NETCONF client to terminate the large size data processing momentarily by protocol interactions; and also allows the fragmented messages to be instantly parsed piece by piece. Specifically, the fragmentation is achieved through a newly defined <get-block> capability and relevant operations.

2. Concept and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2.1. Terminology

DOM: Document Object Model, which is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML and XML documents. Objects in the DOM tree may be addressed and manipulated by using methods on the objects.

SAX: Simple API for XML, which is an event sequential access parser API developed by the XML-DEV mailing list for XML documents. SAX provides a mechanism for reading data from an XML document that is an alternative to that provided by the DOM. Where the DOM operates on the document as a whole, SAX parsers operate on each piece of the XML document sequentially.

libxml: a software library for parsing XML documents.

<get-block>: a capability and operation defined in this document to handle large size

3. Current Large size Handling Methods and Problems

3.1. Stream-Oriented Handling

Stream-Oriented handling mainly includes the following two aspects:

Problems:

3.2. Requesting a Portion of Data

The clients actively limit the search range of the data so that the servers only need to reply with a part of the large size data. Thus the clients could control the replies in a reasonable size. One example is that the clients get a list of the content, and provide a start offset and a max-count, to get a portion at a time.

Problems:

3.3. Using tools to extract data respectively

In this way, it mainly includes the following two steps:

Problems:

4. Netconf Fragmentation Mechanism

4.1. Fragmentation Requirements

this document proposes an RPC fragmentation mechanism to handle the large size data. Two essential requirements of the fragmentation are:

4.2. <get-block> extention

o Function

The devices can only use <get-block> operation when the Get-block capability was announced.

The <get-block> fragmentation rules are:

o Parameters

<discard-fragmentation>: in <get-block> operation, if the <discard-fragmentation> parameter is conveyed, it means the operation is terminated. Then it doesn't need to reply the remaining fragmentations.

o Successful Operation Reply

A <rpc-reply> message conveying a <data> element indicates the operation is successful. If there exists a next fragment, then an set-id attribute MUST be included in the <rpc-reply> messge. The attribute set-id is used to identify different fragment sets.

o Exception Handling

After the NETCONF server replies a fragment, if there is no corresponding Get-block request from the client in a reasonable period (the time valued to be specified in the future), then the server release the offset of the replying data and cannot use <get-block> operation anymore, and the remaining data needs to be replied.

Please refer to Appendix A.1 for an example.

5. YANG data model

<CODE BEGINS> file "ietf-netconf-fragmentation@2018-06-20.yang"
 module ietf-netconf-fragmentation {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-fragmentation";
     prefix fgm;
     
	 import ietf-datastores{
	  prefix ds;
	 }
	  
     import ietf-yang-types {
       prefix yang;
     }
	 
     import ietf-netconf {
       prefix nc;
     }

     organization
       "IETF NETCONF Working Group";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/netconf/>

        WG List:  <mailto:netconf@ietf.org>

        Author:   Guangying Zheng 
		          <zhengguangying@huawei.com>
				  
        Author:   Zitao Wang
		          <wangzitao@huawei.com>";
     description
       "This document introduces an extension to NETCONF (Network Configuration) protocol.  
	   The extension allows NETCONF to handle large size data as fragmented RPC messages.  
	   Specifically, this document defines a new get-block capability and relevant 
	   operations to handle the fragmentations.";

     revision 2018-06-20 {
       description
         "Initial revision.";
       reference "draft-zheng-netconf-fragmentation-01";
     }
	 
	 
	 rpc get-block {
       description
         "Retrieve data from an NMDA datastore.";
       input {
         leaf source {
           type identityref {
            base ds:datastore;
           }
           mandatory true;
           description
             "Datastore from which to retrieve data.";
         }

         choice filter-spec {
           description
             "The content filter specification for this request.";

           anydata subtree-filter {
             description
               "This parameter identifies the portions of the
                target datastore to retrieve.";
             reference "RFC 6241, Section 6.";
           }
           leaf xpath-filter {
             if-feature nc:xpath;
             type yang:xpath1.0;
             description
               "This parameter contains an XPath expression
                identifying the portions of the target
                datastore to retrieve.";
           }
         }
     }
	}
	rpc discard-fragmentation {
	    description
        "Discard the netconf fragmentation, if the discard parameter is conveyed, 
		it means the operation is terminated.  
		Then it doesn't need to reply the remaining fragmentations.";
    }

}
<CODE ENDS>

6. Security Considerations

TBD.

7. IANA Considerations

TBD.

8. Normative References

[I-D.ietf-netmod-revised-datastores] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K. and R. Wilton, "Network Management Datastore Architecture", Internet-Draft draft-ietf-netmod-revised-datastores-10, January 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011.

Appendix A. Appendix A: Examples of the Candidate Solutions

A.1. <get-block> (RPC Fragmentation) Example:

Example 1: Get the next fragment

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users/>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0"
          xmlns:hw=http://www.huawei.com/NETCONF/capability/base/1.0
hw:set-id="101">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
               <type>superuser</type>
               <full-name>Charlie Root</full-name>
               <company-info>
                 <dept>1</dept>
                 <id>1</id>
               </company-info>
             </user>
             <!-- additional <user> elements appear here... -->
           </users>
         </top>
       </data>
     </rpc-reply>

<rpc message-id="102"
          xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">
       <get-block xmlns="http://www.huawei.com/NETCONF/capability/base/1.0"
set-id="101">
       </get-block>
     </rpc>
     <rpc-reply message-id="102"
          xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0"
          xmlns:hw=http://www.huawei.com/NETCONF/capability/base/1.0
hw:set-id="101">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>admin</name>
               <type>commonuser</type>
               <full-name>Jim Green</full-name>
               <company-info>
                 <dept>9</dept>
                 <id>90</id>
               </company-info>
             </user>
             <!-- additional <user> elements appear here... -->
           </users>
         </top>
       </data>
     </rpc-reply>

Example 2: Abandon the remaining fragments

     <rpc message-id="103"
          xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">
       <get-block xmlns=http://www.huawei.com/NETCONF/capability/base/1.0 set-id="1">
         <discard-fragmentation/>
       </get-block>
     </rpc>

     <rpc-reply message-id="103"
       xmlns="urn:ietf:params:xml:ns:NETCONF:base:1.0">
       <ok/>
     </rpc-reply>

Authors' Addresses

Guangying Zheng Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China EMail: zhengguangying@huawei.com
Michael Wang Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China EMail: wangzitao@huawei.com