Subject: rpc-reply fragmentation

From: 李岩 <[email-masked]>
Date: Thu, 22 Dec 2005 11:37:19 +0800

Hi

I think we need rpc-reply fragmentation when the result of get or get-config
operation is very huge.

Suppose I retrieve a route table which contains 10,000 routes. I have to
wait for a long time until the device form a whole rpc-reply. If we allow
rpc-reply fragmentation, the 10,000 routes can be returned in multiple
rpc-reply. So I can see a portion of result rapidly.

What's your opinion?

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Dec 2005 07:10:27 -0800

李岩 wrote:

> Hi
>
> I think we need rpc-reply fragmentation when the result of get or
> get-config operation is very huge.
>
> Suppose I retrieve a route table which contains 10,000 routes. I have
> to wait for a long time until the device form a whole rpc-reply. If we
> allow rpc-reply fragmentation, the 10,000 routes can be returned in
> multiple rpc-reply. So I can see a portion of result rapidly.
>
> What's your opinion?
>

The WG discussed this many times in the past.
This is considered an implementation issue, since there are
ways to implement NETCONF in a stream-oriented fashion,
and there are ways for the manager to ask for subsets of data.

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>