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

[Schönwälder, Jürgen <[e-mail]>]

Benoit,

thanks for the clarification.

I still believe that the approach taken is wrong. I doubt that network
operators are interested in an assembly level approach for expressing
threshold triggers. I am not sure xpath is the answer either. What was
perhaps reasonable to try in the 90s (RMON, DISMAN work) may not be
reasonably today anymore.

The example starting on page 43 seems to be doing this

  every 10 minutes
  if    exists(/ietf-interfaces:interfaces='eth0')
  and   if:interface[if:name='eth0']/if:statistic/if:in-errors >= 100
  then  /if:interfaces/if:interface[if:name='eth0']/if:enable = false

but it requires 1.5 pages of XML to express this (and then the rule is
not even meaningful since comparing an absolute value of a counter is
not useful).

If we are serious about policies, I believe we need to think about a
language-based approach that can be read and understood and which does
the things that are meaningful. Let me makeup some pseudo code based
on the example that can work for all eth* interfaces and that gets the
delta calculation of the counter right.

  if = /ietf-interfaces:interfaces/interface # json style namespace binding
  dt = 600 # 10 minutes in seconds
  every dt
  foreach name in $if/name:
    this = $if/[name=$name]
    if   $name matches 'eth.*'
    and  delta($this/statistic/in-errors, dt) >= 100
    then $this/enable = false

If people are serious about doing this kind of work, start by
collecting real-world policies that need to be expressable, then
identify the "language" mechanisms that are needed (loops over lists,
bindings, variables and substitutions, pattern matching, ...) and then
find a suitable representation. Yes, this is also something that
people wanted SUPA to do and it did fail because it was already hard
to collect real-world policies that help to understand what kind of
mechanisms are needed and why.

/js

On Wed, Feb 19, 2020 at 11:45:39AM +0100, Benoit Claise wrote:
> 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
> > 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>