Subject: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 4 Jun 2014 10:22:12 +0000

Hi all,

We've posted a new draft, which is about NETCONF data fragmentation.

The basic idea is, when NMS is retrieving a large size of data in the device, the <rpc-reply> might be very big (e.g. the routes in a core router).
Currently there are mainly two methods of handling the big <rpc-reply>: one is stream-oriented handling; the other is just request a portion of the data.

This draft considers both the two methods are problematic in some situations, and proposes a new method which allows the large size <rpc-reply> to be fragmented in NETCONF level.

Please read the draft and comment.
Many thanks!

Best regards,
Bing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 04, 2014 5:27 PM
To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying
Subject: New Version Notification for draft-liu-netconf-fragmentation-00.txt

A new version of I-D, draft-liu-netconf-fragmentation-00.txt
has been successfully submitted by Bing Liu and posted to the IETF repository.

Name:		draft-liu-netconf-fragmentation
Revision:	00
Title:		A NETCONF Extension for Data Fragmentation
Document date:	2014-06-04
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-liu-netconf-fragmentation-00.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-netconf-fragmentation/
Htmlized:       http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00

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.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: chong feng <[email-masked]>
Date: Wed, 4 Jun 2014 23:32:55 +0800

Hi,
   I have reviewed this new draft.
   I understand your solution is that NETCONF server reserve break points
and wait for client to retrieve the next response.
I think it's not a good solution, because server may need to reserve many
break points if there a large number of concurrent requests.
It's too heavy for server. And, the server must be stateful if it support
get-block capability.

The other questions and comments are listed below:
1. Get-block capability should not change the get-config operation's
behavior. If client use get-config operation to retrieve data,
all data must be sent in one response or get-block capability should add a
parameter to get-config operation to indicate the
response data will be fragmented.
2. A set-id can be aged? when client never send a request to retrieve the
next fragment for a long time, I think this set-id should be aged,
otherwise, server will be reserve more and more set-ids.
3. A set-id is unique in session level or server level?
4. If a session is killed or closed, other session can retrieved the next
fragment if the client provide the correct set-id?
 /frank

2014-06-04 18:22 GMT+08:00 Liubing (Leo) <[email-masked]>:

> The basic idea is, when NMS is retrieving a large size of data in the
> device, the <rpc-reply> might be very big (e.g. the routes in a core
> router).
> Currently there are mainly two methods of handling the big <rpc-reply>:
> one is stream-oriented handling; the other is just request a portion of the
> data.
>
> This draft considers both the two methods are problematic in some
> situations, and proposes a new method which allows the large size
> <rpc-reply> to be fragmented in NETCONF level.
>
> URL:
> http://www.ietf.org/internet-drafts/draft-liu-netconf-fragmentation-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-liu-netconf-fragmentation/
> Htmlized:
> http://tools.ietf.org/html/draft-liu-netconf-fragmentation-00
>
>
> Abstract:
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Jun 2014 09:43:12 -0700

> It's too heavy for server. And, the server must be stateful if it support

I agree with these concerns.  Holding a snapshot of state data for
interactive retrieval
by the client is very expensive.

I do not agree with the premise that the client needs to know the key
values in advance.
An "iterator" approach allows a list resource to be retrieved in chunks.
 This is what RESTCONF
is going to do, and NETCONF could add a similar RPC function:

   rpc get-list {
     input {
       leaf target {
          type schema-instance-identifier;
          description "Identifies subtree to retrieve.";
      }
      leaf start {
         type uint32;
         default 0;
         description "Number of entries to skip before starting retrieval";
      }
      leaf max-entries {
        type uint32 { range "1..max"; }
        default 25;
        description "Maximum number of list entries to retrieve";
      }
    }
    output {
       anyxml data {
          description "Contains the requested data";
       }
    }
  }

  <rpc>
    <get-list>
      <target>/if:interfaces/if:interface</target>
    </get-list>
  </rpc>

  <rpc-reply>
     <data>
        <interfaces>
           <interface>   .... first entry </interface>
           ...
           <interface>   .... 25th entry </interface>
        </interfaces>
     </data>
  </rpc-reply>

   <rpc>
    <get-list>
      <target>/if:interfaces/if:interface</target>
      <start>25</start>
    </get-list>
  </rpc>

  <rpc-reply>
     <data>
        <interfaces>
           <interface>   .... 26th entry </interface>
           ...
           <interface>   .... 50th entry </interface>
        </interfaces>
     </data>
  </rpc-reply>

There is a problem with rapidly changing lists
(could get repeat entries on miss some entries), but the snapshot
approach uses too much memory, and if the list instances
change rapidly, a stale snapshot is not very useful.

Andy

---

From: [email-masked]
Date: Thu, 5 Jun 2014 08:59:43 +0800

andy,
   How to process nested lists using your solution?
 
For example:
   list foo {
       key a;
       leaf a {...}
       leaf b {...}
       list nested-foo {
            key nested-a;
            leaf nested-a {...}
            leaf netsted-b {...}
       }
   }

  If request is:
  <rpc>
     <get-list>
       <target>/foo</target>
     </get-list>
   </rpc> 
  What is the response?

And, another question:
Start-index is not reliable, if some entries are deleted. I think you can 
use start key instead.

/frank

"Netconf" <[email-masked]> 写于 2014-06-05 00:43:12:

