Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC92120A46 for ; Tue, 5 Nov 2019 06:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdJFfnqybpJi for ; Tue, 5 Nov 2019 06:50:33 -0800 (PST) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BAE12081D for ; Tue, 5 Nov 2019 06:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1572964468; bh=4KMZkjbxljDWkx0bOezjNRuExAYJB78q9s4OWLiFjjU=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=P6MeRfawEtj0LyKT9KH6n1mJ+samsmapGDrycyHfxwSwKxM82ek3w1OqVLn9sUJL+U+hEBObw7SatA6yCffsRd/jQSL34fSuVIudi+zoxEO3Qhpw95Sj2QkGGlkUpE/hd3C1bp8woriBiJ1qBJu5fPbro9TKlz5zlqvPK//r6hwUORhDL0FPeM1HBsgR723aKpXXWxrlpTqMjKafVQT4SToNgvVTDs5ZJNyVlSyhE1CJODRc38rkotxVZnVF1jLPhWobma+ojvUO8LnYjdXv90f2MpvsMMu2wOtn2Ex/uSxDNxkjDGbJJ1qfE4hFWX0h2cjt+rSQtvPrR3YD/sY4FQ== X-YMail-OSG: rn5srowVM1k3MUtXsXbA3yIIVxvLf8O0l1WzxU3ilVkoaij9BT_MRUlBEIJA9QF bkM08rZPPWedWRA_kUlCMWZeQ8oNxN_2v7PbG3IsTPQAmj.LTJ3phgGvjoSPN_DHV1CsDIPeWtQo 9wYenwccMJtfj7l76cSgC28gn4UUFsLc5zovSeMLkn0cLWDhmKMO4hMKzo_0y4zmAokSpzx.cwzd sM4huLKqwcxyvHj3MnkjvgslwckzzEOfrYuxasSQt094BQyHkkv_MgKrQ4ZwktugJAJq4yIhAlQc GGqwVPA3ElM0fcxv2vhfIleb2JEKuRt477yvyIuWBdiNi6fUbC6vHcTIRNKQtj.NKRZZMFqFYnXZ z.vxwyGqzqy6ySK0ItlY3M0MQT2WEEzQI23tw5QSAIVJ0tUz4Xo9BQHmZa3mdGAmCDPBFxgKyTsN FCbBsYJPFU7_Sbl1a7pbtqDCrKPyehKEEAvcTapNfjoVzdfWcwIqNmRY2QSrlzymGxZUyP1O7d4i bnwWu2V9ckmxQUvBaMXFRWR9sboyUlxNyqYwM9CMHYbB0hxrGKo5ti9f_SaZyoFickSpcChBWKGo U8ZD5dvQ8eCXRAmrpkmUDUNQ2swoZ8sIrKwSTGge7sB6seOZfTSn7EQdkUwf8KOylLDScwfG42pt rCpx2qId2FNGhW5JAiDBIPg4X6Zesd5nhxZ7j6eOKG919RFMR28QgrYwG.miWInDOdMBmb93cmiX Kb2iktyo1vx6.Qfq3BDkMsYPDRfxrK7c.7trF9qJ8WxxGM0X0NLd.7e0N7dD6dWh4UnHDClBkn9_ ii.JwCVkxBy3fnfIyqik0Ip2h4aTvdsgF61MceIopwEw3vKj6iMqrGtjGDD5rZBks9Q.qSjnpMLb yMSVGBwrByu_aRxIEPd6T9AKJtvfCyiERPK50SrEcsf4CDbZS0ges6LA23K2_F4zvyMDGuwo4Tq4 cTxfieUuVNkDijPV5dDV0KrEBw71b92O4Jpf1wgbbBpci15fsHjz205CyDBhmkUDbNWOdtXDPsTu LJ2AW9eJY8FDG4gKV9chUyZy.PKjaWt9H8ykI0gD6WWWcGCIAmmVJMVWV0k8eOe2hnjXycDAMyfs Gz3.aDHCAKkbZm89BYDoxPzCyc40mrd_KyYXZ_XaZgk6TxZ3I0Re5IKHBfX3PlfxjYBr8aF6MydO My4uWX1P7SU.6c8eiTMWXVAkr7.molk728y8iJT.89xCuewldGxX.BddbPzPer_n_XIph08jpHuF LlykRkvTSOJ8a95qwtvQu._XxF.VdJTQORsxL1RguKEqC.OeyYnL8VGAo49lT00OhoZ_T3wi8ig. vc56wzNuBDsyjyUJ5aN2at5luNDFSSoTF Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Tue, 5 Nov 2019 14:34:28 +0000 Date: Tue, 5 Nov 2019 14:01:43 +0000 (UTC) From: Igor Bryskin To: "netmod@ietf.org" , "draft-bryskin-netconf-automation-yang@ietf.org" , Lou Berger , Qin Wu Cc: "draft-wwx-netmod-event-yang@ietf.org" Message-ID: <794371551.1792893.1572962503805@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1792892_710899355.1572962503799" 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-BeenThere: netmod@ietf.org 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: Tue, 05 Nov 2019 14:50:44 -0000 ------=_Part_1792892_710899355.1572962503799 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Qin, Good discussion. Please, see in-line. Igor On Tuesday, November 5, 2019, 3:09:53 AM EST, Qin Wu wrote: =20 =20 =20 Hi, Igor: =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Igor Bryskin [mailto:i_bryskin@yahoo.com] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B411=E6=9C=885=E6=97=A5 3:= 06 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu ; netmod@ietf.org; = draft-bryskin-netconf-automation-yang@ietf.org; Lou Berger =E6=8A=84=E9=80=81: draft-wwx-netmod-event-yang@ietf.org =E4=B8=BB=E9=A2=98: Re: I-D Action: draft-wwx-netmod-event-yang-04.txt =20 =C2=A0 =20 Hi Qin, =20 =C2=A0 =20 Thanks for the effort. =20 =C2=A0 =20 My general question is=C2=A0 what is the ultimate objective/ambition of thi= s work? Is it =20 =C2=A0 =20 1. Modeling the imperative policy style network automation as stipulated by= the SUPA framework =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or =20 2. Event scoping of PUSH machinery =20 =C2=A0 =20 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 =20 =C2=A0 =20 If 1. is the case, then =20 here is our comments/suggestions as to how the work should in our opinion e= volve going forward: =20 =C2=A0 =20 [Qin]:Good question, I think we mostly focus on modelling imperative policy= in which ECA is a typical example of ECA model. In addition, we see Event = scoping of PUSH machinery is a special case of ECA without Action to be spe= cified. We clarified the relation with YANG Push, we think YAN PUSH model can be a= ugmented with some grouping defined in ECA model. So ECA model doesn=E2=80= =99t need to tie with YANG Push. IB>> True, but if we model generic ECAs, things like=C2=A0 PUSH Event scopi= ng, Smart Filters, etc. come naturally as trivial private cases. There is n= o need to focus on them. =20 =C2=A0 =20 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 propo= sed two methods: =20 a) When configuring Condition using XPath expression string. This allows ex= pressing Conditions of arbitrary complexity, but does require servers to (s= ufficiently) support XPath language; =20 [Qin]:XPATH expression is supported in model proposed in draft-wwx, it is m= odelled 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 ex= pression string is realistically the only choice, all alternatives are intr= oduced for model completeness more than anything else - too cumbersome to b= e useful. =20 b) For the case of simpler servers we defined elementary logical primitives= that could be used in building bottom up in hierarchical manner complex lo= gical expressions =20 =C2=A0 =20 [Qin]: I believe you are talking about Condition Expression, which is corre= sponding to ietf-trigger.yang defined in draft-wwx-netmod-event-yang-04. We= model them as three trigger conditions =20 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0An existence test monitors and manage= s the absence, presence, and change of a data object =20 2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A Boolean test compares the value of = the monitored object with the reference value and takes action according to= the comparison result. =20 3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0A Threshold trigger condition regular= ly compares compares the value of the monitored object with the threshold v= alues. In each trigger condition, we will break down them into policy variable an= d policy value based on RFC3460, policy variable is renamed as target, poli= cy value is renamed as value in proposed ECA model IB>> IMHO this is not=C2=A0 sufficient, not even close. I feel you change the meaning of policy variable, since in bryskin=E2=80= =99s draft, policy variable is described as an output parameter of an RPC w= hich 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 thre= ad stores results of computations and output of algorithms/RPCs, so that th= e results could be used within a single thread or between multiple threads = of the same or different ECAs, could provide input for automatic re-configu= rations 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=20 =C2=A0 =20 2. Your model seems to suggest for ECA Action=C2=A0 not much more than PUSH= ing a notification (triggered by a certain event and satisfying the configu= red condition) to the client with the hope that the client will subsequentl= y request some device/network re-configurations ro react to the event. =20 =C2=A0 =20 [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 foll= owing capabilities: 1)Configuration data object reconfiguration IB>> Good, but keep in mind that the parameters of such configurations coul= d not be limited to values specified by the client at the time of ECA confi= guration ( 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 va= lues to configure (i.e. PVs along with PCs)=20 2) ECA Log report Notification 3)Invoke another Event=20 IB>> 2) and 3) are (albeit important) auxiliary functions, rather than ECA= Actions, strictly speaking =20 It can be extended to support more advanced features if needed. =20 =C2=A0 =20 There are situations, however, when the said re-configurations must be appl= ied 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), a= nd the client may want to pre-configure them along with configuring=C2=A0 t= he ECA's Event and Condition, and then rely on what we call close loop netw= ork automation, rather than to be involved in device/network micro manageme= nt in real time. To this end our contribution suggests the flowing ECA Acti= on configuration options: =20 a) Network re-configuration (in the form of per-configured Netconf edit con= fig statements); [Qin]: We support this. =20 b) PUSHing notifications to the client (the same as you suggest) [Qin]: Cor= rect. =20 c) Enabling/disabling notification streams (pre-configured as PUSH subscrip= tions); [Qin]: Do you propose to allow netconf server send notif to the cli= ent and instruct client to enable or disable notification stream or the net= work server can enable or disable some =20 event stream and inform the client the result? =20 d) Invoking local network intelligence (configured as YANG RPCs defined in = supported by the server YANG models). For example, calling local TE path co= mputation (defined as Path Computation RPC by the te-tunnel=C2=A0 or Path C= omputation model) could be configured within ECA as Action in order to disc= over more optimal path for a TE tunnel after the configured Event is fired. [Qin]: Usually the RPC is sent from NETCONF client to NETCONF server ,do y= ou propose the other way around and allow the netconf server send RPC reque= st to the NETCONF client? I am not sure we can do this IB>> No, this is about instructing the serer to invoke=C2=A0 its local inte= lligence with the identity and input/output of which=C2=A0 articulated by t= he client (as ECA Action) in the form of an RPC defined in a YANG model sup= ported by the server. Think about it this way: when the client per-configur= es an automatic re-configuration, it does so in the form of edit-config NET= CONF command, that is, in the form of a native NETCONF RPC. We simply exten= d this to allow for specifying RPCs defined by YANG models (e.g. Path Compu= tation RPC). In addition, when we talk about how to use ECA model, are we focusing =C2= =A0using ECA model in the external interface between NMS and router or are = you focusing on using ECA model as internal script to manipulate service lo= gic? IB>> The latter. This is what pushing (imperative or declarative) policies = down to the network server usually means. =20 =C2=A0 =20 3. Evaluation of ECA Conditions, as well as input to ECA Actions may requir= e not just instantaneous network states, but also accumulation/computation = of thereof over periods of time (e.g. min/max/mean leaf values, history dat= a, threshold overstep counters, results of various functions/computations/a= lgorithms performed on network states over time, etc.) Hence there is a nee= d for storage of intermediate results of such computations. Our contributio= n introduces such storage in the form of Policy Variables (PVs). PVs could = be part of Condition expressions, as well as Action inputs along with insta= nt network states. PVs also could appear in notifications PUSHed to the cli= ent. =20 =C2=A0 =20 =C2=A0 =20 [Qin]: If you followshttps://tools.ietf.org/html/draft-bwd-netmod-eca-frame= work-00 =20 You will see we have already considered what state needs to be held, curren= t state and history state, and where this state is held. =20 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 o= f server implantation. IB>> No, I am talking about defining /pushing by the client and executing b= y 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 a= nd report "interesting" for the client=C2=A0 events and data, rather than s= tream raw data=C2=A0 99% of which to be parched, evaluated and discarded as= uninteresting=20 =20 =C2=A0 =20 4. Notifications triggered by ECA s require definition beyond what is defin= ed by PUSH models, so that the notifications could be properly associated b= y the client with a given execution of a given ECA.=C2=A0 Said definition c= ould be found in https://datatracker.ietf.org/doc/draft-bryskin-netconf-aut= omation-yang/. =20 =C2=A0 [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 t= rigger 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 a= nd the server, rather, quite the opposite - it is about pushing ECAs down t= o the server and let the server perform the instructed event driven network= management=20 =20 The use case we like to aim at is service assurance use case and network tr= oubleshooting self-management use case. =20 =C2=A0 =20 We have more points to discuss, but what is above is a good starting point. =20 =C2=A0 =20 Regards, Igor (and Xufeng) =20 =C2=A0 =20 =C2=A0 =20 =C2=A0 =20 On Saturday, November 2, 2019, 10:33:40 AM EDT, Lou Berger wrote: =20 =C2=A0 =20 =C2=A0 =20 Qin, =C2=A0=C2=A0=C2=A0 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.=C2=A0 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.=C2=A0 I'm not sure who among the author= s 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.=C2=A0 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 =20 On 11/1/19 11:02 PM, Qin Wu wrote: > v-04 is posted to address chairs' comments,=20 > https://datatracker.ietf.org/doc/html/draft-wwx-netmod-event-yang-04 > the main changes include: >=C2=A0 =C2=A0 o=C2=A0 Add text in introduction section to clarify the usag= e examples of >=C2=A0 =C2=A0 =C2=A0 ECA policy >=C2=A0 =C2=A0 o=C2=A0 Update objective section to align with use cases. >=C2=A0 =C2=A0 o=C2=A0 Clarify the relationship between target and policy v= ariable. >=C2=A0 =C2=A0 o=C2=A0 Change variation trigger condition back into thresho= ld trigger >=C2=A0 =C2=A0 =C2=A0 condition and clarify the usage of three trigger cond= itions. >=C2=A0 =C2=A0 o=C2=A0 Remove Event MIB related section. >=C2=A0 =C2=A0 o=C2=A0 Add new coauthors and contributors. > Chairs, what is the next step? >=20 > -Qin (on behalf of authors) >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: I-D-Announce [mailto:i-d-announce-bounces@ie= tf.org]=E4=BB=A3=E8=A1=A8internet-drafts@ietf.org > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B411=E6=9C=882=E6=97=A5 = 10:57 > =E6=94=B6=E4=BB=B6=E4=BA=BA:i-d-announce@ietf.org > =E4=B8=BB=E9=A2=98: I-D Action: draft-wwx-netmod-event-yang-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : A YA= NG Data model for ECA Policy Management >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Michael W= ang >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Qin Wu >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Chongfeng Xie >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Igor Bryskin >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Xufeng Liu >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Alexander Clemm >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Henk Birkholz >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tianran Zhou > =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-wwx-netmod= -event-yang-04.txt > =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 32 > =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2019-1= 1-01 >=20 > Abstract: >=C2=A0 =C2=A0 RFC8328 defines a policy-based management framework that all= ow >=C2=A0 =C2=A0 definition of a data model to be used to represent high-leve= l, >=C2=A0 =C2=A0 possibly network-wide policies.=C2=A0 Policy discussed in RF= C8328 are >=C2=A0 =C2=A0 classified into imperative policy and declarative policy, EC= A policy >=C2=A0 =C2=A0 is an typical example of imperative policy.=C2=A0 This docum= ent defines an >=C2=A0 =C2=A0 YANG data model for the ECA policy management.=C2=A0 The ECA= policy YANG >=C2=A0 =C2=A0 provides the ability for the network management function (wi= thin a >=C2=A0 =C2=A0 controller, an orchestrator, or a network element) to contro= l the >=C2=A0 =C2=A0 configuration and monitor state change on the network elemen= t and >=C2=A0 =C2=A0 take simple and instant action when a trigger condition on t= he system >=C2=A0 =C2=A0 state is met. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-wwx-netmod-event-yang/ >=20 > 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 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-wwx-netmod-event-yang-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > 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 >=20 =20 ------=_Part_1792892_710899355.1572962503799 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Qin,

