Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

From: Qin Wu <[email-masked]>
Date: Mon, 2 Jul 2018 12:16:27 +0000

Good point and suggestion. Here is my thought:
In case :startup capability is supported, the factory datastore can be copied into <startup>, restart is not needed since we have loaded content of factory datastore into startup. Startup will be updated with running each time the running is altered. In case of system fatal error, we will consider copy factgory datatore into <startup> again for restore.
In case the restart is needed or device power on is needed, the factory datastore as source may not be set, instead, URL is set as source, the content of source identified by URL can be loaded into target datastore during restart or device repower on. In this case, the proposed factory datastore
and new operation can work together with zero touch bootstrapping procedure proposed in draft-ietf-netconf-zerotouch.

In case :writable-running capability is supported, the factory datastore can be directly copied into <running>, in case of multiple conceptual flows, we can consider to copy one factory datastore into multiple <running> targets.
In case :candidate capability is supported, the factory datastore can be first copied into <candiate> and then the <candidate> is committed into <running>, in this case, startup is not touched.

-Qin
-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2018年6月30日 17:08
收件人: Qin Wu
抄送: Kent Watsen; Ladislav Lhotka; [email-masked]
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

On Sat, Jun 30, 2018 at 07:05:23AM +0000, Qin Wu wrote:

> One point to add, we hope to support factory restore without 
> reboot/restart and support factory restore with reboot, two cases, 
> this make factory restore can be supported in the whole lifetime of 
> the device.

So is the <factory> datastore conceptually copied into <startup> and then you restart or is the the <factory> datastore conceptually copied into <running>? Yes, <startup> is not mandatory to have, so there may be multiple conceptual flows that are possible. I think it will be helpful to be clear about the conceptual dataflow between the datastores - and once this is clear, it should be relatively easy to define the operations that are necessary.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jul 2018 14:22:54 +0200

> In case :startup capability is supported, the factory datastore can be copied into <startup>, restart is not needed since we have loaded content of factory datastore into startup. Startup will be u…

I doubt this will work. If you copy <factory> to startup> and
subsequently <running> to <startup>, there is a copy of <running> left
in <startup>, i.e., the copy of <factory> to startup> had no effect.

> and new operation can work together with zero touch bootstrapping procedure proposed in draft-ietf-netconf-zerotouch.

URLs are an optional capability so far and I do not know what "URL is
set as source" means to me. What is target datastore here? I am not
sure how data flows.

> In case :candidate capability is supported, the factory datastore can be first copied into <candiate> and then the <candidate> is committed into <running>, in this case, startup is not touched.

What are multiple <running> targets? What are "multiple conceptual flows"?
I am confused.

/js

---

From: Qin Wu <[email-masked]>
Date: Mon, 2 Jul 2018 13:56:54 +0000

发件人： Juergen Schoenwaelder
收件人： Qin Wu<[email-masked]<mailto:[email-masked]>>
抄送： Kent Watsen<[email-masked]<mailto:[email-masked]>>;Ladislav Lhotka<[email-masked]<mailto:[email-masked]>>;netconf<[email-masked]<mailto:[email-masked]>>
主题： Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt
时间： 2018-07-02 20:23:06

I doubt this will work. If you copy <factory> to startup> and
subsequently <running> to <startup>, there is a copy of <running> left
in <startup>, i.e., the copy of <factory> to startup> had no effect.
[Qin] To address this issue, we can introduce multiple target data sores in the new operation factory restore operation, copy factory datastore to startup and running in one operation, the source will be set to the same factory datastore.

URLs are an optional capability so far and I do not know what "URL is
set as source" means to me. What is target datastore here? I am not
sure how data flows.
[Qin] see device power on procedure defined in zero touch netconf WG draft, factory restore scheme, in my opinion can be integrated into it. The target datastore(s) can be set to any datasore(s) you want to return factory default.

What are multiple <running> targets? What are "multiple conceptual flows"?
I am confused.
[Qin] see above, in the above cases,multiple datasores can be set to <startup> and <running> And all other datastore that need to set to factory default. That means in the new operation, multiple target list can be included. If multiple factory defaults are allowed,multiple sources can be included as well.

Not sure multiple target running case exists,if we can copy one source to multiple instances distributed in multiple logical network elements, that will be great.
/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jul 2018 16:01:56 +0200

I suggest to try to make the proposal simpler, not more complex.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Jul 2018 09:08:51 -0700

> I suggest to try to make the proposal simpler, not more complex.

+1

IMO the only thing needed is 1 simple identity named "factory".
Existing protocol operations can be used (e.g, copy-config from factory to
running)

/js

Andy

