Subject: [Netconf] Fwd: Regarding complete device configuration sync to NMS

From: Shiva Kumar Pathori <[email-masked]>
Date: Thu, 3 Sep 2015 12:32:47 +0530

---------- Forwarded message ----------
From: "Shiva Kumar Pathori" <[email-masked]>
Date: 03-Sep-2015 12:29 pm
Subject: Regarding complete device configuration sync to NMS
To: <[email-masked]>
Cc:

Hi,
I would like to propose one method to get the complete configuration
through zip file to NMS. I feel this method will be effective instead of
<get> without any filter. Please advice.

Regards,
Shiva

---

From: Kent Watsen <[email-masked]>
Date: Thu, 3 Sep 2015 16:04:31 +0000

Hi Shiva,

> I would like to propose one method to get the complete configuration through zip file to NMS. I feel this method will be effective instead of <get> without any filter. Please advice.

Regards,
Shiva

---

From: Kent Watsen <[email-masked]>
Date: Thu, 3 Sep 2015 16:17:22 +0000

[hit the wrong button before]

Hi Shiva,

> I would like to propose one method to get the complete
> configuration through zip file to NMS. I feel this method will be
>effective instead of <get> without any filter. Please advice.

Like a <copy-config> with a parameter indicating compression.  Then, to
avoid the zip file being base64 encoded, another parameter indicate where
to put the file (tftp://, ftp://, etc.), or wait for the multiple-replies
draft to provide a better solution for bulk transfer.

In the meanwhile, a custom RPC could define this behavior immediately.

Cheers,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Sep 2015 18:40:08 +0200

> In the meanwhile, a custom RPC could define this behavior immediately.

If the goal to reduce bits on the wire, certain secure transports can
do compression transparently for you (and it then works for everything
exchanged in a session, not just a get without filters).

/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: Andy Bierman <[email-masked]>
Date: Thu, 3 Sep 2015 09:46:15 -0700

> exchanged in a session, not just a get without filters).
Yes, but it would be nice if NETCONF was not so "cache-unfriendly".
RESTCONF has Entity tags to help the client only retrieve data
when it has changed.  Pub/sub offers a way to push only the data
that has changed.  A "get without filters" should be a rare event
if the protocol is designed correctly.

> /js

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Sep 2015 19:10:49 +0200

> if the protocol is designed correctly.

I guess we agree that it is unclear why he asked the question, that is
which problem he is actually trying to solve.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Sep 2015 12:42:26 -0700

> which problem he is actually trying to solve.
Devices that are large enough to make this worthwhile generally
no not store the contents of <get> in memory in 1 process.
Building a giant response file then compressing it would not work.
Lossless compression that works on an arbitrary chunk of data at a time
would be OK.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 03 Sep 2015 21:50:33 +0200 (CEST)

> no not store the contents of <get> in memory in 1 process.

I think he meant <get-config>, but it doesn't matter for the
discussion.

> Lossless compression that works on an arbitrary chunk of data at a time

... which SSH provides already.

/martin

---

From: Shiva Kumar Pathori <[email-masked]>
Date: Fri, 4 Sep 2015 07:13:24 +0530

I mean the zip file in fact contains proper <rpc-reply> with multiple
files. Each file is of one complete XML document.
@Kent,
By the way, please share me some details about the multiple  reply draft. I
would like to work on it.
On 04-Sep-2015 1:20 am, "Martin Bjorklund" <[email-masked]> wrote:

Andy Bierman <[email-masked]> wrote:
> > > > > Like a <copy-config> with a parameter indicating compression.
Then,
> > to
> > > > > avoid the zip file being base64 encoded, another parameter
indicate
> > where

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 3 Sep 2015 19:10:46 -0700

> files. Each file is of one complete XML document.

The <rpc-reply> is an XML instance document.
Why would there be multiple "files" in response to 1 <get> or <get-config>?

I suggest you implement this and report the memory usage compared to
streaming
buffer-at-a-time with SSH, and also compare the number of bytes on the wire
for each approach.

BTW, do you intend this for config only (<get-config>) or all data (<get>)?

Andy

@Kent,
> By the way, please share me some details about the multiple  reply draft.
> I would like to work on it.

---

From: Shiva Kumar Pathori <[email-masked]>
Date: Fri, 4 Sep 2015 07:51:42 +0530

This method is similar to the draft
https://datatracker.ietf.org/doc/draft-liu-netconf-multiple-replies/?include_text=1.
Where as Client has to send multiple get-block RPC to get the complete
data. In this method all such replies will be put in multiple files and
zipped. This will reduce the RPC message interaction between client and
server.
On 04-Sep-2015 7:40 am, "Andy Bierman" <[email-masked]> wrote:

> buffer-at-a-time with SSH, and also compare the number of bytes on the
> wire for each approach.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Sep 2015 09:23:19 +0200

> buffer-at-a-time with SSH, and also compare the number of bytes on the wire

+1

/js

---

From: Shiva Kumar Pathori <[email-masked]>
Date: Sat, 5 Sep 2015 19:34:40 +0530

> buffer-at-a-time with SSH, and also compare the number of bytes on the
wire

+1

/js