> Andy Bierman <[email-masked]> 
> 发件人:  "Netconf" <[email-masked]>
> 
> 2014-06-05 00:43
> 
> 收件人
> 
> chong feng <[email-masked]>, 
> 
> 抄送
> 
> Zhengguangying <[email-masked]>, Netconf 
> <[email-masked]>, Yangang <[email-masked]>
> 
> 主题
> 
> Re: [Netconf] Netconf fragmentation-//FW: New Version Notification 
> for draft-liu-netconf-fragmentation-00.txt
> 
> 

>    I understand your solution is that NETCONF server reserve break 
> points and wait for client to retrieve the next response.
> I think it's not a good solution, because server may need to reserve
> many break points if there a large number of concurrent requests.
> It's too heavy for server. And, the server must be stateful if it 
> support get-block capability.
>  
> 
> I do not agree with the premise that the client needs to know the 
> key values in advance.
> An "iterator" approach allows a list resource to be retrieved in 
> chunks.  This is what RESTCONF
> all data must be sent in one response or get-block capability should
> add a parameter to get-config operation to indicate the 
> 2. A set-id can be aged? when client never send a request to 
> retrieve the next fragment for a long time, I think this set-id 
> should be aged,
> 4. If a session is killed or closed, other session can retrieved the
> next fragment if the client provide the correct set-id?
> /frank
> 

> The basic idea is, when NMS is retrieving a large size of data in 
> the device, the <rpc-reply> might be very big (e.g. the routes in a 
> core router).
> Currently there are mainly two methods of handling the big <rpc-
> reply>: one is stream-oriented handling; the other is just request a
> portion of the data.
> 
> submission until the htmlized version and diff are available at 
tools.ietf.org
> .

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Jun 2014 18:15:51 -0700

>    How to process nested lists using your solution?

I am not suggesting a standard solution, but IMO the client picks the
list it wants to iterate over, not the server.  If the client doesn't know
how the server will break up the subtree, it will have a lot of work
guessing what all the fragments mean.

> Start-index is not reliable, if some entries are deleted. I think you can
If the server can support snapshots of large lists (solutions like RMON2
usrHistoryTable
have been around for decades) then it can provide that feature without
changing NETCONF.
Data skew due to polling latency is a different problem then limiting the
size of data that
is processed by a client in 1 reply.

Andy

> > From: [email-masked] [mailto:[email-masked]
> <[email-masked]>]

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 05 Jun 2014 10:39:09 +0200

I am a bit concerned that we are now discussing a possible solution.

BUT.... I think we should first discuss on this list:

- Is the problem statement describing a real problem that we all agree with?

- If it is, do we believe that our WG should work on a solution?

Once we have agree on that, we can decide if we want to add this topic
to our WG charter and work on it.

Bert (speaking as co-chair)

On 05/06/14 02:59, [email-masked] wrote:
> Start-index is not reliable, if some entries are deleted. I think you can use start key instead.
>
>
>
> /frank
>
>  > submission until the htmlized version and diff are available at tools.ietf.org
>  > .
>  >
>  > The IETF Secretariat
>  >

---

From: [email-masked]
Date: Thu, 5 Jun 2014 17:11:40 +0800

/frank

"Bert Wijnen (IETF)" <[email-masked]> 写于 2014-06-05 16:39:09:

> "Bert Wijnen (IETF)" <[email-masked]> 
> 2014-06-05 16:39
> 
> 收件人
> 
> [email-masked], Andy Bierman <[email-masked]>, 
> 
> 抄送
> 
> Zhengguangying <[email-masked]>, Netconf <netconf-
> [email-masked]>, Netconf <[email-masked]>, Yangang 
<[email-masked]>
> 
> 主题
> 
> Re: [Netconf] 答复: Re:  Netconf fragmentation-//FW: New Version 
> Notification for draft-liu-netconf-fragmentation-00.txt
> 
I agree. But I don't agree with this solution. NETCONF server should be 
stateless, 
one request should only have one response.
> - If it is, do we believe that our WG should work on a solution?
I think WG should work on a solution. When we realized NETCONF, we also 
have encountered this problem.
> > ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and 
> confidential and is intended for the exclusive use of the addressee
> (s).  If you are not an intended recipient, any disclosure, 
> reproduction, distribution or other dissemination or use of the 
> information contained is strictly prohibited.  If you have received 
> this mail in error, please delete it and notify us immediately.
> >
> >
> >
> >
> > ZTE Information Security Notice: The information contained in this
> mail (and any attachment transmitted herewith) is privileged and 
> confidential and is intended for the exclusive use of the addressee
> (s).  If you are not an intended recipient, any disclosure, 
> reproduction, distribution or other dissemination or use of the 
> information contained is strictly prohibited.  If you have received 
> this mail in error, please delete it and notify us immediately.
> >
> >
> >
> >

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 5 Jun 2014 09:58:56 +0000

Hi Chong,

Thanks for your review and comments. Please see replies inline.

From: chong feng [mailto:[email-masked]]
Sent: Wednesday, June 04, 2014 11:33 PM
To: Liubing (Leo)
Cc: Netconf; Zhengguangying; Yangang
Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt

Hi,
   I have reviewed this new draft.
   I understand your solution is that NETCONF server reserve break points and wait for client to retrieve the next response.
I think it's not a good solution, because server may need to reserve many break points if there a large number of concurrent requests.
It's too heavy for server. And, the server must be stateful if it support get-block capability.
[Bing] The break point design is mainly for the issue of terminating the retrieving operation instantly. So before thinking of the design as too heavy or what, may I ask do you agree it is a requirement need to be solved?

