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

From: Qin Wu <[email-masked]>
Date: Wed, 8 Nov 2017 15:21:08 +0000

Interesting discussion, does smart filter mean that netconf server should be stateful since it keep a few state while traditional yang push doesn't require netconf sever to be stateful, i.e., should be stateless?
I think set threshold for packet loss or latency is pretty much common in network trouble shooting, such threshold can be also moved down over time.
What kind of threshold can be set more depends on empirical experience. I am wondering how this can be modeled using XPATH statement or some other mechanism.

-Qin
-----邮件原件-----
发件人: Netconf [mailto:[email-masked]] 代表 Igor Bryskin
发送时间: 2017年11月3日 3:42
收件人: Alexander Clemm <[email-masked]>; Tianran Zhou <[email-masked]>; Xufeng Liu <[email-masked]>; [email-masked]
主题: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

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,

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. 

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

IB>> agree    

--- Alex

> -----Original Message-----
> 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]
> Subject: Re: [Netconf] YANG PUSH Based Generalized Network Control 
> Automation Problem Statement
> 
> 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 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
> 
> 
> -----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,
> 
> 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.
> >
> > 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
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 8 Nov 2017 17:00:02 +0000

Hi Qin,

Please, see in-line.

Igor

-----Original Message-----
From: Qin Wu 
Sent: Wednesday, November 08, 2017 10:21 AM
To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu; [email-masked]
Subject: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement

IB>> Yes. For example, an RPC (one of possible generalized actions) output could be stored to be used in subsequent ECAs (event-condition-action). The models we have in mind will allow for managing and accessing such state.

IB>> I let Alex answer this, but I would assume that the smart-filters model will allow for comparing a data state pointed by XPath with configured threshold value to evaluate trigger condition (and much more)

-Qin
-----邮件原件-----
发件人: Netconf [mailto:[email-masked]] 代表 Igor Bryskin
发送时间: 2017年11月3日 3:42
收件人: Alexander Clemm <[email-masked]>; Tianran Zhou <[email-masked]>; Xufeng Liu <[email-masked]>; [email-masked]
主题: Re: [Netconf] YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi Alex,

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

--- Alex

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 8 Nov 2017 19:00:17 +0000

Hi,

A few additional comments inline, <ALEX>

Thanks
--- Alex

> From: Igor Bryskin
> Sent: Wednesday, November 08, 2017 9:00 AM
> To: Qin Wu <[email-masked]>; Alexander Clemm
> <[email-masked]>; Tianran Zhou
> <[email-masked]>; Xufeng Liu <[email-masked]>;
> [email-masked]
> Interesting discussion, does smart filter mean that netconf server should be
> stateful since it keep a few state while traditional yang push doesn't require
> netconf sever to be stateful, i.e., should be stateless?
> 
> IB>> Yes. For example, an RPC (one of possible generalized actions) output
> could be stored to be used in subsequent ECAs (event-condition-action). The
> models we have in mind will allow for managing and accessing such state.

<ALEX> Yes.  Just how much state we want to allow is one of the items that need to be discussed.  I am of the opinion that this should be limited to a few frequently used scenarios such as threshold crossing alerts and in-range/out-of-range monitors.  By its nature, a threshold monitor _has_ to be stateful (it is not sufficient to simply compare the current value of a data item against the threshold, you also need to know if you already reported this earlier without clearing the counter threshold in the meantime).  This will be simply part of the feature of the smart filter that is configured via Netconf/Restconf.  However, I don't think the state in those cases should have to be externally exposed - it is simply part of how the filter construct works.  

The other stateful scenario currently defined as in-scope in the problem statement is the "recent high water mark" scenario, in which you keep track of the high water mark for some amount of time after which it is cleared.  (The analogy is that of a graphic equalizer.)  

