Re: [netmod] I-D Action: draft-wwx-netmod-event-yang-04.txt

[Igor Bryskin <[e-mail]>]

Hi Qin, 






Thanks for  the  interesting and fruitful discussion. 




The most important next step in my opinion is to agree on how we model PVs. Specifically, 


1. How the client can configure a PV  of a known type (defined in a YANG model supported  by the server); 


2. How the client can use PVs in the ECAs (computation actions, condition evaluation, RPC input/output, notifications sent to the client, etc.) 




This done, I believe, everything else will fall into place rather quickly and relatively simple. 


F2F meeting in Singapore will help a lot. 


Unfortunately,  I am not coming to Singapore,  but Xufeng will be there. I am looking forward  to a good progress. 




Cheers and good luck, 


Igor 






Get Outlook for Android







On Thu, Nov 7, 2019 at 8:07 AM -0500, "Qin Wu" <[e-mail]> wrote:




















Hi, Igor:


Thank for your clarification, please see my follow up comments.


发件人: Igor Bryskin [mailto:[e-mail]]


发送时间: 2019年11月6日
 23:04

收件人: [e-mail]; [e-mail]; Lou Berger <[e-mail]>; Qin Wu <[e-mail]>

抄送: [e-mail]

主题: Re: I-D Action: draft-wwx-netmod-event-yang-04.txt


 




Hi Qin,



 



[ snipped]





........







 






1.The Expression clause in an ECA could be very complex and hence requires a complex syntax to articulate. To address this in our contribution
 (https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/)
 we proposed two methods:




























a) When configuring Condition using XPath expression string. This allows expressing Conditions
 of arbitrary complexity, but does require servers to (sufficiently) support XPath language;


[Qin]:XPATH expression is supported in model proposed in draft-wwx, it is modelled as one of member
 of union, i.e., instance-identifier, in addition, we support model three other member types
Type yang:object-identifier;
Type yang:uuid;



Type string



 



IB>> Good. Please, note that we were told on many occasions that because of potentiality very complex syntax of the ECA
 Condition clause, the XPath expression string is realistically the only choice, all alternatives are introduced for model completeness more than anything else - too cumbersome to be useful.


 


[Qin]: Tend to agree, this is complexity we can consider to get rid of.








b) For the case of simpler servers we defined elementary logical primitives that could be used
 in building bottom up in hierarchical manner complex logical expressions 




 


[Qin]: I believe you are talking about Condition Expression, which is corresponding to ietf-trigger.yang
 defined in draft-wwx-netmod-event-yang-04. We model them as three trigger conditions



1.       An existence test monitors and manages the absence, presence, and change of a data object



2.       A Boolean test compares the value of the monitored object with the reference value and takes action according to the comparison result.



3.       A Threshold trigger condition regularly compares compares the value of the monitored object with the threshold values.



In each trigger condition, we will break down them into policy variable and policy value based on RFC3460, policy variable
 is renamed as target, policy value is renamed as value in proposed ECA model



 



IB>> IMHO this is not  sufficient, not even close.


 


[Qin]: Actually it can be extended, the essence of trigger condition is <target><relation><arg> which is similar to <arg1><relation><arg2>
 in draft-bryskin


would you like to provide an example which can not be expressed by these trigger conditions?



I am open to the better design choice.



 



 




IB2>>> Realistically, this is not much of a use. Imagine you are a client and you have to express a condition made of some 80 logical operations.
 Using the above would be very cumbersome. And  what if in addition to the logical operations condition expression includes other operations, such as arithmetic, function calls, etc. ?




 






 [Qin-2]: I agree arithmetic, function calls is useful, but it is defined as part of action in the ECA model, right? Not
 part of condition statement?


Just to clarify, the target defined under event in draft-wwx is a target list, which is similar to policy variables list.
 Two key elements in trigger conditions are target, value, target is pointing to target under event and doesn’t need to be the data object that is being monitored or managed, it can be policy variable that is not presented in any YANG data model, value is expressed
 as one similar to <arg2> In draft-bryskin.