Then for the “too heavy” consideration, I don’t think <get-block> would be wide used among operations, only if the retrieving data is too big. So basically I don’t think there would be a large number of concurrent requests.

The other questions and comments are listed below:
1. Get-block capability should not change the get-config operation's behavior. If client use get-config operation to retrieve data,
all data must be sent in one response or get-block capability should add a parameter to get-config operation to indicate the
response data will be fragmented.
[Bing] Yes, get-block capability is in use only if both of the client and server support the capability. And in current design, <get-block> is defined as a new operation along with <get-config>.
If I understand correctly, you had the assumption that it is the server who triggers the <get-block> operation in a response to <get-config>? If so, I think it is a good point that we should consider.

2. A set-id can be aged? when client never send a request to retrieve the next fragment for a long time, I think this set-id should be aged,
otherwise, server will be reserve more and more set-ids.
3. A set-id is unique in session level or server level?
4. If a session is killed or closed, other session can retrieved the next fragment if the client provide the correct set-id?
[Bing] Set-id is used for distinguishing fragments in a specific session. So when the session is killed, the set-ids are invalid as well.

Best regards,
Bing

/frank

2014-06-04 18:22 GMT+08:00 Liubing (Leo) <[email-masked]<mailto:[email-masked]>>:
Hi all,

Best regards,
Bing

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, June 04, 2014 5:27 PM
To: Liubing (Leo); Liubing (Leo); Zhengguangying; Zhengguangying
Subject: New Version Notification for draft-liu-netconf-fragmentation-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 5 Jun 2014 10:03:58 +0000

Hi Bert,

Many thanks for your consideration.
I fully agree we should focusing on the problem statement considering it is a -00 version draft.

For the solutions, we're open to discuss the alternatives.

Best regards,
Bing

