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

From: Qin Wu <[email-masked]>
Date: Thu, 9 Nov 2017 13:32:36 +0000

Alex:
That is a good design consideration, condition check job is not trivial. When you decouple condition check from smart filter, does this mean you leave condition check to NETCONF kernel to do this?

-Qin
发件人: Alexander Clemm
发送时间: 2017年11月9日 5:44
收件人: Igor Bryskin <[email-masked]>; Qin Wu <[email-masked]>; Tianran Zhou <[email-masked]>; [email-masked]; [email-masked]
主题: RE: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement

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]<mailto:[email-masked]>>; Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Qin Wu <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement

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,

A few additional comments inline, <ALEX>

Thanks
--- Alex

> -----Original Message-----
> From: Igor Bryskin
> Sent: Wednesday, November 08, 2017 9:00 AM
> 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]>
> Subject: RE: YANG PUSH Based Generalized Network Control Automation
> Problem Statement
>
> 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]<mailto:[email-masked]>
> Subject: RE: YANG PUSH Based Generalized Network Control Automation
> Problem Statement
>
> 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: Alexander Clemm <[email-masked]>
Date: Thu, 9 Nov 2017 18:50:41 +0000

Hi Qin,

My thinking is (although Igor or Xufeng may want to chime in here) that this will be part of the automation framework.  We would not affect Netconf.  Not every device will implement the automation  framework; those that do will need to address this.  In my opinion, we need to look for simple solutions, which means that the complexity of conditions being checked should be constrained (you will not use this to program arbitrary custom decision logic, just simple (presumably stateless) checks such as existence or value ranges of certain objects ).  Those are some of the things that we will need to work out there.

--- Alex

From: Qin Wu
Sent: Thursday, November 09, 2017 5:33 AM
To: Alexander Clemm <[email-masked]>; Igor Bryskin <[email-masked]>; Tianran Zhou <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: RE: YANG PUSH Based Generalized Network Control Automation Problem Statement

Alex:

-Qin
发件人: Alexander Clemm
发送时间: 2017年11月9日 5:44
收件人: Igor Bryskin <[email-masked]<mailto:[email-masked]>>; Qin Wu <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: 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

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 9 Nov 2017 19:15:58 +0000

Hi Alex,

I agree. The automation will be governed  by a set of relatively simple models  (smart filters being one of them), which a server may or may not support.
In no way this would affect Netconf.

Igor

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

Hi Qin,

--- Alex

From: Qin Wu

Alex:

-Qin
发件人: Alexander Clemm
发送时间: 2017年11月9日 5:44

Hi Igor,

Best
--- Alex

From: Igor Bryskin

Hi Alex,

Igor
From:Alexander Clemm

Hi,

Thanks
--- Alex