Operator in Boolean condition trigger case is similar to comparison-operation, it is not clear to me why condition made of 80 logical operations can not be described,
 maybe logical-operation-type should be introduced in the ECA model explicitly. We actually talk about this AND and OR design in the section 3.1 of draft-bwd-netmod-eca-framework-00.
In addition,
I am wondering how to describe a condition when a network event is triggered when the monitored object disappear or appear or change


How do you describe a condition when network event is triggered if the difference between the current measurement
 value and the previous


measurement value of monitored data object is smaller than or equal to the delta falling threshold.


I see the big difference is you defined local policy variable, distinct from global policy variable, global policy
 variable can apply to multiple script. I am not sure these scripts are generated from ECA YANG data model? Or pre-configured? How these scripts are different func call or XPAH function?


In addition, it is not clear to me why we mixed policy variable with policy value. I can not see difference between
 them by reading draft-bryskin. The policy value can be constant, or change based on some calculation method, see example of condition in section 5.8.3 of rfc3460. Do we need to align with RFC3460?


 



 
I feel you change the meaning of policy variable, since in bryskin’s draft, policy variable is described as an output parameter of an RPC which is not consistent with the definition in RFC3460, in my opinion.

IB>> No, I have not. In our definition a PV is a variable where an ECA thread stores results of computations and output of algorithms/RPCs, so that the results could be used within a single thread or between multiple threads of the same or different ECAs, could provide input for automatic re-configurations and RPCs, could be used in Condition evaluations, could be exposed directly to the client via notifications, etc. In short, this is the place where ECAs store and accumulate the results of their work


 [Qin]: I thought PV is corresponding to target defined in draft-wwx, or data object to be monitored,
 we will reflect the change of data object or target in the action definition of ECA model.




I see the only difference on model design, is target or policy variable is separated from ietf-event, or part of ietf-event. If the reason why
 we should have a separate policy-variable is we should store state on policy-variable or target, I think put policy-variable into ietf-event, you still can store state related to policy-variable in ietf-event, No?



 



IB2>> PV is a variable of the ECA language - i.e. a memory structure where ECA thread execution results could be stored to be used in subsequent
 Condition evaluations and Action inputs. In my view, PV has nothing to do with PUSH target,


[Qin-2]:PV is very powerful, it can change over time, it can be overridden, however it is also hard to keep track of which PV is impacted by which
 PV, which PV is final execution results? Which execution order we should follows.


PV can be explicit PV and implicit PV based on RFC3460, if it is explicitly PV, it is related to data object or data instance you manipulated. If
 it is implicit PV, it could be used to store tempo results.


In addition, we you define PV type as XPATH, it is actually related to data object you subscribed, in my opinion.







2. Your model seems to suggest for ECA Action  not much more than PUSHing a notification (triggered
 by a certain event and satisfying the configured condition) to the client with the hope that the client will subsequently request some device/network re-configurations ro react to the event.



 


[Qin]:Igor, the ECA action proposed in the model of draft-wwx-netmod-event-yang-04 can do more
 than PUSHing a notification, it have supported the following capabilities:




1)Configuration data object reconfiguration




 




IB>> Good, but keep in mind that the parameters of such configurations could not be limited to values specified by the
 client at the time of ECA configuration ( such values we call Policy Constants (PCs)). It is imperative to allow for the results of the ECA thread computations
 to be also used as values to configure (i.e. PVs along with PCs)


 


[Qin]: Yes, I have been aware that Policy constant is different from Policy variable, Are both pointing to the same monitored
 data objects?



I think whether it is policy constant or policy variable, it should be set or configured only when certain conditions hold.



 



IB2>> How do you allow the client to say "When Event E is fired, configure leaf L with a value computed using expression X"? Our suggestion
 is via two sun-Acrions associated with the ECA: first computes the expression X and stores it in a PV, second executes edit-config with the PV content as a value.



[Qin-2]: I agree arithmetic, function calls we should cover in ECA model. In the current model, we only support on
 event invoke another event. In your case, how to hook them together and define the work flow, e.g., first do this, and do that, this PV should be outputted by this process, input into another process? I think there is some challenge we should see how to tackle,
 right?







