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

Igor Bryskin <> Mon, 04 November 2019 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDC08120A8D for <>; Mon, 4 Nov 2019 11:11:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RbIgK31ohw5F for <>; Mon, 4 Nov 2019 11:11:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F979120A25 for <>; Mon, 4 Nov 2019 11:11:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1572894660; bh=q4NvZkOanlr/moLeDjpHztB/1u/4yHlsAey5Oj78qeQ=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=e65H/HmEp+6Y2H2PvsKFVVZ4BnC/rDlNuByqgQKVpvGGXc5voTn3PpazGE2XYiDtgv99IwccGJRwGg9wkj4tMCpXvpA64w+7eFTCHuji+cndVlhr/u3adQgDVrAzhINwRA4HVr+2LI9z2Hbi+C+3RnmhippAP9Gf3dD6E18lFudSpH+oJ7Oucr25r1ud7VQjluOqqy6d6lY3vmG1d2ulBX/fSQYN5Rhp5LNm37qjFyS+O9d/y2iR/XjKpfVzHHgy32fYjp4TXP1B9BAO4GSJEm3qV5TywwSFG9A4GbHJcYa4nmm0DhAnO+5h/wcWsvX7ZiAdejmL3FtEhxxXGivKGQ==
X-YMail-OSG: pKmezygVM1mgRk8dKlicjtyFAWq5e1gtYAcHaWh9KGEmj_y7v6OeZSUMmXpZJM6 tTPFwKDEHCDvxFZjKmtuiAFWUmVBBOlJZae.zh2VWjBYBMAhVHSwxhGUyBxr7ZrbeLdPGT7TskKo Rt9dDX8x7WaOHuq7EpcoKQpdV4Ghll1ba8J_u4mcYH_M.M2NuO0GxH7mL8psFw4yMOjuGg85vk2y KUWrWIR2W0ssg4C5cYNup4iI_2fJQM0DxB16bNBzUdGihe_MQTKIfcas8m38dw4wCr2goHML6bJD PaMmVHD2lBTODQAbbzCKuPwnLN0WbeMtKZLDcvt.Y2DyA_w.qypnTufzEbXdzeYHQG84x56GpVyU Oxrs4xAZLlMTELBnmSPaFCVTBXUo61i20nLME5cbPkwMePRbav3E8vsBlQn_cFSOmeKWVh_AwLdd e.VrtAJVMYGKnLxhTEbwTFsyTWzYThkmmYtRdbUjXX0PBN.0pAN4Xmp3zhcXOI_jo2K5INkoSExp Usr6IdCD4ZsUaqryyLyDu_BikguEgRd5cDk7dFOsqhuYyMSYA_8Op2tLME41CRCuFVYAqnIPDAbf jhk8RGE_H7pV3J4uEmVDEgoQKx3wEh_TbcXgkC_6R4ka8oZHz_hnko.c9H9u6O_v1POX40z0fdmV 78kza.BVUrwcQS8uI19SUIhoe6uXrjjCIyLHtbjyw9SwHUKKeMBhR6o.yZ4x3KHrcB1.EH6O3mRX PYDkUhBQm2q53_74zibORCI2MNt2XlqaJjtqrPYGFJOWwFG.GqdY6fWlLYNe3que3GtK.opty8QR 8__6gfSBqm3IGcNY12_QpzpL.2KdQwiSqUd1F._nE16Atmpq7v2FEw2z.8m9WWE0imCbzEyWG596 V0kY1TJG19p7E9RvKigRkb77jKtjgkhhxXyma2Xd8nEhJDZghzaZdJClHTZp0g1XsQA4Y2cifwVc CAObrqmGs5JL5HRMsq3kTvMxPcorLB.cRV2HUdB7Ecmi2B1RZx.DN3fxwAI5.bgBhKHjjSWy7B4k ofVRfi5jSqvf3a2M3p6HnAXuxOGD7znakr8IFI_OiidiXfShYW0M8DOcWE.KLZLnSaWolLflaGp5 C8SZRRnSVt3MKoU16LVEnAtT60xMTqncsSdG13mb5GUKN_VTbKe7J08HI43fA9yBYn5V_wT.7quE qzx.Ot6T_N8_rn3Ty12sKdr9TlWIA17vS3KkmAUIs6.glTqDyaSUOKisYSIIUJ5gpb_CdZQoVCJH eak8Xwde8SPhLkBcXeLns27u_.O35KjaR4Gp94tuLn0KmaIIEflLUh4xpfmN79OTwB7k6BZaxgp. j3SbDKapVZFWUaKmjujZx5FClKQ--
Received: from by with HTTP; Mon, 4 Nov 2019 19:11:00 +0000
Date: Mon, 04 Nov 2019 19:06:01 +0000
From: Igor Bryskin <>
To: Qin Wu <>, "" <>,, Lou Berger <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1414483_1192168966.1572894361411"
X-Mailer: WebService/1.1.14638 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Archived-At: <>
Subject: Re: [netmod] I-D Action: draft-wwx-netmod-event-yang-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 19:11:16 -0000

 Hi Qin,

Thanks for the effort.

My general question is  what is the ultimate objective/ambition of this work? Is it

1. Modeling the imperative policy style network automation as stipulated by the SUPA framework
2. Event scoping of PUSH machinery

If 2. is the case, it would certainly make sense and might prove useful for many use cases. However, in this case you have neither reason nor right to use well understood abbreviation ECA, nor to refer to the SUPA documents. Neither it would make any sense to merge our contributions IMHO

If 1. is the case, then
here is our comments/suggestions as to how the work should in our opinion evolve going forward:

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 ( 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;
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 
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. There are situations, however, when the said re-configurations must be applied immediately after the event detection with no time to loose on network- client communications. Furthermore, there are cases when the necessary re-configurations are known a priory (at the time of the ECA configuration), and the client may want to pre-configure them along with configuring  the ECA's Event and Condition, and then rely on what we call close loop network automation, rather than to be involved in device/network micro management in real time. To this end our contribution suggests the flowing ECA Action configuration options:a) Network re-configuration (in the form of per-configured Netconf edit config statements);
b) PUSHing notifications to the client (the same as you suggest)
c) Enabling/disabling notification streams (pre-configured as PUSH subscriptions);
d) Invoking local network intelligence (configured as YANG RPCs defined in supported by the server YANG models). For example, calling local TE path computation (defined as Path Computation RPC by the te-tunnel  or Path Computation model) could be configured within ECA as Action in order to discover more optimal path for a TE tunnel after the configured Event is fired.
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.

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

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

Igor (and Xufeng)

    On Saturday, November 2, 2019, 10:33:40 AM EDT, Lou Berger <> wrote:  
    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

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.


On 11/1/19 11:02 PM, Qin Wu wrote:
> v-04 is posted to address chairs' comments, 
> 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 [] 代表
> 发送时间: 2019年11月2日 10:57
> 收件人:
> 主题: 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:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories: or