> > 抄送： Kent Watsen<[email-masked]<mailto:[email-masked]>>;Ladislav
> Lhotka<[email-masked]<mailto:[email-masked]>>;netconf<[email-masked]
> <mailto:[email-masked]>>
> > > In case :startup capability is supported, the factory datastore can be
> copied into <startup>, restart is not needed since we have loaded content
> of factory datastore into startup. Startup will be updated with running
> each time the running is altered. In case of system fatal error, we will
> consider copy factgory datatore into <startup> again for restore.
> >
> > [Qin] To address this issue, we can introduce multiple target data sores
> in the new operation factory restore operation, copy factory datastore to
> startup and running in one operation, the source will be set to the same
> factory datastore.
> >
> > > In case the restart is needed or device power on is needed, the
> factory datastore as source may not be set, instead, URL is set as source,
> the content of source identified by URL can be loaded into target datastore
> during restart or device repower on. In this case, the proposed factory
> datastore
> > > and new operation can work together with zero touch bootstrapping
> procedure proposed in draft-ietf-netconf-zerotouch.
> >
> > [Qin] see device power on procedure defined in zero touch netconf WG
> draft, factory restore scheme, in my opinion can be integrated into it. The
> target datastore(s) can be set to any datasore(s) you want to return
> factory default.
> >
> > > In case :writable-running capability is supported, the factory
> datastore can be directly copied into <running>, in case of multiple
> conceptual flows, we can consider to copy one factory datastore into
> multiple <running> targets.
> > > In case :candidate capability is supported, the factory datastore can
> be first copied into <candiate> and then the <candidate> is committed into
> <running>, in this case, startup is not touched.
> >
> > [Qin] see above, in the above cases,multiple datasores can be set to
> <startup> and <running> And all other datastore that need to set to factory
> default. That means in the new operation, multiple target list can be
> included. If multiple factory defaults are allowed,multiple sources can be
> included as well.
> >
> > Not sure multiple target running case exists,if we can copy one source
> to multiple instances distributed in multiple logical network elements,
> that will be great.
> > /js
> >
> > --
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 2 Jul 2018 17:23:03 +0100

On 02/07/2018 17:08, Andy Bierman wrote:
>
>
> On Mon, Jul 2, 2018 at 7:01 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
Yes, I basically agree.

In addition, when a device boots then <startup> is initialized to 
<factory> if it doesn't exist.  Or alternatively, <running> is 
initialized to <factory> if <startup> doesn't exist.
A client can use an RPC to copy <factory> to <startup> or to <running> 
if they want, but then can never write to <factory> (although factory 
could change via a software update).

> Existing protocol operations can be used (e.g, copy-config from 
> factory to running).
Now RESTCONF is datastore aware, it looks like we need to add a 
"copy-config" RPC (or should it just be "copy"?) to RESTCONF to allow 
the contents of one datastore to be copied to another datastore.  Such 
an RPC should be entirely generic and not tied to the factory datastore 
in anyway.  Possibly, related to this, it might be worth considering if 
there are any other operations in NETCONF that should be supported in 
RESTCONF and to do that as a single update to the protocol rather than 
lots of piecemeal extensions.

Thanks,
Rob

