Subject: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

From: Xufeng Liu <[email-masked]>
Date: Wed, 1 Nov 2017 19:30:37 +0000

Dear WG,

The Yang-push Dezign Team has been working on the Yang push enhancement. We have posted a draft on the problem statement to extend Yang push to a more generalized network control automation framework.

The following is the summary of this topic. Any comments, thoughts, and suggestions are appreciated.

Thanks,
- Xufeng

================
YANG PUSH Based Generalized Network Control Automation 
draft-bryskin-netconf-automation-framework-00

Evolution of YANG Based Network Automation
* "Custom Subscription to Event Notifications" model :
	- allows for a client to subscribe to unsolicited event notifications  defined by supported YANG models;

* "Subscribing to YANG datastore push updates" model:
	- allows for a client to define subscribable events and contents of event notifications as target-trigger-notify triplets

* "Smart filters for Push Updates" model:
	- allows for a client to filter event triggers and notifications on push object values and their change history, focuses on "outliers"

Objectives of  YANG PUSH Based Generalized Network Control Automation  
1) To generalize target-trigger-notify concept into event-condition-action concept, where:

	event - a particular change in the network state explicitly defined by one of the YANG models supported by the network or implicitly defined by the client, which is constantly monitored by the network;

	condition - a logical expression that is evaluated only once after the associated event is detected;

	action - an operation to be carried out by the network when the associated event is detected and the associated condition is met

2) To provide for a client a capability to configure the event-condition-action triplets as policy rules ahead of time or/and during network operations

