Hi Andy, Jurgen, Alex and All,
I believe that YANG could be a useful participant in a successful ECA framework
if the following is kept in mind:
1. It is not feasible to realize an ECA framework relying solely on YANG. It
is reasonable to expect ECA capable servers to support to a sufficient degree
Xpath Expressions language and some sort of general purpose scripting
environment , such as Python, JunoScript, TCL/TKL, etc.;
2. ECA YANG model should define (and/or use definitions produced by other YANG
models for) certain ECA components, such as Events, Policy Variables (PVs) and
Actions (e.g. network re-configurations, client notifications, invoking of
RPCs, etc.), but everything to do with Conditions and logical and mathematical
expressions (which should be expected to be potentially very complex), should
be left to XPath (i.e. configured as XPath expression strings). Although it is
possible to define elementary micro conditions, it would be impractical (too
tedious) for the clients to build conditions hierarchically (bottom up) and too
cumbersome for the servers to process such constructs;
3.Likewise, it would be too demanding to expect servers implementing
interpreters for specific purpose of interpretation of an ECA directly as it
configured in YANG. Rather , it would be prudent to expect a server, upon
receiving an ECA configuration, to generate out of it a micro-script in a
locally supported scripting language and arrange said micro-script execution at
the moment of the Event (or timer) firing;
4. In short, the objective of the ECA YANG configuration is to provide a
universal ECA representation that could be converted into a micro-script of the
server's choice.
What do you think?
Igor
On Wednesday, February 26, 2020, 1:11:00 PM EST, Andy Bierman
<[email protected]> wrote:
Hi,
On Tue, Feb 25, 2020 at 5:57 PM Alexander Clemm <[email protected]> wrote:
In my view, an ECA model allows to define rules for events – conditions –
actions, i.e. what actions to perform when an event occurs and a condition met.
A smart filter filters an input stream, letting some objects pass but not
others. They are not the same.
There is a connection in that you could define the passing of an object by a
smart filter as an event. So, it is conceivable to include an ability to
define events in this draft. If this is the intent it should be stated so
clearly. The question then becomes if you would want those be used also
independently of the ECA model – there may be benefit in defining a new event
without tying it to a rule (i.e. a condition and action) but simply emitting
it.. (Same thing for the timer notification, which might have uses beyond
ECA.) In the draft these things are all mashed together, but separating the
ability to define an event from the ability to specify an ECA rule (which
refers to / is triggered by an event) can benefit reusability.
Anyway, as mentioned I think this work is relevant and I would like to see it
go forward; IMHO some reframing and perhaps splitting of the draft should be
considered whether that occurs before WG adoption or afterwards.
I do not agree that refactoring this draft solves any adoption
issues.YANG-based management already has events (specified with
notification-stmt).The ECA data model should not duplicate other functionality
such as alarms.Any event that can be received on an event stream (RFC 8639)
should automaticallybe usable in any ECA logic. Working on a solution without
agreement on even the mostbasic ECA architecture or problem scope is a recipe
for failure.
Programming with YANG data models as the logic for conditions and actionshas
never been proven to work. Even the trivial examples are complexand real-world
use-cases seem near impossible. (nobody has ever provided oneso we have to
speculate). Achieving interoperability with a workable solutionwill not be
easy. Other solutions have got "Hello world" to work, declared victory,and then
went away forever. Why will this time be different?
Andy
--- Alex
From: Tianran Zhou <[email protected]>
Sent: Tuesday, February 25, 2020 4:44 PM
To: Alexander Clemm <[email protected]>; Joel Jaeggli <[email protected]>;
[email protected]
Subject: RE: [netmod] Adoption poll for draft-wwx-netmod-event-yang
Hi the authors,
>“Another one to allow the definition of custom events/notifications, or smart
>filters for push updates. (We should bring back the earlier draft.)”
As we worked on the smart filter before. We want to use the ECA model.
It seems this model enabled the generic programmability. Can we just use it to
program any filter or what potentially need to augment/customize for a specific
model?
Thanks,
Tianran
From: netmod [mailto:[email protected]]On Behalf Of Alexander Clemm
Sent: Wednesday, February 26, 2020 4:01 AM
To: Joel Jaeggli <[email protected]>;[email protected]
Subject: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang
Hi,
I support this draft and would like to see netmod work on this, but I do think
some aspects need more maturing and parts of this probably should be rescoped.
Should the draft be adopted now, or should it be improved first and adopted
later? Not sure. I would like to see the work continue, so in that sense I
would clearly like to see the work adopted; at the same time there are a
number of issues that IMHO really need to be addressed.
I share some of the concerns raised by Juergen and Andy. Specifically, I think
the precise problem needs to be defined more clearly. In the discussion it was
mentioned RMON – would it be that, or perhaps a better analogy Event MIB?
Section 3 mentions that this is to specify trigger conditions for when to send
push updates. That is perhaps consistent with an Event MIB, but a slightly
different problem from ECAs. Section 4.2 then proceeds to allow for the
definition of “events” – but really only defining a “timer event”, with the ECA
model omitting tie-in e.g. with notifications. Including a threshold mechanism
here is a bit distracting and should perhaps be taken out – while the crossing
of a threshold might constitute an event, I don’t think this should be tied
inside an ECA but be something that stands on its own. (The prior draft on
Smart Filters for Push Updates addressed this – it has layed dormant for a
while and in this sense I can’t object for this work to be picked someplace
else, but logically really it does not belong here but should be separate.)
The actions, finally, describe not simply management operations. I understand
the intent is to have an escape mechanism allowing to “call out” other
functions / scripts deployed at a device, but this intent needs to be called
out more clearly.
So, in summary, I think the WG should consider rescoping this draft a bit –
maybe divided into separate drafts, each addressing a separate concern, which
will provide focus and make the problem being solved clearer: One to define an
ECA framework. In this, clarify the invocation of actions, and allow for
tie-in of notifications. This would be this draft. Another one to allow the
definition of custom events/notifications, or smart filters for push updates.
(We should bring back the earlier draft.) A third one to perhaps allow for the
definition of “custom RPCs” that allow to invoke custom scripts/functions via
Netconf/Restconf operations, then tie that , which are then invoked using the
regular RPC. (This would be a new draft)
--- Alex
From: netmod <[email protected]>On Behalf Of Joel Jaeggli
Sent: Tuesday, February 18, 2020 8:44 AM
To: [email protected]
Subject: [netmod] Adoption poll for draft-wwx-netmod-event-yang
This email begins a 2 week working group adoption poll for:
https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06
Please voice your support or objections before the poll completes on March 3rd.
Thanks
joel
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