>     > 收件人： Qin Wu<[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     > 抄送： Kent Watsen<[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>>;Ladislav Lhotka<[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>>;netconf<[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     > 主题： Re: [Netconf] I-D Action:
>     draft-wu-netconf-restconf-factory-restore-00.txt
>     > 时间： 2018-07-02 20:23:06
>     >
>     > > In case :startup capability is supported, the factory
>     datastore can be copied into <startup>, restart is not needed
>     since we have loaded content of factory datastore into startup.
>     Startup will be updated with running each time the running is
>     altered. In case of system fatal error, we will consider copy
>     factgory datatore into <startup> again for restore.
>     >
>     > [Qin] To address this issue, we can introduce multiple target
>     data sores in the new operation factory restore operation, copy
>     factory datastore to startup and running in one operation, the
>     source will be set to the same factory datastore.
>     >
>     > > In case the restart is needed or device power on is needed,
>     the factory datastore as source may not be set, instead, URL is
>     set as source, the content of source identified by URL can be
>     loaded into target datastore during restart or device repower on.
>     In this case, the proposed factory datastore
>     > > and new operation can work together with zero touch
>     bootstrapping procedure proposed in draft-ietf-netconf-zerotouch.
>     >
>     > [Qin] see device power on procedure defined in zero touch
>     netconf WG draft, factory restore scheme, in my opinion can be
>     integrated into it. The target datastore(s) can be set to any
>     datasore(s) you want to return factory default.
>     >
>     datastore can be directly copied into <running>, in case of
>     multiple conceptual flows, we can consider to copy one factory
>     datastore into multiple <running> targets.
>     > > In case :candidate capability is supported, the factory
>     datastore can be first copied into <candiate> and then the
>     <candidate> is committed into <running>, in this case, startup is
>     not touched.
>     >
>     > [Qin] see above, in the above cases,multiple datasores can be
>     set to <startup> and <running> And all other datastore that need
>     to set to factory default. That means in the new operation,
>     multiple target list can be included. If multiple factory defaults
>     are allowed,multiple sources can be included as well.
>     >
>     > Not sure multiple target running case exists,if we can copy one
>     source to multiple instances distributed in multiple logical
>     network elements, that will be great.
>     > /js
>     > 
>     > --
>     > Fax: +49 421 200 3103 <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
>
>     -- 
>     Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netconf>
>
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Jul 2018 10:09:18 -0700

On Mon, Jul 2, 2018 at 9:23 AM, Robert Wilton <[email-masked]> wrote:

> <factory> if it doesn't exist.  Or alternatively, <running> is initialized
> to <factory> if <startup> doesn't exist.
> A client can use an RPC to copy <factory> to <startup> or to <running> if
> they want, but then can never write to <factory> (although factory could
> change via a software update).
>
>
Yes, factory is a read-only datastore.
I suppose the boot-time setup of the conventional dataastores could be
standardized.

> running).
> "copy-config" RPC (or should it just be "copy"?) to RESTCONF to allow the
> contents of one datastore to be copied to another datastore.  Such an RPC
> should be entirely generic and not tied to the factory datastore in
> anyway.  Possibly, related to this, it might be worth considering if there
> are any other operations in NETCONF that should be supported in RESTCONF
> and to do that as a single update to the protocol rather than lots of
> piecemeal extensions.
>
>

RESTCONF has access to all RPC operations so
/restconf/operations/ietf-netconf:copy-config
is already supported.

Andy

>> > > In case :startup capability is supported, the factory datastore can
>> be copied into <startup>, restart is not needed since we have loaded
>> content of factory datastore into startup. Startup will be updated with
>> running each time the running is altered. In case of system fatal error, we
>> will consider copy factgory datatore into <startup> again for restore.
>> >
>> > [Qin] To address this issue, we can introduce multiple target data
>> sores in the new operation factory restore operation, copy factory
>> datastore to startup and running in one operation, the source will be set
>> to the same factory datastore.
>> >
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Jul 2018 01:36:33 +0000

发件人: Robert Wilton [mailto:[email-masked]]
发送时间: 2018年7月3日 0:23
收件人: Andy Bierman; Juergen Schoenwaelder; Qin Wu; Kent Watsen; Ladislav Lhotka; netconf
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

On Mon, Jul 2, 2018 at 7:01 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
I suggest to try to make the proposal simpler, not more complex.
+1

In addition, when a device boots then <startup> is initialized to <factory> if it doesn't exist.  Or alternatively, <running> is initialized to <factory> if <startup> doesn't exist.
A client can use an RPC to copy <factory> to <startup> or to <running> if they want, but then can never write to <factory> (although factory could change via a software update).

[Qin]: Good summary, this is exactly what we like to propose.

Existing protocol operations can be used (e.g, copy-config from factory to running).
Now RESTCONF is datastore aware, it looks like we need to add a "copy-config" RPC (or should it just be "copy"?) to RESTCONF to allow the contents of one datastore to be copied to another datastore.  Such an RPC should be entirely generic and not tied to the factory datastore in anyway.

[Qin]: Yes, one of our thoughts is to define a generic operation, e.g., copy-datastore, delete-datastore, maybe compare-datastore, all these operations are datastore level instead of data node level.

Possibly, related to this, it might be worth considering if there are any other operations in NETCONF that should be supported in RESTCONF and to do that as a single update to the protocol rather than lots of piecemeal extensions.

Thanks,
Rob

/js

Andy

On Mon, Jul 02, 2018 at 01:56:54PM +0000, Qin Wu wrote:
> 收件人： Qin Wu<[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> 抄送： Kent Watsen<[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;Ladislav Lhotka<[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;netconf<[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>

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

Netconf mailing list

[email-masked]<mailto:[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Jul 2018 02:04:04 +0000

发件人: Andy Bierman [mailto:[email-masked]]
发送时间: 2018年7月3日 1:09
收件人: Robert Wilton
抄送: Juergen Schoenwaelder; Qin Wu; Kent Watsen; Ladislav Lhotka; netconf
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

On Mon, Jul 2, 2018 at 9:23 AM, Robert Wilton <[email-masked]<mailto:[email-masked]>> wrote:

+1

Yes, factory is a read-only datastore.
I suppose the boot-time setup of the conventional dataastores could be standardized.

[Qin]: Yes, we see most of contributors agree to document this feature.
Existing protocol operations can be used (e.g, copy-config from factory to running).
Now RESTCONF is datastore aware, it looks like we need to add a "copy-config" RPC (or should it just be "copy"?) to RESTCONF to allow the contents of one datastore to be copied to another datastore.  Such an RPC should be entirely generic and not tied to the factory datastore in anyway.  Possibly, related to this, it might be worth considering if there are any other operations in NETCONF that should be supported in RESTCONF and to do that as a single update to the protocol rather than lots of piecemeal extensions.

RESTCONF has access to all RPC operations so /restconf/operations/ietf-netconf:copy-config
is already supported.

[Qin]:What about RESTCONF is implemented in a device that doesn’t have NETCONF server support.
We see NETCONF is well specified on copying one datatore into another datastore using copy-config.
But in RFC8040,we didn’t see HTTP PUT method is well specified to support copying one datastore into another datastore,

Thanks,
Rob

Andy

/js

Andy

Netconf mailing list

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Jul 2018 02:05:30 +0000

Okay, thanks for your good suggestion.
-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2018年7月2日 22:02
收件人: Qin Wu
抄送: Kent Watsen; Ladislav Lhotka; netconf
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

/js

On Mon, Jul 02, 2018 at 01:56:54PM +0000, Qin Wu wrote:
> 抄送： Kent 
> Watsen<[email-masked]<mailto:[email-masked]>>;Ladislav 
> Lhotka<[email-masked]<mailto:[email-masked]>>;netconf<[email-masked]<m
> ailto:[email-masked]>>
> > factory datastore as source may not be set, instead, URL is set as source, the content of source identified by URL can be loaded into target datastore during restart or device repower on. In this case, the proposed factory datastore and new operation can work together with zero touch bootstrapping procedure proposed in draft-ietf-netconf-zerotouch.
>

---

From: Rohit R Ranade <[email-masked]>
Date: Tue, 3 Jul 2018 03:22:29 +0000

[Rohit R Ranade] +1

[Rohit R Ranade] +1 .

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 3 Jul 2018 13:22:10 +0200

ietf-system:system-restart

Is this what you have been thinking about?
Balazs

On 6/29/2018 7:43 PM, Kent Watsen wrote:
> sufficient.   I'm unsure which published RFC defines the "reboot"
> RPC, it's possible that none do.
>
> Kent // contributor

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Jul 2018 13:05:10 +0000

Thanks Balazs.
I think the exising NC/RC operation doesn't define a parameter to trigger reboot or system-restart, would it be great to define a generic datatore copy operation to indicate when or whether restart is needed?
Separating datastore copy operation from reboot means we should define how reboot works together with NC/RC operations or new operation to fulfill factory restore.
e.g.,Reboot or system-restart might be needed or not needed. The reboot or system-restart might happen before or after the datastore(s) are initialized into <factory>,etc.

-Qin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 3 Jul 2018 15:48:15 +0200

Could you please clarify the definition of reboot and system-restart? 
What is the difference?

So are you looking for a combined copy-config+system-restart operation?

regards Balazs

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Jul 2018 02:43:42 +0000

Good comment, Balazs, 
I am not sure reboot and system-restart are the same thing.
In some cases, they are equivalent.
But in some other cases, they seems different, reboot may need to load software boot image. Reboot need to record boot-date-time.
System-restart may need to inform the client about system-restart event. System-restart seems
to mean restart the whole system (not just NETCONF-sever)

In addition, we may have restart operation, restart and reboot are almost same, both means restart the device, in my understanding.

Regarding combined copy-config+system-restart, or copy-config+reboot, I think in some case, we don't need restart or reboot.
In some case, we need. But Existing copy-config may have limitation,e.g., can not be applied to the case where the RESTCONF is implemented in a device that doesn't have NETCONF support.
-----邮件原件-----
发件人: Balazs Lengyel [mailto:[email-masked]] 
发送时间: 2018年7月3日 21:48
收件人: Qin Wu; Kent Watsen; Ladislav Lhotka; [email-masked]
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt

regards Balazs

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sun, 15 Jul 2018 13:59:19 +0000

Hi,

The new “factory” datastore can be used for NETCONF also so a corresponding NETCONF draft should be updated to support this functionality?

BTW the security considerations section refers to NETCONF instead of RESTCONF.

Regards,
Reshad.

From: Netconf <[email-masked]> on behalf of Rohit R Ranade <[email-masked]>
Date: Monday, July 2, 2018 at 11:23 PM
To: Qin Wu <[email-masked]>
Cc: netconf <[email-masked]>
Subject: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-00.txt