Generalized Action
* Send notification
* Perform immediate network reconfiguration (e.g. modify one or more attributes of one or more CONFIG=TRUE data store nodes);
* Schedule one time or periodic reconfiguration in the future;
* Call RPC defined by one of the YANG models supported by the network ( e.g. call network's path computer to evaluate whether an alternative/more optimal path is available for a given connection)
* Link/unlink data store dynamic sub-trees;
* Etc.

Relationship with Policy Framework
* The framework should work autonomously

* The framework should fit well within a higher level policy framework, with the latter possibly providing a greater level of automation:
  - multiple micro-conditions could be combined into a single macro-condition via a number of logical operations;
  - multiple micro-actions could be combined into a single transaction with a possibility of specifying policies with respect to handling errors/exceptions of each of the transaction components

Framework Benefits
* lower latency, faster responsiveness of the network to various events/conditions;
* better scale (e.g. the client may control more networks because it does not have to monitor/micro-manage any of them);
* CPU and bandwidth savings due to the reduced amount of communication between the client and the network
* The client can take itself out of the network control loop,  change its role from being network's "micro-manager" to being network's "police officer", who interferes into network operations only in exceptional/unpredicted situations

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 2 Nov 2017 03:30:53 +0000

Hi Xufeng,

On the smart filters (also relates to https://tools.ietf.org/html/draft-clemm-netconf-push-smart-filters-ps-00), I think we need criteria to carefully select "conditions". While there are many benefit, say save the bandwidth and relief the collector, it will add computation burden to network devices. Network devices are not good at this as servers.
So maybe:
1. should not too complex to implement.
2. must help to mitigate the export volume.

If so, for example, the average value should be out of scope, IMHO.

Best,
Tianran

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Xufeng Liu
> Sent: Thursday, November 02, 2017 3:31 AM
> To: [email-masked]
> Subject: [Netconf] YANG PUSH Based Generalized Network Control Automation
> Problem Statement
> 
> Dear WG,
> 
> The Yang-push Dezign Team has been working on the Yang push enhancement.
> We have posted a draft on the problem statement to extend Yang push to a
> more generalized network control automation framework.
> 
> 	- allows for a client to define subscribable events and contents of event
> notifications as target-trigger-notify triplets
> 
> 	- allows for a client to filter event triggers and notifications on push
> object values and their change history, focuses on "outliers"
> 
> 	event - a particular change in the network state explicitly defined by
> one of the YANG models supported by the network or implicitly defined by
> the client, which is constantly monitored by the network;
> 
> 	action - an operation to be carried out by the network when the associated
> event is detected and the associated condition is met
> 
> 2) To provide for a client a capability to configure the
> event-condition-action triplets as policy rules ahead of time or/and during
> network operations
> 
> Generalized Action
> * Send notification
> * Perform immediate network reconfiguration (e.g. modify one or more
> attributes of one or more CONFIG=TRUE data store nodes);
> * Call RPC defined by one of the YANG models supported by the network ( e.g.
> call network's path computer to evaluate whether an alternative/more optimal
> path is available for a given connection)
> * The framework should fit well within a higher level policy framework,
> with the latter possibly providing a greater level of automation:
>   - multiple micro-conditions could be combined into a single
> macro-condition via a number of logical operations;
>   - multiple micro-actions could be combined into a single transaction with
> a possibility of specifying policies with respect to handling
> errors/exceptions of each of the transaction components
> 
> Framework Benefits
> * better scale (e.g. the client may control more networks because it does
> not have to monitor/micro-manage any of them);
> * The client can take itself out of the network control loop,  change its
> role from being network's "micro-manager" to being network's "police
> officer", who interferes into network operations only in
> exceptional/unpredicted situations
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 2 Nov 2017 16:53:55 +0000

Hi Tianran,

Thanks for your comments.

Please, note that we see smart filters as a significant step from current push machinery in evolution of network control automation, because it empowers the client to instruct the network to identify and focus on "outliers", rather than on routine changes in the network State. I agree, this will impose more complexity on the network, but the benefits are obvious. For example, instead of receiving tons of largely useless information, 99% of which to be discarded after the processing, the client will be able to receive only "interesting" information WRT actionable events. The network control automation framework intends to make one step further in this evolution. We are basically asking "Why sending notifications is the only action that could be triggered by model defined events and/or push subscriptions and/or smart filters"? Why, for example, pre-defined network re-configurations could not be triggered by smart filters? Why it is not possible for the client to pre-configure desired actions ahead of time?"  

Think about a battleship that just has been torpedoed. The crew members are not expected to just identify holes/leaks in the ship's bottom, report the "telemetry" to the captain and wait for instructions on what to do next, right? Each crew member not only knows his/her pre-defined actions, (s)he is meticulously trained on a daily basis on how to carry out them in the most efficient way. This is how ships survive problems like that. Also this is how the same authority can control big and multiple ships.

Cheers,
Igor    

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Wednesday, November 01, 2017 11:31 PM
To: Xufeng Liu; [email-masked]
Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi Xufeng,

Best,
Tianran

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Nov 2017 10:14:53 -0700

On Thu, Nov 2, 2017 at 9:53 AM, Igor Bryskin <[email-masked]>
wrote:

> Please, note that we see smart filters as a significant step from current
> push machinery in evolution of network control automation, because it
> empowers the client to instruct the network to identify and focus on
> "outliers", rather than on routine changes in the network State. I agree,
> this will impose more complexity on the network, but the benefits are
> obvious. For example, instead of receiving tons of largely useless
> information, 99% of which to be discarded after the processing, the client
> will be able to receive only "interesting" information WRT actionable
> events. The network control automation framework intends to make one step
> further in this evolution. We are basically asking "Why sending
> notifications is the only action that could be triggered by model defined
> events and/or push subscriptions and/or smart filters"? Why, for example,
> pre-defined network re-configurations could not be triggered by smart
> filters? Why it is not possible for the client to pre-configure desired a
>  ctions ahead of time?"
>
> Think about a battleship that just has been torpedoed. The crew members
> are not expected to just identify holes/leaks in the ship's bottom, report
> the "telemetry" to the captain and wait for instructions on what to do
> next, right? Each crew member not only knows his/her pre-defined actions,
> (s)he is meticulously trained on a daily basis on how to carry out them in
> the most efficient way. This is how ships survive problems like that. Also
> this is how the same authority can control big and multiple ships.
>
>

This issue has come up in the IETF many times.
The general problem is how to execute application business logic on the
server
in order to eliminate a relatively lengthy control loop.

We have a Script MIB (RFC 3165) that was never useful because there was no
standard script execution environment.

There was a tightly controlled environment called the Policy Based
Management MIB (RFC 4011)
that nobody implemented (for various reasons).

IMO YANG XPath does a good job of providing all the components required to
evaluate a boolean expression, which is important but insufficient.
A full-blown script engine with various library functions might be over-kill
or it might be the only real-world solution path.

Cheers,
> Igor

Andy

> On the smart filters (also relates to https://tools.ietf.org/html/
> draft-clemm-netconf-push-smart-filters-ps-00), I think we need criteria
> to carefully select "conditions". While there are many benefit, say save
> the bandwidth and relief the collector, it will add computation burden to
> network devices. Network devices are not good at this as servers.
> So maybe:
> >       - allows for a client to subscribe to unsolicited event
> notifications
> > defined by supported YANG models;
> >
> > 1) To generalize target-trigger-notify concept into
> event-condition-action
> > concept, where:
> >
> >       condition - a logical expression that is evaluated only once after
> the
> > associated event is detected;
> >
> > * CPU and bandwidth savings due to the reduced amount of communication
> between
> > the client and the network

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 2 Nov 2017 17:38:49 +0000