Good discussion. Please, see in-line.

Igor

=20
=20
On Tuesday, November 5, 2019, 3:09:53 AM EST, Qin Wu &l= t;bill.wu@huawei.com> wrote:


Hi, Igor:

=20

=E5=8F=91=E4=BB=B6=E4=BA=BA: Igor Bryskin [mailto:i_b= ryskin@yahoo.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2019=E5=B9=B4= 11=E6=9C=885=E6=97= =A5 3:06
=E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>; netmod@ietf.org; draft-= bryskin-netconf-automation-yang@ietf.org; Lou Berger <lberger@labn.net&g= t;
=E6=8A=84=E9=80=81: draft-wwx-netmod-event-yang@ietf.org
=E4=B8=BB=E9=A2=98: Re: I-D Action: draft-wwx-netmod-event-yang-04.txt=20

 =

=20

Hi Qin,

=20

 

=20

Thanks for the effort.

=20

 

=20

My general question is  what is the ultimate obje= ctive/ambition of this work? Is it

=20

 

=20

1. Modeling the imperative policy style network automa= tion as stipulated by the SUPA framework

=20

         = or

=20

2. Event scoping of PUSH machinery

=20

 

=20

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

=20

 

=20

If 1. is the case, then

=20

here is our comments/suggestions as to how the work sh= ould in our opinion evolve going forward:

=20

 

=20

[Qin]:Good question, I think we mostly focus on modell= ing imperative policy in which ECA is a typical example of ECA model. In ad= dition, we see Event scoping of PUSH machinery is a special case of ECA without Action to be sp= ecified.

=20
We clarified the relation with YANG Push, we th= ink YAN PUSH model can be augmented with some grouping defined in ECA model= . So ECA model doesn=E2=80=99t need to tie with YANG Push.



IB>= ;> True, but if we model generic ECAs, things like  PUSH Event scop= ing, Smart Filters, etc. come naturally as trivial private cases. There is = no need to focus on them.
=20

 

=20

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

=20

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

=20

[Qin]:XPATH expression is supported in model proposed = in draft-wwx, it is modelled as one of member of union, i.e., instance-iden= tifier, in addition, we support model three other member types

=20 
Type yang:object-iden=
tifier;
=20 
Type yang:uuid;
=20
Type string

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

b) For the case of simpler servers we defined elementa= ry logical primitives that could be used in building bottom up in hierarchi= cal manner complex logical expressions

