Subject: [Netconf] Solicit comments on inline action capability for NETCONF

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

Hi, Folks:
We have posted inline action capability draft on Jun 28:
https://www.ietf.org/mail-archive/web/netconf/current/msg14823.html

One comment we received from the list is:

https://www.ietf.org/mail-archive/web/netconf/current/msg14863.html

The v-(01) is uploaded to address this comment.
Therefore we would like to draw you attention again on this draft

https://tools.ietf.org/html/draft-zheng-netconf-inline-action-capability-01
We would like to receive more review and feedback on this draft, thanks.

-Qin

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 4 Jul 2018 02:51:39 +0000

Hi Wuqin / Walker,

Section 1

"However which
   data node is applied to which configuration datastore is not
   specified under "action".
"
RFC 8342 is clear that "action" is always invoked in the context of <operational> datastore.
Section 6.2:
"Actions are always invoked in the context of the operational state
   datastore.  The node for which the action is invoked MUST exist in
   the operational state datastore.
"

Is there any user scenario where config and action both MUST happen together ? If so, I feel the introduction can elaborate more on such scenario.

With Regards,
Rohit R Ranade

From: Netconf [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: 04 July 2018 07:32
To: [email-masked]
Subject: [Netconf] Solicit comments on inline action capability for NETCONF

Hi, Folks:

-Qin

---

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

Hi, Rohi:
发件人: Rohit R Ranade
发送时间: 2018年7月4日 10:52
收件人: Qin Wu; Zhengguangying (Walker)
抄送: [email-masked]
主题: RE: Solicit comments on inline action capability for NETCONF

Hi Wuqin / Walker,

Section 1

“However which
   data node is applied to which configuration datastore is not
   specified under "action".
”
RFC 8342 is clear that “action” is always invoked in the context of <operational> datastore.
Section 6.2:
“Actions are always invoked in the context of the operational state
   datastore.  The node for which the action is invoked MUST exist in
   the operational state datastore.
”
[Qin]: Good quotation, we are surprised the action defined in RFC7950 is restricted to being invoked only in operational state datastore,

Limit action to operational state datastore has benefit to avoid operation conflict on the same conceptual node in the underlying

 data model. but see more useful to invoke action on configuration datastore as well, e.g.,<running>.

[Qin]:Yes, invoking action on configuration datastore is our key use cases,e.g., batch operation on 100 interfaces and enable Interface statistics and
Then set MTU value to a specific interface. Enable interface statistics on 100 interfaces will happen first and then MTU value setup.
These operations have no conflict risk and can execute in any order in one transaction, it will be great to introduce this multi-sub operations in one transaction.

In Some other cases when action is invoked in operational state datastore, we can use <operational> to get learned configuration and translate them into static configuration.

With Regards,
Rohit R Ranade

From: Netconf [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: 04 July 2018 07:32
To: [email-masked]<mailto:[email-masked]>
Subject: [Netconf] Solicit comments on inline action capability for NETCONF

Hi, Folks:

-Qin

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 4 Jul 2018 06:01:02 +0000

[Qin]:Yes, invoking action on configuration datastore is our key use cases,e.g., batch operation on 100 interfaces and enable Interface statistics and
Then set MTU value to a specific interface. Enable interface statistics on 100 interfaces will happen first and then MTU value setup.
These operations have no conflict risk and can execute in any order in one transaction, it will be great to introduce this multi-sub operations in one transaction.
[Rohit R Ranade] But why must this happen in single transaction ? If done as two separate RPC what is the impact ?

In Some other cases when action is invoked in operational state datastore, we can use <operational> to get learned configuration and translate them into static configuration.
[Rohit R Ranade] We can still do this. We can get learned configuration from <operational>, and if need to translate to static we can always create such configuration in <running>

With Regards,
Rohit R Ranade

Hi, Folks:

-Qin

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Jul 2018 06:18:31 +0000

发件人: Rohit R Ranade
发送时间: 2018年7月4日 14:01
收件人: Qin Wu
抄送: [email-masked]; Zhengguangying (Walker)
主题: RE: Solicit comments on inline action capability for NETCONF

[Qin]: Improve transaction efficiency is one of important motivations. Separate action from <edit-config> operation, you still need to handle action that is part of <config> element within
<edit-config> operation.

[Qin]:Have we already had standard mechanism to translate learned into static? I see none.

With Regards,
Rohit R Ranade

Hi, Folks:

-Qin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 6 Jul 2018 14:37:57 +0000

Hi Qin
Hi Walker,

From: Qin Wu, July 4, 2018 2:19 AM

发件人: Rohit R Ranade
发送时间: 2018年7月4日 14:01
收件人: Qin Wu
抄送: [email-masked]<mailto:[email-masked]>; Zhengguangying (Walker)
主题: RE: Solicit comments on inline action capability for NETCONF

<Eric> Interesting thread.   Two questions:

(1) With multiple transactions in one, I initially read this as you might want to support the edit config failing if the action fails (i.e., an error coming result from the action on the operational datastore).  And the result is that the aggregate transaction would fail across datastores.

Now looking at your responses on this thread, it looks like that your use case is non-interdependent configuration actions.  Based on that, which of the following do you want to considering in scope?  And if only (a), you should likely add more to the scope statement.

(a) single datastore edit and actions, where each atomic edit will complete or fail independently
(b) single datastore edit and actions, where the full operation fails if any component fails
(c) cross datastore edit and actions, where the full operation fails if any component fails

(2) Do you see any cases where the action operation must occur after the edit config?  I.e., the action depends on a successful edit config happening first.

Thanks,
Eric

With Regards,
Rohit R Ranade

Hi, Folks:

-Qin

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jul 2018 01:00:48 +0000

Thanks Eric for valuable comments, see reply inline.

-Qin
发件人: Eric Voit (evoit) [mailto:[email-masked]]
发送时间: 2018年7月6日 22:38
收件人: Qin Wu; Zhengguangying (Walker)
抄送: [email-masked]; Rohit R Ranade; Aijun Wang
主题: RE: Solicit comments on inline action capability for NETCONF

Hi Qin
Hi Walker,

[Qin]: It depends error-options we select, I think we may support either (a) or (b). The error options are defined in section 7.2 of RFC6241.
(c) cross datastore edit and actions, where the full operation fails if any component fails

(2) Do you see any cases where the action operation must occur after the edit config?  I.e., the action depends on a successful edit config happening first.
[Qin]: Good question, before NMDA is introduced, we support converting learned configuration into static configuration, static configuration can be injected into <running> through <edit-config>,
In this case, we can use action to do such conversion and then use <edit-config> to edit the content into <running>.

Thanks,
Eric

With Regards,
Rohit R Ranade

Hi, Folks:

-Qin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 17 Jul 2018 08:08:47 -0400

Hi Qin,

Having read this draft, I can understand what the draft is proposing, 
but I don't currently understand why this is useful. Specifically, I 
don't find the example that is in the draft as compelling.  If the 
desire is to set the MTU and enable the interface as one configuration 
operation, then wouldn't the client just configure both mtu and enabled 
leaves at the same time.  Why is a separate action required here to 
enable the interface?

So I'm struggling to think of actions that apply to configuration 
datastores where the same behaviour cannot just be achieved via a simple 
configuration manipulation.  One use case could be wanting to repeat the 
same configuration on many interfaces at the same time, but for this, I 
think that a configuration templating solution would be preferable 
rather than using actions, and a templating would probably just reused 
edit-config/edit-data.  So, if you have some other more concrete 
examples of actions that apply to configuration datastores, that might 
be helpful.

Another question (which I think is similar to the one that Eric has also 
asked) is whether to have transactions that mix configuration operations 
and action operations on <operational>.  E.g. perhaps enable an 
interface and reset the counters at the same time, or perform some 
config change and establish a dynamic subscription at the same time.  
But I question how robust this would end up being (I'm not generally a 
fan of distributed transactions - they never seem to be as robust as 
they claim to be).  Perhaps one for future thought and discussion.

Thanks,
Rob

On 03/07/2018 22:01, Qin Wu wrote:
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Jul 2018 15:25:28 +0200

On Tue, Jul 17, 2018 at 08:08:47AM -0400, Robert Wilton wrote:
> Hi Qin,
> 
> Having read this draft, I can understand what the draft is proposing, but I
> don't currently understand why this is useful. Specifically, I don't find
> the example that is in the draft as compelling.  If the desire is to set the
> MTU and enable the interface as one configuration operation, then wouldn't
> the client just configure both mtu and enabled leaves at the same time.  Why
> is a separate action required here to enable the interface?
>

I have asked myself the same question multiple times. ;-)

If people want engineer transactions consisting of multiple
operations, then they should do this for combinations of _arbitrary_
operations. At the end, edit-config is just an operation like
edit-data or any other operation.

Personally, I do not think heavy weight transactions is the way to go
but if people want to engineer this, please make the solution at least
generic and not bound to edit-config or something like that.

/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: Robert Wilton <[email-masked]>
Date: Tue, 17 Jul 2018 10:12:48 -0400

> edit-data or any other operation.
I agree.

> generic and not bound to edit-config or something like that.
I also agree to both points.

Thanks,
Rob