I am wondering where do you store the results of computations(e.g., mean/variance) or some tempo value of monitored data object?



 



IB2>> This is exactly what PV is for






You use policy variable itself or you have somewhere else to store these tempo results?



 



IB2>
Client defined PVs



 









......



 



[Qin]: Usually the RPC is sent from NETCONF client to NETCONF server ,do you propose the other way around and allow the netconf server send RPC
 request to the NETCONF client? I am not sure we can do this



 



 



IB2>> In the context of ECA the RPC Action is request to invoke  *local* server intelligence (such as path computation engine) that would be
 normally invoked if the client called a YANG RPC (e.g. as defined by the Path Computation model). In other words it is calling by the client an RPC deferred until the specified Event.


















  .......


[Qin]: I understand you are looking into TE path computation use case. If ECA model can support path computation API, that will be brilliant,J


 



In addition, when we talk about how to use ECA model, are we focusing  using ECA model in the external interface between NMS and router or are
 you focusing on using ECA model as internal script to manipulate service logic?








 



IB>> The latter. This is what pushing (imperative or declarative) policies down to the network server usually means.







 [Qin]: I think both are needed to provided event driven network management, first, the management
 system put down ECA policy to the managed device using NETCONF interface, secondly, ECA script is generated from ECA policy in the managed device.



3. Evaluation of ECA Conditions, as well as input to ECA Actions may require not just instantaneous
 network states, but also accumulation/computation of thereof over periods of time (e.g. min/max/mean leaf values, history data, threshold overstep counters, results of various functions/computations/algorithms performed on network states over time, etc.) Hence
 there is a need for storage of intermediate results of such computations. Our contribution introduces such storage in the form of Policy Variables (PVs). PVs could be part of Condition expressions, as well as Action inputs along with instant network states.
 PVs also could appear in notifications PUSHed to the client.


 


 


[Qin]: If you follows
https://tools.ietf.org/html/draft-bwd-netmod-eca-framework-00


You will see we have already considered what state needs to be held, current state and history
 state, and where this state is held.


Basic state of ECA include: Event Name, event occurrence time, start time, end time, threshold
 value, etc.



I think it is challenging to store all the states and it adds complexity of server implantation.



 



IB>> No, I am talking about defining /pushing by the client and executing by the server arbitrary logic in the form of
 ECAs. This logic, for example, may instruct the server how to recover from various network failures under extreme time constraints. It may also instruct the server how to identify and report "interesting" for the client  events and data, rather than stream
 raw data  99% of which to be parched, evaluated and discarded as uninteresting 








[Qin]: yeah, network failure recovery and filtering unwanted data are two valid use cases we are
 aiming at also. I am fascinating on function-call you proposed, I am wondering where you store these computation results, why not defined it as mathematics function, just provide input



And then get output, but the problem where to store these output, in addition, how many policy-argument you can support? I seems only two policy-arguments
 are supported? If we support mathematics function, you can support more than two policy arguments, right?



 



IB2>>The answer is PVs. See above. Without PVs you are limited only to instantaneous network states to work with. This may be sufficient for
 PUSH event scoping, but not for generic ECAs


[Qin-2]: I agree to have PV or target to store post processed network states or the value of managed data object. The model proposed in draft-wwx
 is mingled in between, cover whole push event scoping but doesn’t cover arithmetic, function calls, RPC for generic ECAs.





 


4. Notifications triggered by ECA s require definition beyond what is defined by PUSH models, so
 that the notifications could be properly associated by the client with a given execution of a given ECA.  Said definition could be found in
https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/.


 



[Qin]:Good, we also provide a few use cases in the section 4 of draft-bwd-netmod-eca-framework-00 to discuss how notification
 is sent to the NMS to trigger another ECA policy execution, we also could support One event invoke another event, depends on use cases,



 



IB>> Note that ECAs is not about intense communication between the client and the server, rather, quite the opposite -
 it is about pushing ECAs down to the server and let the server perform the instructed event driven network management



 