> From: Netconf [mailto:[email-masked]] On Behalf Of Bert Wijnen
> (IETF)
> Sent: Thursday, June 05, 2014 4:39 PM
> To: [email-masked]; Andy Bierman
> Cc: Zhengguangying; Netconf; Netconf; Yangang
> Subject: Re: [Netconf] 答复: Re: Netconf fragmentation-//FW: New Version
> Once we have agree on that, we can decide if we want to add this topic to
> our WG charter and work on it.
> 
> >  > 发件人:  "Netconf" <[email-masked]>  >  > 2014-06-05
> 00:43
> > >  > 收件人
> >  >
> >  > chong feng <[email-masked]>,  >  > 抄送
> >  >
> >  > Zhengguangying <[email-masked]>, Netconf  >
> > <[email-masked]>, Yangang <[email-masked]>  >  > 主题
> >  >
> >  > I think it's not a good solution, because server may need to
> > reserve  > many break points if there a large number of concurrent
> requests.
> > > interactive retrieval  > by the client is very expensive.
> >  >
> >  > An "iterator" approach allows a list resource to be retrieved in  >
> > chunks.  This is what RESTCONF  > is going to do, and NETCONF could
> > add a similar RPC function:
> >  >
> >  >    rpc get-list {
> >  >      input {
> >  >        leaf target {
> >  > There is a problem with rapidly changing lists  > (could get repeat
> > entries on miss some entries), but the snapshot  > approach uses too
> > much memory, and if the list instances  > change rapidly, a stale
> > snapshot is not very useful.
> >  >
> >  > Andy
> >  >
> >  > 1. Get-block capability should not change the get-config
> > operation's  > behavior. If client use get-config operation to
> > retrieve data,  > all data must be sent in one response or get-block
> > capability should  > add a parameter to get-config operation to
> > indicate the  > response data will be fragmented.
> >  > 2. A set-id can be aged? when client never send a request to  >
> > retrieve the next fragment for a long time, I think this set-id  >
> > should be aged,  > otherwise, server will be reserve more and more
> > set-ids.
> >  > 4. If a session is killed or closed, other session can retrieved
> > the  > next fragment if the client provide the correct set-id?
> >  > /frank
> >  >
> >
> >  > Currently there are mainly two methods of handling the big <rpc-  >
> > > situations, and proposes a new method which allows the large size  >
> >  > From: [email-masked] [mailto:[email-masked]]  >
> > Sent: Wednesday, June 04, 2014 5:27 PM  > To: Liubing (Leo); Liubing
> > (Leo); Zhengguangying; Zhengguangying  > Subject: New Version
> > tools.ietf.org  > .
> > ZTE Information Security Notice: The information contained in this mail
> (and any attachment transmitted herewith) is privileged and confidential and
> is intended for the exclusive use of the addressee(s).  If you are not an
> intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.  If
> you have received this mail in error, please delete it and notify us
> immediately.
> >
> >
> >
> >
> > ZTE Information Security Notice: The information contained in this mail
> (and any attachment transmitted herewith) is privileged and confidential and
> is intended for the exclusive use of the addressee(s).  If you are not an
> intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.  If
> you have received this mail in error, please delete it and notify us
> immediately.
> >
> >
> >
> >

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jun 2014 03:41:41 -0700

> - Is the problem statement describing a real problem that we all agree

which problem? more than 1 has been described:

  1) the client can get a reply that is "too big" so it wants to ask for
well-formed
      XML documents that fragment the reply

  2) data skew can happen across polls so the server needs to snapshot
      the request and store it for the client to retrieve in pieces

> - If it is do we believe that our WG should work on a solution?
>
>
no -- neither problem is important enough to solve right now.
The client can use filtering to achieve (1) and (2) is not practical
because of memory constraints in devices.

> to our WG charter and work on it.

Would we be asking the IESG to approve a new charter while so much
of the current charter remains unfinished?

Andy

>> (and any attachment transmitted herewith) is privileged and confidential
>> and is intended for the exclusive use of the addressee(s).  If you are not
>> an intended recipient, any disclosure, reproduction, distribution or other
>> dissemination or use of the information contained is strictly prohibited.
>>  If you have received this mail in error, please delete it and notify us
>> immediately.
>>
>>
>>
>>
>> (and any attachment transmitted herewith) is privileged and confidential
>> and is intended for the exclusive use of the addressee(s).  If you are not
>> an intended recipient, any disclosure, reproduction, distribution or other
>> dissemination or use of the information contained is strictly prohibited.
>>  If you have received this mail in error, please delete it and notify us
>> immediately.
>>
>>
>>
>>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 5 Jun 2014 10:46:35 +0000

For your convenience, let me post the problems statement in the draft as the following:

o Problems of Stream-Oriented handling
Stream-Oriented method lacks the capability of discontinuing large size processing in the server. It would cause unnecessary resource/performance cost in the devices if the NMS has already got the intended portion or just canceled by the administrators.
Another problem is the implementation. SAX is not as widely supported as DOM [DOM-PARSING]. For example, it is not supported by some existing libraries such as libxml [LIBXML]. 
o Problems of subsets request
This method has an implication that the client needs to know the list/index of the intended large size data in advance before it starting the search request. It can’t fit the scenarios of real-time on-demand data retrieving. And there is no standard to specify the list/index format in a uniform way. Thus it is only suitable for private implementation, thus multi-vendor interaction is not supported.
More important, it is just an indirect way to solve the problem. It could not fit the scenarios where the client just needs the whole large size data in the server.

Best regards,
Bing

> From: Liubing (Leo)
> Sent: Thursday, June 05, 2014 6:04 PM
> To: 'Bert Wijnen (IETF)'; [email-masked]; Andy Bierman
> Subject: RE: [Netconf] Netconf fragmentation-//FW: New Version
> > > Start-index is not reliable, if some entries are deleted. I think
> > > you can use
> > start key instead.
> > >
> > >
> > >
> > > /frank
> > >
> > >  > Andy Bierman <[email-masked]>  > 发件人:  "Netconf"
> > > <[email-masked]>  >  > 2014-06-05
> > 00:43
> > > >  > 收件人
> > >  >
> > > > chunks.  This is what RESTCONF  > is going to do, and NETCONF
> > > could add a similar RPC function:
> > >  >
> > >  >    rpc get-list {
> > >  >      input {
> > >  >        leaf target {
> > >  > There is a problem with rapidly changing lists  > (could get
> > > repeat entries on miss some entries), but the snapshot  > approach
> > > uses too much memory, and if the list instances  > change rapidly, a
> > > stale snapshot is not very useful.
> > >  >
> > >  > Andy
> > >  >
> > > > the device, the <rpc-reply> might be very big (e.g. the routes in
> > > > a core router).
> > >  > has been successfully submitted by Bing Liu and posted to the
> > > IETF
> > repository.
> > >  >
> > >  >    Configuration) protocol. The extension allows NETCONF to
> handle
> > large
> > > mail
> > (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the
> > addressee(s).  If you are not an intended recipient, any disclosure,
> > > mail
> > (and any attachment transmitted herewith) is privileged and
> > confidential and is intended for the exclusive use of the
> > addressee(s).  If you are not an intended recipient, any disclosure,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jun 2014 14:42:14 +0200

On Thu, Jun 05, 2014 at 10:46:35AM +0000, Liubing (Leo) wrote:

> Another problem is the implementation. SAX is not as widely
> supported as DOM [DOM-PARSING]. For example, it is not supported by
> some existing libraries such as libxml [LIBXML].

I think this is not correct.

http://xmlsoft.org/interface.html

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 6 Jun 2014 10:41:48 +0000

Hi Andy,

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, June 05, 2014 6:42 PM
To: Bert Wijnen (IETF)
Cc: Zhengguangying; Yangang; Netconf; Netconf
Subject: Re: [Netconf] 答复: Re: Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt

On Thu, Jun 5, 2014 at 1:39 AM, Bert Wijnen (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
I am a bit concerned that we are now discussing a possible solution.

  1) the client can get a reply that is "too big" so it wants to ask for well-formed
      XML documents that fragment the reply

no -- neither problem is important enough to solve right now.
[Bing] The “too big reply” problem actually comes from real deployment requirement. Now there are some NMS that only provide NETCONF interface to the devices.
Especially when the NMS also get state data from NETCONF, the big reply problem would be highly expected. And since they only use NETCONF interface, it would be much better to solve the problem in a standard way.

The client can use filtering to achieve (1)
[Bing] May I ask whether you are referring to some specific filtering or just in general?
As I understand, filtering mechanisms could be:

-        For example, when the NMS wants to get a portion of the large amount routes, it could filter by interface, by prefix or some other conditions. However, since real deployment scenarios varied a lot, these conditions might not be able to guarantee the result is in the expected amount. Some interfaces might have only a few routes, while some might still have “too big” routes data.

-        Precise filtering like XPath, it might be better than above, but again it is not be able to guarantee to get a proper amount reply. More important, XPath is so sophisticated that some devices just don’t support it. Even if it is supported, it is obviously heavier than just retrieving.

So in general, I think filtering might be helpful, but it doesn’t really solve the problem.

and (2) is not practical
because of memory constraints in devices.
[Bing] Although now we just need to focus on the problem, I’d like to explain a bit more on our solution.

Our proposal is NOT snapshot. It doesn’t hold the whole result in the memory, it only holds the context (data offset .etc). When the NMS request the next block, the device could easily access to the block according to the context.

Best regards,
Bing

Andy

On 05/06/14 02:59, [email-masked]<mailto:[email-masked]> wrote:
andy,
    How to process nested lists using your solution?

For example:
    list foo {
        key a;
        leaf a {...}
        leaf b {...}
        list nested-foo {
key nested-a;
leaf nested-a {...}
leaf netsted-b {...}
        }
    }

   If request is:
<rpc>
      <get-list>
        <target>/foo</target>
      </get-list>
    </rpc>
   What is the response?

And, another question:

/frank

"Netconf" <[email-masked]<mailto:[email-masked]>> 写于 2014-06-05 00:43:12:

 > Andy Bierman <[email-masked]<mailto:[email-masked]>>
 > 发件人:  "Netconf" <[email-masked]<mailto:[email-masked]>>
 >
 > 2014-06-05 00:43
 >
 > 收件人
 >
 > chong feng <[email-masked]<mailto:[email-masked]>>,
 >
 > 抄送
 >
 > Zhengguangying <[email-masked]<mailto:[email-masked]>>, Netconf
 > <[email-masked]<mailto:[email-masked]>>, Yangang <[email-masked]<mailto:[email-masked]>>
 >
 > 主题
 >

 > On Wed, Jun 4, 2014 at 8:32 AM, chong feng <[email-masked]<mailto:[email-masked]>> wrote:
 > Hi,

 > submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>
 > .
 >
 > The IETF Secretariat
 >

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 6 Jun 2014 10:44:36 +0000

Hi Juergen,

Thanks for correcting the information. We'll revise it in the next version.

Nevertheless, it is not the essential problem of stream-oriented processing. The key point is that it lacks the ability of instant termination during the large size of data retrieving.

Best regards,
Bing

> From: Juergen Schoenwaelder
> [mailto:[email-masked]]
> Sent: Thursday, June 05, 2014 8:42 PM
> To: Liubing (Leo)
> Cc: Bert Wijnen (IETF); [email-masked]; Andy Bierman;
> Zhengguangying; Netconf; Yangang
> Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version
> > Another problem is the implementation. SAX is not as widely supported
> > as DOM [DOM-PARSING]. For example, it is not supported by some
> > existing libraries such as libxml [LIBXML].
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Jun 2014 04:36:44 -0700

On Fri, Jun 6, 2014 at 3:41 AM, Liubing (Leo) <[email-masked]>
wrote:

>  Hi Andy,
>
>
>
> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, June 05, 2014 6:42 PM
> *To:* Bert Wijnen (IETF)
> *Cc:* Zhengguangying; Yangang; Netconf; Netconf
> *Subject:* Re: [Netconf] 答复: Re: Netconf fragmentation-//FW: New Version
> [Bing] The “too big reply” problem actually comes from real deployment
> requirement. Now there are some NMS that only provide NETCONF interface to
> the devices.
>
> Especially when the NMS also get state data from NETCONF, the big reply
> problem would be highly expected. And since they only use NETCONF
> interface, it would be much better to solve the problem in a standard way.
>
>
>

the current standard supports subtree and XPath filtering.
Learn how to use them.

> -        For example, when the NMS wants to get a portion of the large
> amount routes, it could filter by interface, by prefix or some other
> conditions. However, since real deployment scenarios varied a lot, these
> conditions might not be able to guarantee the result is in the expected
> amount. Some interfaces might have only a few routes, while some might
> still have “too big” routes data.
>
> -        Precise filtering like XPath, it might be better than above, but
> again it is not be able to guarantee to get a proper amount reply. More
> important, XPath is so sophisticated that some devices just don’t support
> it. Even if it is supported, it is obviously heavier than just retrieving.
>

I think XPath works well enough.  Iterate over the list you care about.
Retrieve the entire list at once and it might be too big.

> Our proposal is NOT snapshot. It doesn’t hold the whole result in the
> memory, it only holds the context (data offset .etc). When the NMS request
> the next block, the device could easily access to the block according to
> the context.
>
>

In that case, your solution suffers all the data skew problems as if the
client held the state,
and none of the benefits. The server has the same problems remembering its
place in constantly
changing state as the client.

Andy

---

From: [email-masked]
Date: Mon, 9 Jun 2014 14:08:59 +0800

Hi,
  What's your problem? NMS wants to get a particular result, but server 
returns too large result? 
  Why not use subtree filter, XPATH filter or client's "iterator" in 
andy's proposal?

  I think the problem is that NMS wants to get a very large data, but they 
don't want to or can't parse too large xml repsonse. 
 
  There are 2 solutions to solve it. (I have developed the both many years 
ago,:-))
 
  The first is your solution. server keep break points and wait for 
client's request to get the next fragment. This solution have
  2 main problems. The former is the sever must be stateful and the state 
is held by client. It's not a good design pattern in C/S architecture.
  The latter is if client send many requests to retrieve large data, the 
sever have to keep many break points, it's too heavy for server.

  The second is "iterator" that andy propose. If response data is too 
large, client can send a request to get the special part of the data,e.g 
25 instances of the list,
  and send a next request to get the next part. Sever does not need to 
keep any break points.
  I think this solution is better than yours. But if there is nested list, 
the process is not simple as andy's example. 
 
/frank

"Netconf" <[email-masked]> 写于 2014-06-05 17:58:56:

> "Liubing (Leo)" <[email-masked]> 
> 2014-06-05 17:58
> Zhengguangying <[email-masked]>, Yangshouchuan 
> <[email-masked]>, Netconf <[email-masked]>, Yangang 
> <[email-masked]>
> 
> 主题
> 
> [Bing] The break point design is mainly for the issue of terminating
> the retrieving operation instantly. So before thinking of the design
> as too heavy or what, may I ask do you agree it is a requirement 
> need to be solved?
> 
> Then for the “too heavy” consideration, I don’t think <get-block> 
> would be wide used among operations, only if the retrieving data is 
> too big. So basically I don’t think there would be a large number of
> concurrent requests.
> 
> [Bing] Yes, get-block capability is in use only if both of the 
> client and server support the capability. And in current design, 
> <get-block> is defined as a new operation along with <get-config>.
> If I understand correctly, you had the assumption that it is the 
> server who triggers the <get-block> operation in a response to <get-
> config>? If so, I think it is a good point that we should consider. 
> 
> [Bing] Set-id is used for distinguishing fragments in a specific 
> session. So when the session is killed, the set-ids are invalid as well.
> 
> Best regards,
> Bing
> 
> /frank
> 
tools.ietf.org

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 11 Jun 2014 01:24:51 +0000

Hi Chong & all,

>What's your problem? NMS wants to get a particular result,
>but server returns too large result?
>Why not use subtree filter, XPATH filter or client's "iterator" in andy's proposal?

>I think the problem is that NMS wants to get a very large data, but they don't want to or can't parse too large xml repsonse.

Please pardon me repeating the issues.
Let me clearly separate the Problem and Solutions as the following.

- Problem to be solved:
either the NMS wants to get a particular result, or get a very large data store, the problem is the same: how do the client and server handle the large response? However, the latter should be the typical use case.

- Existing solutions:
1. Stream-oriented processing. As discussed in the draft, one big issue is that it lacks the ability of canceling the ongoing processing.
2. Subtree/XPath filtering. The problem is, the filtered results might still large.

- New proposed solutions:
1. <get-block> extension, which is proposed in the draft
2. <get-list> extension, which is proposed during recent mailing list discussion

So may I ask Chong and the WG, do you agree the “Existing solutions” are NOT sufficient enough to solve the problem, so that we need a NEW solution (regardless of which solution to choose)?

For the solution, now the point is stateful or stateless, we’d be glad to have further discussion in depth, but we’d like to confirm the problem first.

Many thanks.

Best regards,
Bing

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 09, 2014 2:09 PM
To: Liubing (Leo)
Cc: chong feng; Netconf; Netconf; Yangang; Yangshouchuan; Zhengguangying
Subject: Re: [Netconf] Netconf fragmentation-//FW: New Version Notification for draft-liu-netconf-fragmentation-00.txt

Hi,
  What's your problem? NMS wants to get a particular result, but server returns too large result?
  Why not use subtree filter, XPATH filter or client's "iterator" in andy's proposal?

  I think the problem is that NMS wants to get a very large data, but they don't want to or can't parse too large xml repsonse.

  There are 2 solutions to solve it. (I have developed the both many years ago,:-))

  The first is your solution. server keep break points and wait for client's request to get the next fragment. This solution have
  2 main problems. The former is the sever must be stateful and the state is held by client. It's not a good design pattern in C/S architecture.
  The latter is if client send many requests to retrieve large data, the sever have to keep many break points, it's too heavy for server.

  The second is "iterator" that andy propose. If response data is too large, client can send a request to get the special part of the data,e.g 25 instances of the list,
  and send a next request to get the next part. Sever does not need to keep any break points.
  I think this solution is better than yours. But if there is nested list, the process is not simple as andy's example.

/frank

"Netconf" <[email-masked]<mailto:[email-masked]>> 写于 2014-06-05 17:58:56:

> "Liubing (Leo)" <[email-masked]<mailto:[email-masked]>>
> Zhengguangying <[email-masked]<mailto:[email-masked]>>, Yangshouchuan
> <[email-masked]<mailto:[email-masked]>>, Netconf <[email-masked]<mailto:[email-masked]>>, Yangang
> <[email-masked]<mailto:[email-masked]>>
>
> 主题
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jun 2014 18:49:13 -0700

On Tue, Jun 10, 2014 at 6:24 PM, Liubing (Leo) <[email-masked]>
wrote:

> either the NMS wants to get a particular result, or get a very large data
> store, the problem is the same: how do the client and server handle the
> large response? However, the latter should be the typical use case.
>
>
>
> - Existing solutions:
>
> 1. Stream-oriented processing. As discussed in the draft, one big issue is
> that it lacks the ability of canceling the ongoing processing.
>
> So may I ask Chong and the WG, do you agree the “Existing solutions” are
> NOT sufficient enough to solve the problem, so that we need a NEW solution
> (regardless of which solution to choose)?
>

I do not agree that the server should hold any state at all for subtree
iteration.
In your solution the client has no idea how the server is going to break up
the subtrees
into responses.  The client cannot even ask for a "plain" <get-config>
instead of fragments.

There is a current solution for iteration.
The keys do not need to be known to iterate with XPath (e.g. position()
function).

   <filter type="xpath" select="/interfaces/interface[position() >= 0 and
position() < 25]" />

   <filter type="xpath" select="/interfaces/interface[position() >= 25 and
position() < 50]" />

