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

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" <andy@yumaworks.com> wrote:

>
>
> 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
>>
>>
>