Hi Andy,

We assume that a network could be controlled via a set of YANG data stores. This is a powerful environments that we never had in the past. The YANG model we have in mind will allow for configuring scripts you mentioned as sets of event-condition-action (ECA) triplets. Smart filters will take care of event-condition part. We will focus on YANG based action generalization.

Igor

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, November 02, 2017 1:15 PM
To: Igor Bryskin
Cc: Tianran Zhou; Xufeng Liu; [email-masked]
Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

On Thu, Nov 2, 2017 at 9:53 AM, Igor Bryskin <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tianran,

Please, note that we see smart filters as a significant step from current push machinery in evolution of network control automation, because it empowers the client to instruct the network to identify and focus on "outliers", rather than on routine changes in the network State. I agree, this will impose more complexity on the network, but the benefits are obvious. For example, instead of receiving tons of largely useless information, 99% of which to be discarded after the processing, the client will be able to receive only "interesting" information WRT actionable events. The network control automation framework intends to make one step further in this evolution. We are basically asking "Why sending notifications is the only action that could be triggered by model defined events and/or push subscriptions and/or smart filters"? Why, for example, pre-defined network re-configurations could not be triggered by smart filters? Why it is not possible for the client to pre-configure desired a
 ctions ahead of time?"

This issue has come up in the IETF many times.
The general problem is how to execute application business logic on the server
in order to eliminate a relatively lengthy control loop.

There was a tightly controlled environment called the Policy Based Management MIB (RFC 4011)
that nobody implemented (for various reasons).

Cheers,
Igor

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tianran Zhou
Sent: Wednesday, November 01, 2017 11:31 PM
To: Xufeng Liu; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi Xufeng,

Best,
Tianran

> From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xufeng Liu
> To: [email-masked]<mailto:[email-masked]>
> [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]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 2 Nov 2017 17:59:48 +0000

Hi,

Clearly there is a case to be made for the ability of simple automation / closed control loops on the server.  

Just a few comments regarding the role of YANG Push smart filters in this, and where I view the boundary between them:

- A smart filter allows to send updates only when certain filter conditions regarding its values are met, possibly involving state.  Example: A threshold has been crossed, a high-water mark has been breached.  These updates clearly constitute "events" that can feed into an event/condition/action rule.  
- That said, the focus on smart filters is to be smart-yet-simple, applying 90/10 rule.  It is not the intention to make this assume the role of a general "Event + Expression MIB".   For examples, events that would require cross-correlation comparing values across data items, processing entire lists, computing aggregates over time, etc, would be outside the scope.   
- The assessment of any conditions would be left for the automation framework.  In other words, a smart filter will just assess the update itself against a smart filter.  It will not make additional checks with regards to other data or take other actions as a result of the filter before sending an event.  That would be precisely left for the automation stages.  There is a reason that it's "event-condition-action", not simply "trigger-action".     