IMO it is a very low priority to create yet another optional feature in
NETCONF.
Replacing 1 solution because it is not implemented on every server with
another
optional solution will not accomplish anything.

IMO it would require a new protocol version to force every server to
support new RPCs.

>
> For the solution, now the point is stateful or stateless, we’d be glad to
> have further discussion in depth, but we’d like to confirm the problem
> first.
>
>
>
> Many thanks.
>
>
>
> Best regards,
>
> Bing
>

Andy

>
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Monday, June 09, 2014 2:09 PM
> *To:* Liubing (Leo)
> *Cc:* chong feng; Netconf; Netconf; Yangang; Yangshouchuan; Zhengguangying
> *Subject:* Re: [Netconf] Netconf fragmentation-//FW: New Version
> large, client can send a request to get the special part of the data,e.g 25
> instances of the list,
> > From: chong feng [mailto:[email-masked]
> <[email-masked]>]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jun 2014 08:33:12 +0200

> 2. <get-list> extension, which is proposed during recent mailing list discussion

As mentioned in a different context, another solution is to change or
augment NETCONF at some point in time such that an <rpc> can lead to a
sequence of <rpc-reply/>s with a suitable cancel mechanism. This would
address the concern of large data retrievals but would also allow long
running asynchronous rpcs (the ping or traceroute example). The
benefit of such a solution would be that it can be utilized in many
contexts. But this is of course new protocol work and perhaps we need
to focus on finishing the currently chartered work items before taking
on new work.