[Qin]: We are aligned on this core case.





The use case we like to aim at is service assurance use case and network troubleshooting self-management
 use case.



 



We have more points to discuss, but what is above is a good starting point.



 



Regards,

Igor (and Xufeng)































 




 





 









On Saturday, November 2, 2019, 10:33:40 AM EDT, Lou Berger <[e-mail]>
 wrote: 




 




 





Qin,

    Thanks for the update.



To answer your question as well as respond to the related thread, as

chair, I generally think it best to adopt once there is consensus in the

WG on a direction to take with respect to the topic covered by a draft.

That is not to say that a fully formed or documented solution is

required at adoption but that if there are several different approaches

available, that the adopted work reflects the direction that the WG will

pursue.



In this case, the current rev is certainly a step in that direction, but

the WG still as two different basic approaches available to it in this

draft and draft-bryskin-netconf-automation-yang.  I personally always

prefer it when individual draft authors can find common ground and come

to the WG with a single (unified) proposal rather than ask the working

group to choose one over the other.  I'm not sure who among the authors

will be in Singapore, but perhaps the authors can take the opportunity

to meet to discuss the possibly of such a unified proposal as well

report back to the working group on their progress/status.  Time

permitting, we should at least hear a summary of each approach so that

if a unified approach is not proposed that the WG is better informed on

the proposals.



Cheers,

Lou






On 11/1/19 11:02 PM, Qin Wu wrote:

> v-04 is posted to address chairs' comments, 

> https://datatracker.ietf.org/doc/html/draft-wwx-netmod-event-yang-04

> the main changes include:

>    o  Add text in introduction section to clarify the usage examples of

>      ECA policy

>    o  Update objective section to align with use cases.

>    o  Clarify the relationship between target and policy variable.

>    o  Change variation trigger condition back into threshold trigger

>      condition and clarify the usage of three trigger conditions.

>    o  Remove Event MIB related section.

>    o  Add new coauthors and contributors.

> Chairs, what is the next step?

> 

> -Qin (on behalf of authors)

> 

> -----邮件原件-----

> 发件人: I-D-Announce [mailto:[e-mail]]
代表
[e-mail]

> 发送时间: 2019年11月2日
 10:57

> 收件人:
[e-mail]

> 主题: I-D Action: draft-wwx-netmod-event-yang-04.txt

> 

> 

> A New Internet-Draft is available from the on-line Internet-Drafts directories.

> 

> 

>        Title          : A YANG Data model for ECA Policy Management

>        Authors        : Michael Wang

>                          Qin Wu

>                          Chongfeng Xie

>                          Igor Bryskin

>                          Xufeng Liu

>                          Alexander Clemm

>                          Henk Birkholz

>                          Tianran Zhou

>     Filename        : draft-wwx-netmod-event-yang-04.txt

>     Pages          : 32

>     Date            : 2019-11-01

> 

> Abstract:

>    RFC8328 defines a policy-based management framework that allow

>    definition of a data model to be used to represent high-level,

>    possibly network-wide policies.  Policy discussed in RFC8328 are

>    classified into imperative policy and declarative policy, ECA policy

>    is an typical example of imperative policy.  This document defines an

>    YANG data model for the ECA policy management.  The ECA policy YANG

>    provides the ability for the network management function (within a

>    controller, an orchestrator, or a network element) to control the

>    configuration and monitor state change on the network element and

>    take simple and instant action when a trigger condition on the system

>    state is met.

> 

> 

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-wwx-netmod-event-yang/

> 

> There are also htmlized versions available at:

> https://tools.ietf.org/html/draft-wwx-netmod-event-yang-04

> https://datatracker.ietf.org/doc/html/draft-wwx-netmod-event-yang-04

> 

> A diff from the previous version is available at:

> https://www.ietf.org/rfcdiff?url2=draft-wwx-netmod-event-yang-04

> 

> 

> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

> 

> Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

> 

> _______________________________________________

> I-D-Announce mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/i-d-announce

> Internet-Draft directories: http://www.ietf.org/shadow.html
or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

>