Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang

[Xufeng Liu <[e-mail]>]

Agree with Dan. The use case is valid, though the errors in the data model
can be fixed.
Support.
Thanks,
- Xufeng

On Wed, Feb 19, 2020 at 6:44 AM King, Daniel <[e-mail]> wrote:

> Hi All,
>
>
>
> Expressing, and delegating base imperative policy to network nodes
> (regardless if it’s a switch, router, network function, or indeed
> “controller”) is a critical step for facilitating network automation. I
> support the I-D and would like to see the WG adopt the work. Yes, the I-D
> needs to be developed further and this would be better managed if the
> effort was owned by the WG.
>
>
>
> I do agree somewhat with Jürgen that past experiences have shown a lack
> of willingness between vendors for expressing policy (imperative or
> otherwise). Major vendors have tended to implement their own policy
> language, or specific purpose (security, role management, et al.) language
> that has been based on standards (formal) or open-source project (de
> facto). The fact that the I-D author and contributor list already has a
> good mix of implementors demonstrates a willingness to develop an
> interoperable network-wide solution.
>
>
>
> BR, Dan.
>
>
>
> *From:* netmod <[e-mail]> *On Behalf Of *Benoit Claise
> *Sent:* 19 February 2020 10:46
> *To:* Schönwälder, Jürgen <[e-mail]>; Joel
> Jaeggli <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang
>
>
>
> Jürgen,
>
> To tell that I was skeptical about the SUPA work is just wrong.
>
> I had great hopes for SUPA, as having consistent policy constructs in YANG
> module was key. The big hope was that those SUPA constructs could be
> re-used in other YANG modules
>     example: routing, ACL, security ...
>     Regardless of the location: in a network element or in a
> controller/orchestrator
>     Regardless of the function: network element and service YANG modules
> If successful, in the end, SUPA would have helped to reuse code.
>
> Was I disappointed by the progress? Yes. The results were not there while
> the rest of the world uses their YANG policy constructs. Timing was key so,
> as AD, I had to pull the plug.
> The world has moved on. So be it.
> You can't infer skepticism from pragmatism.
>
> Now, back to the draft.
> From a network element point, I stressed the need to take have *simple *ECA
> rules directly routers.
> Think about RMON event/alarm but for YANG. Think about removing the RMON
> event/alarm restrictions that it works only for integer/counter.
> If your point is that the draft is not perfect, fair point.
> Should we solve attempt to solve that issue? Yes.
>
> A confusion comes from the abstract that implies that this work is based
> on SUPA.
>
> Abstract
>
>
>
>    RFC8328 defines a policy-based management framework that allows
>
>    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, Event
>
>    Condition Action (ECA) policy is an typical example of imperative
>
>    policy.  This document defines a YANG data model for the ECA policy
>
>    management.  The ECA policy YANG provides the ability for the network
>
>    management function (within a network element) to control the
>
>    configuration and monitor state change and take simple and instant
>
>    action on the server when a trigger condition on the system state is
>
>    met.
>
> Actually, in my mind, the abstract should be simplified to something such
> as (and yes, it could be improved)
>
> Abstract
>
>
>
>    This document defines a YANG data model for the ECA policy
>
>    management.  The ECA policy YANG provides the ability for the network
>
>    management function (within a network element) to control the
>
>    configuration and monitor state change and take simple and instant
>
>    action on the server when a trigger condition on the system state is
>
>    met.
>
> And then, somewhere in the introduction, the following text should be
> reused:
>
>    RFC8328 defines a policy-based management framework that allows
>
>    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, Event
>
>    Condition Action (ECA) policy is an typical example of imperative
>
>    policy.
>
>
> Regards, Benoit.
>
> On Tue, Feb 18, 2020 at 08:44:18AM -0800, Joel Jaeggli wrote:
>
> 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.
>
>
>
> I am against adoption of this draft. I wonder whether Benoit will
>
> explain his contributions to this document; Benoit was added as a
>
> co-author in -06 and he used to be rather sceptical about the SUPA
>
> work (and this is essentially part of the SUPA work resubmitted to the
>
> NETMOD WG). Despite this, the YANG definitions are clearly not up to
>
> the level one would expect for WG adoption. Many descriptions are
>
> just repetition of leaf names and there are obvious errors such as
>
>
>
>           leaf-list day-of-month {
>
>             type uint8 {
>
>               range "0..59";
>
>             }
>
>             description
>
>               "A set of days of the month at which this
>
>                scheduling timing will trigger.";
>
>           }
>
>
>
> Despite the strange range, it is unclear how a number will in the
>
> range will identify a set. Note, this is an example, there are lots of
>
> them in the document. The examples provides are not convincing and
>
> technically wrong (how can <interval>10m</interval> match
>
>
>
>           leaf interval {
>
>             type uint32 {
>
>               range "1..max";
>
>             }
>
>             units "seconds";
>
>             mandatory true;
>
>             description
>
>               "The number of seconds between two triggers
>
>                generated by this periodic timing object.";
>
>           }
>
>
>
> and I have serious doubts that the design is anywhere close to be
>
> practically usable. There need to be mechanisms to bind 'variables'
>
> while matching conditions that and be reused in action definitions, it
>
> is not scalable to have constants such as interface names in the
>
> examples hard-coded in policy rules - this would lead to a huge number
>
> of rules if you want to apply policy rules to all interfaces.
>
>
>
> There is also a lack of extensibility, which is important for a core
>
> policy language, and definitions like:
>
>
>
>   identity function-type {
>
>     description
>
>       "Possible values are:
>
>        plus, minus, mult, divide, remain.";
>
>   }
>
>
>
> without ever defining these operators feels strange. I also not
>
> convinced that the resulting expressions are expressive enough for
>
> real-world use.
>
>
>
> This document is in a state that requires way too much effort to fix
>
> in a WG process. I also doubt that expressing policies in such a
>
> low-level format is usable in practice. Policy languages for network
>
> management have a long history and this proposal seems to ignore the
>
> lessons learned in the past.
>
>
>
> /js
>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>