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

[Shiva Kumar Pathori <[e-mail]>]

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" <[e-mail]> wrote:

Andy Bierman <[e-mail]> wrote:
> On Thu, Sep 3, 2015 at 10:10 AM, Juergen Schoenwaelder <
> [e-mail]> 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 <
> > > [e-mail]> 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