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

On Thu, Sep 3, 2015 at 6:43 PM, Shiva Kumar Pathori <pathori@gmail.com>
wrote:

> I mean the zip file in fact contains proper <rpc-reply> with multiple
> 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.
> On 04-Sep-2015 1:20 am, "Martin Bjorklund" <mbj@tail-f.com> wrote:
>
> Andy Bierman <andy@yumaworks.com> wrote:
> > On Thu, Sep 3, 2015 at 10:10 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Thu, Sep 03, 2015 at 09:46:15AM -0700, Andy Bierman wrote:
> > > > On Thu, Sep 3, 2015 at 9:40 AM, Juergen Schoenwaelder <
> > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > > On Thu, Sep 03, 2015 at 04:17:22PM +0000, Kent Watsen wrote:
> > > > > > [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.
> > > > >
> > > > > 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).
> > > > >
> > > > >
> > > > 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.
> > > >
> > >
> > > I guess we agree that it is unclear why he asked the question, that is
> > > 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.
>
> I think he meant <get-config>, but it doesn't matter for the
> discussion.
>
> > 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.
>
> ... which SSH provides already.
>
>
> /martin
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>