/js

---

From: Giles Heron <[email-masked]>
Date: Wed, 11 Jun 2014 10:59:05 +0100

> to focus on finishing the currently chartered work items before taking

understood.

though isn't the issue to some extent that unless/until we have good solutions for such requirements then SPs will continue to use CLI-scripting and hence NETCONF will fail to offer a comprehensive management solution (and if you use CLI-scripting for one thing you might as well use it for everything - or so the argument might go)?

my preference would be to add the sequence of <rpc-reply/> to NETCONF 1.1.

Giles

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jun 2014 12:11:58 +0200

On Wed, Jun 11, 2014 at 10:59:05AM +0100, Giles Heron wrote:
> though isn't the issue to some extent that unless/until we have good
> solutions for such requirements then SPs will continue to use
> CLI-scripting and hence NETCONF will fail to offer a comprehensive
> management solution (and if you use CLI-scripting for one thing you
> might as well use it for everything - or so the argument might go)?
> 

NETCONF 1.1 is defined in RFC 6241 so it is difficult to add something
to it. It may be possible to engineer this as an extension of NETCONF
1.1., i.e., a protocol capability that does not require to revise RFC
6241. But I have not worked this through and so this is more wild
guessing at the moment. At the end, someone has to invest time and sit
down to work out a concrete solution proposal.