=20

 

=20

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

=20

1.  =      An ex= istence test monitors and manages the absence, presence, and change of a da= ta object

=20

2.  =      A Boo= lean test compares the value of the monitored object with the reference val= ue and takes action according to the comparison result.

=20

3.  =      A Thr= eshold trigger condition regularly compares compares the value of the monit= ored object with the threshold values.

=20
In each trigger condition, we will break down them i= nto policy variable and policy value based on RFC3460, policy variable is r= enamed as target, policy value is renamed as value in proposed ECA model

IB>> IMHO this = is not  sufficient, not even close.
=20 
I feel you change the=
 meaning of policy variable, since in bryskin=E2=80=99s draft, policy varia=
ble is described as an output parameter of an RPC which is not consistent w=
ith 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 result=
s 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 d=
ifferent 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=20

  
=20





2. Your model seems to suggest for ECA Action  no=
t much more than PUSHing a notification (triggered by a certain event and s=
atisfying 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.

=20

  
=20

[Qin]:Igor, the ECA action proposed in the model of dr=
aft-wwx-netmod-event-yang-04 can do more than PUSHing a notification, it ha=
ve supported the
 following capabilities:
=20

1)Configurati=
on data object reconfiguration


IB>> Good, bu=
t keep in mind that the parameters of such configurations could not be limi=
ted to values specified by the client at the time of ECA configurati=
on ( 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 t=
o configure (i.e. PVs along with PCs)
=20

2) ECA Log report Notification
=20