--- Alex

> From: Netconf [mailto:[email-masked]] On Behalf Of Igor Bryskin
> Sent: Thursday, November 02, 2017 9:54 AM
> To: Tianran Zhou <[email-masked]>; Xufeng Liu
> <[email-masked]>; [email-masked]
> Please, note that we see smart filters as a significant step from current push
> machinery in evolution of network control automation, because it empowers
> the client to instruct the network to identify and focus on "outliers", rather
> than on routine changes in the network State. I agree, this will impose more
> complexity on the network, but the benefits are obvious. For example,
> instead of receiving tons of largely useless information, 99% of which to be
> discarded after the processing, the client will be able to receive only
> "interesting" information WRT actionable events. The network control
> automation framework intends to make one step further in this evolution.
> We are basically asking "Why sending notifications is the only action that
> could be triggered by model defined events and/or push subscriptions
> and/or smart filters"? Why, for example, pre-defined network re-
> configurations could not be triggered by smart filters? Why it is not possible
> for the client to pre-configure d  esired a  ctions ahead of time?"
> 
> are not expected to just identify holes/leaks in the ship's bottom, report the
> "telemetry" to the captain and wait for instructions on what to do next,
> right? Each crew member not only knows his/her pre-defined actions, (s)he
> is meticulously trained on a daily basis on how to carry out them in the most
> efficient way. This is how ships survive problems like that. Also this is how the
> same authority can control big and multiple ships.
> 
> Cheers,
> Igor
> 
> 
> On the smart filters (also relates to https://tools.ietf.org/html/draft-clemm-
> netconf-push-smart-filters-ps-00), I think we need criteria to carefully select
> "conditions". While there are many benefit, say save the bandwidth and
> relief the collector, it will add computation burden to network devices.
> Network devices are not good at this as servers.
> So maybe:
> > Subject: [Netconf] YANG PUSH Based Generalized Network Control
> > Automation Problem Statement
> >
> > Dear WG,
> >
> > We have posted a draft on the problem statement to extend Yang push to
> > a more generalized network control automation framework.
> >
> > 	- allows for a client to define subscribable events and contents of
> > event notifications as target-trigger-notify triplets
> >
> > 	- allows for a client to filter event triggers and notifications on
> > push object values and their change history, focuses on "outliers"
> >
> > event-condition-action concept, where:
> >
> > 	event - a particular change in the network state explicitly defined
> > by one of the YANG models supported by the network or implicitly
> > defined by the client, which is constantly monitored by the network;
> >
> > the associated event is detected;
> >
> > 	action - an operation to be carried out by the network when the
> > associated event is detected and the associated condition is met
> >
> > event-condition-action triplets as policy rules ahead of time or/and
> > during network operations
> >
> > Generalized Action
> > * Send notification
> > call network's path computer to evaluate whether an alternative/more
> > optimal path is available for a given connection)
> > * The framework should fit well within a higher level policy
> > framework, with the latter possibly providing a greater level of automation:
> >   - multiple micro-actions could be combined into a single transaction
> > with a possibility of specifying policies with respect to handling
> > * better scale (e.g. the client may control more networks because it
> > does not have to monitor/micro-manage any of them);
> > between the client and the network
> > * The client can take itself out of the network control loop,  change
> > its role from being network's "micro-manager" to being network's
> > "police officer", who interferes into network operations only in

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 2 Nov 2017 18:08:38 +0000

Hi, just to add on:

I do think the intent of this is to be reasonably simple.  To provide something like a generalized fog programming framework would not be the idea here, just the ability to provide some very basic automation (such as the ability to collect more information when certain events occur, maybe run a test that can be invoked via RPC, etc).