/js

---

From: Giles Heron <[email-masked]>
Date: Wed, 11 Jun 2014 11:13:10 +0100

> down to work out a concrete solution proposal.

sorry - brain out of gear.  Was thinking YANG rather than NETCONF.

But yes, it'd be nice to work out how to do this.

Giles

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jun 2014 05:26:26 -0700

On Wed, Jun 11, 2014 at 3:13 AM, Giles Heron <[email-masked]> wrote:

> On 11 Jun 2014, at 11:11, Juergen Schoenwaelder <
> [email-masked]> wrote:
>
> >> On 11 Jun 2014, at 07:33, Juergen Schoenwaelder <
> [email-masked]> wrote:
> >>

This is a really weak argument. Many vendors are adopting NETCONF.
A vendor can add all the RPCs they want to the protocol instead of
blaming complete inaction on the lack of a standard YANG module.
Most MIB modules were proprietary, not standard, so lack of standard modules
has never been a real concern of vendors.

> >> my preference oyuld be to add the sequence of <rpc-reply/> to
> >> NETCONF 1.1.
>

Why did you dismiss notifications?
Seems like NETCONF already supports multiple messages from server to client
that can be sent at any time.

> But yes, it'd be nice to work out how to do this.
I am concerned about the NETMOD WG's perception that it can
change NETCONF normative behavior by changing YANG.

I do not see how "extra" RPC replies can be considered backward compatible.
If the message-id doesn't change they will look like duplicate replies.
If the message-id is new the client won't have a request to match against
it.
I do not think it would be good design to change the NETCONF RPC model with
a sentence or 2 in a YANG description-stmt.

Giles

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jun 2014 14:50:27 +0200

> a sentence or 2 in a YANG description-stmt.

Nobody proposed that.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jun 2014 05:58:38 -0700

> > a sentence or 2 in a YANG description-stmt.

Sorry.  So this would be a new protocol version for NETCONF?
We would obsolete base:1.1 and create a base:1.2 or something like that?
There will be no attempt to alter the RPC layer by any other means.

/js
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jun 2014 15:45:39 +0200

> There will be no attempt to alter the RPC layer by any other means.

I think even a capability could be sufficient. Here is a very rough
sketch:

  If a server announces :linked-replies and the client supports it as
  well, the client can add an additional parameter to an rpc to
  indicate the possible use of linked-replies. An old client will of
  course never do this. Here is what a new client might do if it
  wants to use linked replies:

  <rpc message-id="101" link-id="123" xmlns="...">
  </rpc>

  The server can either simply send an rpc-reply or it starts sending
  linked replies, e.g.:

  <rpc-reply message-id="101" next-message-id="102" link-id="123" xmlns="...">
  </rpc-reply>

  <rpc-reply message-id="102" next-message-id="103" link-id="123" xmlns="...">
  </rpc-reply>

  <rpc-reply message-id="103" link-id="123" xmlns="...">
  </rpc-reply>

