Subject: Re: [Supa] SUPA charter proposal

From: Benoit Claise <[email-masked]>
Date: Wed, 2 Sep 2015 15:58:16 +0200

Juergen,

So you wants a SIEVE-like language for policies?
Not sure I understood that from the BoF.

Regards, Benoit
> On Sat, Aug 15, 2015 at 10:09:32AM -0700, Andy Bierman wrote:
>> I prefer a solution where the smarts are provided by the client,
>> not built into the policy engine.
> +1
>
>> Programming in YANG is a non-starter,
>> but programming in a scripting language that is very YANG-aware is quite
>> the opposite.
>>
>>    event: leverage pub/sub work in NETCONF WG
>>    condition: scripts, using event data and framework to access topology and
>> NE data
>>    action: scripts, using some framework to access topology and NE data
>>
>> It is hard to standardize a script language, so not sure how this will
>> happen.
> There are examples in the IETF, like for instance the SIEVE mail
> filtering language:
>
> https://en.wikipedia.org/wiki/Sieve_%28mail_filtering_language%29
>
> Unfortunately, Benoit's proposed charter seems to rule out solutions
> where the power is in scriptable events / conditions / actions.  So,
> the alternatives that are in Benoit's proposed charter are we either
> do something that
>
> (a) requires domain specific data models for every type of policy
>      (unlikely to be implemented if you ask me) or something that
>
> (b) exposes even simple boolean expressions as complex collections of
>      YANG objects (leading to something way too complex to be used for
>      anything more serious than hello world examples), or
>
> (c) we will define a policy framework that essentially only works with
>      strings that mean something to black boxes that interpret them in
>      whatever way they like best (which is unlikely to be
>      interoperable).
>
> Going back to the 'disable SNMP on all edge routers' example, I would
> assume that a solution has an action that essentially instantiates ACL
> entries according to the YANG ACL configuration data model. The
> knowledge of which ports need to be blocked is encoded in the config
> snippet embodied in the action. The condition needs to hook into the
> topology data model and extract all routers that are edge routers.
> This ideally boils down to filtering on some tags in the topology
> model. The events that trigger the rule would essentially be any
> changes to the IP topology layer (e.g., when edge routers are added or
> removed) and it might in addition be periodic. With scriptable
> events/conditions/actions, I can see how I could do all this with
> meaningful complexity. But as said above, unfortunately Benoit's
> proposed charter rules this option out. So the proponents of the other
> approaches need to explain how they are going to implement a simple
> policy like 'disable SNMP on all edge routers'.
>
> /js
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Sep 2015 21:23:35 +0200

I believe that exposing expressions as collections of operators and
operands that are all separate YANG objects is the wrong level of
abstraction. We use xpath in YANG must/when expressions and in NETCONF
(see the :xpath capability) for filtering purposes. It feels odd to go
back to an assembly language like notation for policy conditions and
event expression.

Personally, I think that policy actions should support basic
primitives working on YANG configuration models, such as insert an
entry in list a if it is not yet present, remove all entries from list
b that match a certain expression, etc. This is what I always had in
mind when I used the term 'generic policy model' - namely a mechanism
that can evaluate event and candition expressions on arbitrary YANG
data models and that can make modifications on arbitrary YANG
configuration data models.

/js

On Wed, Sep 02, 2015 at 03:58:16PM +0200, Benoit Claise wrote:
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 2 Sep 2015 13:57:30 -0700

+1

I brought up the issue that the charter text could apply to either approach.
IMO a leaf containing an XPath expression is far better than
a leaf for every token in the XPath expression.  It is also better to
use an existing standard rather than invent yet another regular expression
syntax.

> configuration data models.

I don't think the "action" scripts can be YANG data nodes.
The complexity here could vary greatly (e.g. 1-shot, or
req. and need to examine response, or multiple req./resp. pairs
with if/then/else branching)

The problem is that boiling the ocean is no good and some trivial
solution that is just a toy is no good.  A completely prorietary
"action" solution is also no good. I am really skeptical the IETF
can deliver the 'A' in ECA.

> /js

Andy

> > >>   condition: scripts, using event data and framework to access
> topology
> > >>   and
> > >>NE data