I don’t think that smart filters will provide a comprehensive source of events either.  The focus there is on fairly simple conditions, such as value in or out of range, high water mark, etc.  This does go beyond xpath in that some state for these is needed.  Still, I would think that smart filters will be one source but not the only source of events – there will be other notifications (beyond push updates), and perhaps at some point someone will indeed produce the equivalent of an event and expression MIB. (The ambition with smart filters is to be a little less than that, let alone a script MIB.)

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Igor Bryskin
Sent: Thursday, November 02, 2017 10:39 AM
To: Andy Bierman <[email-masked]>
Cc: Xufeng Liu <[email-masked]>; [email-masked]
Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi Andy,

Igor

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, November 02, 2017 1:15 PM
To: Igor Bryskin
Cc: Tianran Zhou; Xufeng Liu; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

Cheers,
Igor

Andy

-----Original Message-----
From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tianran Zhou
Sent: Wednesday, November 01, 2017 11:31 PM
To: Xufeng Liu; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi Xufeng,

Best,
Tianran

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Nov 2017 12:20:13 -0700

Hi,

I do not want to imply the IETF should work on a general-purpose scripting
engine for YANG.
IMO NETCONF and NETMOD have too many unfinished work items to start new
ones right now.
It would be prudent to get the chartered notification work finished before
adding more features.

Spot solutions that are intentionally incomplete and non-reusable are too
expensive in the IETF.

Andy

On Thu, Nov 2, 2017 at 10:59 AM, Alexander Clemm <[email-masked]

> Just a few comments regarding the role of YANG Push smart filters in this,
> and where I view the boundary between them:
>
> - A smart filter allows to send updates only when certain filter
> conditions regarding its values are met, possibly involving state.
> Example: A threshold has been crossed, a high-water mark has been
> breached.  These updates clearly constitute "events" that can feed into an
> event/condition/action rule.
> - That said, the focus on smart filters is to be smart-yet-simple,
> applying 90/10 rule.  It is not the intention to make this assume the role
> of a general "Event + Expression MIB".   For examples, events that would
> require cross-correlation comparing values across data items, processing
> entire lists, computing aggregates over time, etc, would be outside the
> scope.
> - The assessment of any conditions would be left for the automation
> framework.  In other words, a smart filter will just assess the update
> itself against a smart filter.  It will not make additional checks with
> regards to other data or take other actions as a result of the filter
> before sending an event.  That would be precisely left for the automation
> stages.  There is a reason that it's "event-condition-action", not simply
> "trigger-action".
>
> --- Alex
>
>
> draft-clemm-

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 2 Nov 2017 19:41:59 +0000

Hi Alex,

Thanks for your thoughtful comments. Please, see in-line.

Igor

-----Original Message-----
From: Alexander Clemm 
Sent: Thursday, November 02, 2017 2:00 PM
To: Igor Bryskin; Tianran Zhou; Xufeng Liu; [email-masked]
Subject: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi,

IB>> Exactly. For example, consider the logic:

if(link's bandwidth utilization > 80% threshold) /* smart filter */
   configure parallel link /* generalized action */

If the client knows that this is what needs to be done in such an event, why not to say that ahead of time instead of processing the link's telemetry and asking for the action reactively?   
 
- That said, the focus on smart filters is to be smart-yet-simple, applying 90/10 rule.  It is not the intention to make this assume the role of a general "Event + Expression MIB".   For examples, events that would require cross-correlation comparing values across data items, processing entire lists, computing aggregates over time, etc, would be outside the scope.  
IB>> Fair enough. But sending notification and relying on a higher (client's) intelligence is one of the actions, but it is not the only one. How the client's and network's intelligences are split could be optimized and best compromises found   

IB>> agree    

--- Alex

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 2 Nov 2017 22:36:59 +0000

Agree we should finish the chartered work first.  Hopefully this is not too far off...  Clearly we don’t want to delay, but I don’t think it is too early to start thinking about what should be put in the pipeline next?  The fact that there is more demand to build on the existing platform and add to it should be a good thing.  Netconf has been very configuration / fulfillment oriented so far.  The notification/subscription/push work opens up the door for another field, assurance.  This is a big opportunity.
--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, November 02, 2017 12:20 PM
To: Alexander Clemm <[email-masked]>
Cc: Igor Bryskin <[email-masked]>; Tianran Zhou <[email-masked]>; Xufeng Liu <[email-masked]>; [email-masked]
Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi,

I do not want to imply the IETF should work on a general-purpose scripting engine for YANG.
IMO NETCONF and NETMOD have too many unfinished work items to start new ones right now.
It would be prudent to get the chartered notification work finished before adding more features.

Spot solutions that are intentionally incomplete and non-reusable are too expensive in the IETF.

Andy

On Thu, Nov 2, 2017 at 10:59 AM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

--- Alex

> From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Igor Bryskin
> To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Xufeng Liu
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 3 Nov 2017 02:44:24 +0000

Hi Alex,

I do agree with your perspective on the scope considerations.
And I like the 90/10 rule.

Cheers,
Tianran

> Sent: Friday, November 03, 2017 2:00 AM
> - A smart filter allows to send updates only when certain filter conditions
> regarding its values are met, possibly involving state.  Example: A
> threshold has been crossed, a high-water mark has been breached.  These
> updates clearly constitute "events" that can feed into an
> - That said, the focus on smart filters is to be smart-yet-simple, applying
> 90/10 rule.  It is not the intention to make this assume the role of a general
> "Event + Expression MIB".   For examples, events that would require
> cross-correlation comparing values across data items, processing entire
> lists, computing aggregates over time, etc, would be outside the scope.
> - The assessment of any conditions would be left for the automation framework.
> In other words, a smart filter will just assess the update itself against
> a smart filter.  It will not make additional checks with regards to other
> data or take other actions as a result of the filter before sending an event.
> That would be precisely left for the automation stages.  There is a reason
> that it's "event-condition-action", not simply "trigger-action".
> 
> --- Alex
> 
> 
> > Please, note that we see smart filters as a significant step from
> > current push machinery in evolution of network control automation,
> > because it empowers the client to instruct the network to identify and
> > focus on "outliers", rather than on routine changes in the network
> > State. I agree, this will impose more complexity on the network, but
> > the benefits are obvious. For example, instead of receiving tons of
> > largely useless information, 99% of which to be discarded after the
> > processing, the client will be able to receive only "interesting"
> > information WRT actionable events. The network control automation
> framework intends to make one step further in this evolution.
> > We are basically asking "Why sending notifications is the only action
> > that could be triggered by model defined events and/or push
> > subscriptions and/or smart filters"? Why, for example, pre-defined
> > network re- configurations could not be triggered by smart filters?
> > Why it is not possible for the client to pre-configure d  esired a  ctions
> ahead of time?"
> >
> > Think about a battleship that just has been torpedoed. The crew
> > members are not expected to just identify holes/leaks in the ship's
> > bottom, report the "telemetry" to the captain and wait for
> > instructions on what to do next, right? Each crew member not only
> > knows his/her pre-defined actions, (s)he is meticulously trained on a
> > daily basis on how to carry out them in the most efficient way. This
> > is how ships survive problems like that. Also this is how the same authority
> can control big and multiple ships.
> >
> > Cheers,
> > Igor
> >
> >
> > netconf-push-smart-filters-ps-00), I think we need criteria to
> > carefully select "conditions". While there are many benefit, say save
> > the bandwidth and relief the collector, it will add computation burden
> to network devices.
> > > We have posted a draft on the problem statement to extend Yang push
> > > to a more generalized network control automation framework.
> > >
> > > notifications defined by supported YANG models;
> > >
> > > * Call RPC defined by one of the YANG models supported by the
> > > network (
> > e.g.
> > >   - multiple micro-actions could be combined into a single
> > > transaction with a possibility of specifying policies with respect
> > > to handling errors/exceptions of each of the transaction components
> > >
> > > Framework Benefits
> > > * The client can take itself out of the network control loop,
> > > change its role from being network's "micro-manager" to being
> > > network's "police officer", who interferes into network operations
> > > only in exceptional/unpredicted situations
> > >
> > >