Of course, there are lots of unclear questions concerning data
merging, error handling, how to send a cancel for a given link-id
(e.g., by sending a new <rpc-cancel> message with a matching link-id)
and so on. I do not see that this would cause an interoperability
problem. Even if an old client would accidentally send a link-id, it
would simply pick the first rpc-reply and drop the rest because of
unknown message-ids.

Anyway, there are tons of details to work out (also whether it is
necessary to negotiate linked rpc-reply sizes or whether it is good
enough for the server to decide freely as it likes). This is really
just a very very rough idea. However, it believe that thinking in this
direction may lead to better support for asynchronous rpcs and rpcs
that potentially return very large chunks of data than trying to solve
this problem without enhancements of the rpc layer.

To me, it seems a capability is sufficient to achieve interoperability.
Of course, some people may argue that changes of the message layer go
too far for a capability. But then RFC 5277 also added a new message
using essentially just a capability - so there is already a precendence.

/js

---

From: Giles Heron <[email-masked]>
Date: Wed, 11 Jun 2014 14:53:24 +0100

Hi Andy,

> has never been a real concern of vendors.

agreed - it's weak.  But I can see people taking that view :(

At any rate I wasn't saying "NETCONF won't be adopted until there are standardised YANG modules for everything".

I was rather saying that if NETCONF can only be used for configuration and for a subset of operations (e.g. a subset that excludes things like ping/traceroute) then even if all vendors adopt NETCONF it will leave SPs still needing CLI scripts to do ping/traceroute/etc.

> that can be sent at any time.

Yes - but it seems a bit ugly to me to have to, for example, send an RPC to start e.g. a ping and be told in the RPC reply that I then need to subscribe to temporary stream "foo" to get the responses.

Also if we follow your logic that the NETCONF stream will carry all NETCONF Notifications then wouldn't those notifications also end up in that stream?

> change NETCONF normative behavior by changing YANG. 

I never suggested changing YANG (and I don't think Juergen did either).  I meant that my "1.1" comment was because I was thinking of the YANG 1.1 process.

Giles

> If the message-id is new the client won't have a request to match against it.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jun 2014 06:53:51 -0700

On Wed, Jun 11, 2014 at 6:45 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > > I do not think it would be good design to change the NETCONF RPC
> model
> > > with
OK - If the client and server both advertised the capability (ala base:1.1)
then a new capability could work.  The client is going to send
message-id=103 so
if the server sends a reply out of order, your solution will break.
It would work better if the original message-id was retained and just the
link-id
kept changing. Not sure why a next-link-id is needed.  Increment a uint32.

  { message-id, link-id } forms a set of unique tuples fo a given linked
reply.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Jun 2014 10:57:56 +0200

>   { message-id, link-id } forms a set of unique tuples fo a given linked

Sure, the details can be worked out. The message-ids are pretty opaque
in NETCONF and I just picked simple numbers and you are right that
they might clash.

My point was more that having a more powerful rpc layer would solve
some problems in a much nicer way. In hindsight, if we would have had
such a linked reply mechanism in the RPC layer, we likely would not
have needed the special purpose <notification> message in RFC 5277.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jun 2014 03:54:37 -0700

> in NETCONF and I just picked simple numbers and you are right that
not the point.  They are client-selected strings.  The only way the server
can
be 100% sure never to collide --  the server can never pick a message-id.
(This field does not exist in a notification.)

> have needed the special purpose <notification> message in RFC 5277.

The notification message is needed because event notifications are not
linked
replies.  Multiple replies per RPC request has some special purpose uses.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Jun 2014 13:01:13 +0200

On Mon, Jun 16, 2014 at 03:54:37AM -0700, Andy Bierman wrote:
> not the point.  They are client-selected strings.  The only way the
> server can be 100% sure never to collide -- the server can never
> pick a message-id.  (This field does not exist in a notification.)

OK. Pick some other field.

> The notification message is needed because event notifications are
> not linked replies.  Multiple replies per RPC request has some
> special purpose uses.

Notification messages are not linked replies since linked replies did
not exist. 

What I am saying is that at the end of the day, once could have
modeled a 'create-subscription' rpc as a long lasting rpc, much like a
'ping' that runs indefinitely or a 'tail -f' that runs indefinitely. I
think we created a special purpose solution for notifications but in
hindsight it could have been equally possible to build a more general
purpose mechanism.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jun 2014 07:25:06 -0700

> OK. Pick some other field.

You did -- the server always send the message-id the client first picked,
and just increments the link-id  { 101, 1 }, { 101, 2 }, { 101, 3 }, etc.

> hindsight it could have been equally possible to build a more general

OK - maybe we would have also decoupled the replay buffer features if
we did it that way.  In hindsight, we know that the XSD needs to be
replaced by a YANG module, but we decided that was not worth doing.

We implement source filtering in our server, since the standard filtering
works on the
output of the replay buffer. The WG might have thought more about how
some event notifications can overwrite higher priority events in the ring
buffer.
IMO the lack of standardized fields such as 'severity' is a problem.
A giant firehose stream called "NETCONF" is not that useful.

/js

Andy