3)Invoke another Even=
t 

IB>> 2) and 3) are (albeit important) auxiliary  functions,=
 rather than ECA Actions, strictly speaking
=20

It can be extended to support more advanced features i=
f needed.
=20

  
=20

There are situations, however, when the said re-config=
urations 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-configu=
rations 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 contributi=
on suggests the flowing ECA Action configuration options:
=20





a) Network re-configuration (in the form of per-config=
ured Netconf edit config statements); [Qin]:=
 We support this.
=20



b) PUSHing notifications to the client (the same as yo=
u suggest) [Qin]: Correct.
=
=20



c) Enabling/disabling notification streams (pre-config=
ured as PUSH subscriptions); [Qin]: Do you p=
ropose to allow netconf server
 send notif to the client and instruct client to enable or disable notifica=
tion stream or the network server can enable or disable some<=
/p>=20

event stream and inform the client the result?<=
/p>=20





d) Invoking local network intelligence (configured as =
YANG RPCs defined in supported by the server YANG models). For example, cal=
ling local TE path computation
 (defined as Path Computation RPC by the te-tunnel  or Path Computatio=
n 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.=20

[Qin]: Usually the RPC is sent from NETCONF client t=
o 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

IB>> No, this is about instructin=
g the serer to invoke  its local intelligence with the identity and in=
put/output of which  articulated by the client (as ECA Action) in the =
form of an RPC defined in a YANG model supported by the server. Think about=
 it this way: when the client per-configures an automatic re-configuration,=
 it does so in the form of edit-config NETCONF command, that is, in the for=
m of a native NETCONF RPC. We simply extend this to allow for specifying RP=
Cs defined by YANG models (e.g. Path Computation RPC).


=
=20

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

IB>> The latter. This is wha=
t pushing (imperative or declarative) policies down to the network server u=
sually means.
=20





  
=20



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

  
=20

  
=20

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

You will see we have already considered what state nee=
ds to be held, current state and history state, and where this state is hel=
d.
=20

Basic state of ECA include: Event Name, event occurren=
ce time, start time, end time, threshold value, etc.
=20

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

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



  
=20



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 foun=
d in 
https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/=
.
=20

  
=20

[Qin]:Good, we also provide a few use cases in the s=
ection 4 of draft-bwd-netmod-eca-framework-00 to discuss how notification i=
s sent to the NMS
 to trigger another ECA policy execution, we also could support One event i=
nvoke 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 pushin=
g ECAs down to the server and let the server perform the instructed event d=
riven network management 
=20

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



  
=20



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



  
=20



Regards,

Igor (and Xufeng)
=20

 

=20

 

=20

 

=20

On Saturday, November 2, 2019, 10:33:40 AM EDT, Lou Be= rger <lberger@labn.net> wrote:

=20

 

=20

 

=20

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<= br clear=3D"none"> 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 author= s
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

=20


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 u= sage examples of
>      ECA policy
>    o  Update objective section to align with use cases.=
>    o  Clarify the relationship between target and polic= y variable.
>    o  Change variation trigger condition back into thre= shold trigger
>      condition and clarify the usage of three trigger c= onditions.
>    o  Remove Event MIB related section.
>    o  Add new coauthors and contributors.
> Chairs, what is the next step?
>
> -Qin (on behalf of authors)
>
> -----=E9=82=AE= =E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB= =B6=E4=BA=BA: I-D-A= nnounce [mailto:i-d-announce-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 internet-drafts@ietf.org
> =E5=8F= =91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5= =B9=B411=E6=9C=882=E6=97=A5 10:57
> =E6=94=B6=E4=BB= =B6=E4=BA=BA: i-d-announce@ietf.org
> =E4=B8=BB=E9=A2= =98: I-D Action: dr= aft-wwx-netmod-event-yang-04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
>        Title          : A= YANG Data model for ECA Policy Management
>        Authors        : Michae= l Wang
>                    &= nbsp;     Qin Wu
>                    &= nbsp;     Chongfeng Xie
>                    &= nbsp;     Igor Bryskin
>                    &= nbsp;     Xufeng Liu
>                    &= nbsp;     Alexander Clemm
>                    &= nbsp;     Henk Birkholz
>                    &= nbsp;     Tianran Zhou
>     Filename        : draft-wwx-net= mod-event-yang-04.txt
>     Pages          : 32
>     Date            : 201= 9-11-01
>
> Abstract:
>    RFC8328 defines a policy-based management framework that = allow
>    definition of a data model to be used to represent high-l= evel,
>    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 do= cument 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 con= trol the
>    configuration and monitor state change on the network ele= ment and
>    take simple and instant action when a trigger condition o= n 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=3Ddraft-wwx-netmod-event-yang-04
>
>
> Please note that it may take a couple of minutes from the time of subm= ission 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
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

=20
------=_Part_1792892_710899355.1572962503799--