With regards to automation and ECA, I would view smart filters as an important source of events, but not as the only one.  The intent here is not to provide a general programming framework to define any type of events - as mentioned earlier, this is not intended as an event+expression MIB or any such thing, just frequently needed filters/categories of events that are fairly broadly applicable and useful.  Obviously, where the "sweet spot" lies is subject to discussion.  We would love to hear feedback about what other filters are deemed useful.  
</ALEX>
> 
> 
> I think set threshold for packet loss or latency is pretty much common in
> network trouble shooting, such threshold can be also moved down over
> time.
> What kind of threshold can be set more depends on empirical experience. I
> am wondering how this can be modeled using XPATH statement or some
> other mechanism.
> 
> IB>> I let Alex answer this, but I would assume that the smart-filters
> IB>> model will allow for comparing a data state pointed by XPath with
> IB>> configured threshold value to evaluate trigger condition (and much
> IB>> more)

<ALEX> We need to figure out the details of the filter construct.  In addition to node selection and value/range comparison against a threshold/range expression (so far, so straightforward), you need to be able to specify a comparison against a state, to update the state (e.g. threshold crossing sent vs cleared, current high water mark etc), to specify a counter / clear threshold, etc.   I don't think this can be accomplished with XPATH alone.  
--- Alex
</ALEX>

 (remainder of message thread deleted)

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 8 Nov 2017 19:12:19 +0000

Hi Alex,

I do agree with you that in the context of the network control automation smart filters will contribute conditions rather than events. Events will be explicitly defined by the network control automation model(s) and/or any other YANG models supported by the server.

Igor
From:Alexander Clemm
To:Igor Bryskin,Qin Wu,Tianran Zhou,Xufeng Liu,[email-masked],
Date:2017-11-08 14:00:25
Subject:RE: YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi,

Thanks
--- Alex

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 8 Nov 2017 21:43:43 +0000

Hi Igor,

But I don't think we will assess conditions as part of smart filters.   IMHO this should be part of the automation framework.  Just to clarify terminology, to me an event is some kind of "occurrence" that you are notified of (such as "threshold has just been crossed", "an update that meets a smart filter has just been observed", "some YANG notification has just been emitted", etc), whereas the condition is a "check" that is actively conducted (to see if the condition holds when the event was observed).  Smart filters on YANG-push updates will provide for many of the events that the automation framework would utilize, but they may not be the only source, that's all.

Best
--- Alex

From: Igor Bryskin
Sent: Wednesday, November 08, 2017 11:12 AM
To: Alexander Clemm <[email-masked]>; Igor Bryskin <[email-masked]>; Qin Wu <[email-masked]>; Tianran Zhou <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi Alex,

Igor
From:Alexander Clemm

Hi,

Thanks
--- Alex

> To: Qin Wu <[email-masked]<mailto:[email-masked]>>; Alexander Clemm
> <[email-masked]<mailto:[email-masked]>>; Tianran Zhou
> <[email-masked]<mailto:[email-masked]>>; Xufeng Liu <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>
> To: Igor Bryskin; Alexander Clemm; Tianran Zhou; Xufeng Liu;
> [email-masked]<mailto:[email-masked]>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 8 Nov 2017 22:53:03 +0000

Alex,

If I understand you correctly, from the automation framework's point of view a smart filter could be a (part of) event of an event-condition-action that may or may not trigger an action depending on associated with the event conditions  (which could be, for example. one-time  check(s) of data store node(s) or RPC output(s) against some constant or variable  value(s)). I agree. What I meant to say is  that events may be explicitly defined, not be necessarily smart filters,  because constant evaluation of smart filters may be too demanding for the server. On the other hand, evaluating smart filters once in an event's context  is much simpler proposition.

Igor

From: Alexander Clemm
Sent: Wednesday, November 08, 2017 4:44 PM
To: Igor Bryskin; Qin Wu; Tianran Zhou; [email-masked]; [email-masked]
Subject: RE: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement

Hi Igor,

Best
--- Alex

From: Igor Bryskin

Hi Alex,

Igor
From:Alexander Clemm

Hi,

Thanks
--- Alex