billwuqin
commented
4 years ago Forward Andy's comment related to this issue as follows: " On Tuesday, May 19, 2020, 1:16:20 PM EDT, Andy Bierman andy@yumaworks.com wrote:
Hi,
I need to catch up on the draft details soon.
I like an architecture that relies on the NETCONF/YANG interface of the device. The device event streams (plus pseudo-events) are the ECA logic input. The device RPC requests (include YANG action) are the ECA logic output.
This allows ECA clients to use the same ECA logic on a controller platform or on a native device platform. Controller deployment is important because not all native platforms will be able to support ECA, or will not be upgraded soon enough.
The action taken by an ECA policy will rarely be as simple as sending 1 hard-wired notification or RPC request. Even a simple edit can be done about 10 different ways on an arbitrary server.
IMO there needs to be an extensible library of pseudo-commands (or scripts) that can be used by the ECA logic. e.g, a primitive called "update-config" that handles all the editing variants like :candidate, :writable-running, :startup, and even locking and NMDA.
The extensible library architecture can be standardized without picking a programming language. This allows standard and vendor pseudo-commands to be supported from the start. Binding the YANG interface to a real programming language API could be opensource or maybe standardized later.
"
The assumption we made for ECA is ECA capable servers support a sufficient degree Xpath expression languages and some sort of general purpose scripting enviroment, so we need an usage example to show how to translate ECA configuration into general purpose script.