Subject: [Supa] ECA policy model definition

From: Tina TSOU <[email-masked]>
Date: Tue, 10 Feb 2015 13:10:16 +0000

Dear all,

After reading draft-hayashi-supa-policy-model-00, I think the ECA policy definition can be described as following. Thoughts?

Event, the monitored object based on which to make adjustment.
Condition, the value or state of the monitored object must meet some requirement.
Action, the consequent performance or operation.

E.g. If(a>10)  then b++;
Here, a is the event, a>10 is the condition and b++ is the action.

More specifically, in the network system a predefined policy model can be like this. Sorry, no description and code here, and I expect the authors can develop them if they think it makes sense.

Policy
    +--event
         +-- bandwidth usage 
         +-- port N status
         +-- TTL value
    +-- condition 
         +-- bandwidth usage > x
         +-- port N is up
         +-- TTL < y
    +-- action
         +-- adjust flow
         +-- use backup link
         +-- retry

Thank you,
Tina

---

From: John Strassner <[email-masked]>
Date: Tue, 10 Feb 2015 06:11:30 -0800

Hi Tina,

this is a rather restricted definition of ECA. A more general definition is
as follows:

   Event:       a significant occurrence in time that triggers the
evaluation of the condition of the policy rule
   Condition: a set of tests that determine if the actions of the policy
rule should be executed or not
   Action:      a set of operations that should be performed if the
condition is true

Note that event, condition, and action can each be made up of Boolean
clauses

In implementations that I have designed, there is also metadata for each
that can be used to describe the semantics of each.

regards,
John

On Tue, Feb 10, 2015 at 5:10 AM, Tina TSOU <[email-masked]>
wrote:

> Dear all,
>
> After reading draft-hayashi-supa-policy-model-00, I think the ECA policy
> definition can be described as following. Thoughts?
>
> More specifically, in the network system a predefined policy model can be
> like this. Sorry, no description and code here, and I expect the authors
> can develop them if they think it makes sense.
>
> Policy
>     +--event
>          +-- bandwidth usage
>          +-- port N status
>          +-- TTL value
>     +-- condition
>          +-- bandwidth usage > x
>          +-- port N is up
>          +-- TTL < y
>     +-- action
>          +-- adjust flow
>          +-- use backup link
>          +-- retry
>
>
> Thank you,
> Tina
>
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa
>

-- 
regards,
John

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 10 Feb 2015 14:33:51 +0000

+1, and a further (perhaps just personal edification) question for John:

Could “Condition” be extended to incorporate possible intersection with “Intent” … i.e., can we marry Intent-Driven and ECA on Condition … or do you see them as mutually exclusive …?

Or does Intent-Driven simply subsume ECA as an implementation approach at a “lower” level (i.e., closer to the managed resource)?

Or something else?

I believe that from a practical perspective many such implementation options are possible … but I am curious about the “right” formal relationships for reliable and efficient specification going forward.

Avanti,
BobN

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, February 10, 2015 9:12 AM
To: Tina TSOU; John Strassner
Cc: [email-masked]
Subject: Re: [Supa] ECA policy model definition

Hi Tina,

this is a rather restricted definition of ECA. A more general definition is as follows:

   Event:       a significant occurrence in time that triggers the evaluation of the condition of the policy rule
   Condition: a set of tests that determine if the actions of the policy rule should be executed or not
   Action:      a set of operations that should be performed if the condition is true

Note that event, condition, and action can each be made up of Boolean clauses

In implementations that I have designed, there is also metadata for each that can be used to describe the semantics of each.

regards,
John

On Tue, Feb 10, 2015 at 5:10 AM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

E.g. If(a>10)  then b++;

Policy
    +--event
         +-- bandwidth usage
         +-- port N status
         +-- TTL value
    +-- condition
         +-- bandwidth usage > x
         +-- port N is up
         +-- TTL < y
    +-- action
         +-- adjust flow
         +-- use backup link
         +-- retry

Thank you,
Tina

_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 10 Feb 2015 07:04:40 -0800

Hi Bob,

interesting question. I think that it depends on how one defines "intent".
For me, intent is a declarative style of expression, while ECA is not. So,
if you look in (for example) the ZOOM or DEN-ng models, ECA is one type of
policy rule, but intent (called GoalPolicy) is a sibling class. (And for
fun, we defined two additional siblings: UtilityFunctionPolicy and
PromisePolicy).

best,
John

On Tue, Feb 10, 2015 at 6:33 AM, Natale, Bob <[email-masked]> wrote:

> Could “Condition” be extended to incorporate possible intersection with
> “Intent” … i.e., can we marry Intent-Driven and ECA on Condition … or do
> you see them as mutually exclusive …?
>
>
>
> Or does Intent-Driven simply subsume ECA as an implementation approach at
> a “lower” level (i.e., closer to the managed resource)?
>
>
>
> Or something else?
>
>
>
> I believe that from a practical perspective many such implementation
> options are possible … but I am curious about the “right” formal
> relationships for reliable and efficient specification going forward.
>
>
>
> Avanti,
>
> BobN
>
>
>
> *From:* Supa [mailto:[email-masked]] *On Behalf Of *John Strassner
> *Sent:* Tuesday, February 10, 2015 9:12 AM
> *To:* Tina TSOU; John Strassner
> *Cc:* [email-masked]
> *Subject:* Re: [Supa] ECA policy model definition
>
>
>
> Hi Tina,
>
>
>

-- 
regards,
John

---

From: Dan Martin <[email-masked]>
Date: Tue, 10 Feb 2015 16:27:40 +0000

From what I’ve seen around policy definition efforts, no matter where you start you end up with  “policies are whatever I say they are”, so an approach that provides for the stuff john points out, intent, function, and promise, seems more complete to me.  I think the ECA work is a good and necessary place to start, but . . .

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, February 10, 2015 10:05 AM
To: Natale, Bob; John Strassner
Cc: [email-masked]; Tina TSOU
Subject: Re: [Supa] ECA policy model definition

Hi Bob,

interesting question. I think that it depends on how one defines "intent". For me, intent is a declarative style of expression, while ECA is not. So, if you look in (for example) the ZOOM or DEN-ng models, ECA is one type of policy rule, but intent (called GoalPolicy) is a sibling class. (And for fun, we defined two additional siblings: UtilityFunctionPolicy and PromisePolicy).

best,
John

On Tue, Feb 10, 2015 at 6:33 AM, Natale, Bob <[email-masked]<mailto:[email-masked]>> wrote:
+1, and a further (perhaps just personal edification) question for John:

Or something else?

Avanti,
BobN

From: Supa [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Strassner
Sent: Tuesday, February 10, 2015 9:12 AM
To: Tina TSOU; John Strassner
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Supa] ECA policy model definition

Hi Tina,

regards,
John

E.g. If(a>10)  then b++;

Policy
    +--event
         +-- bandwidth usage
         +-- port N status
         +-- TTL value
    +-- condition
         +-- bandwidth usage > x
         +-- port N is up
         +-- TTL < y
    +-- action
         +-- adjust flow
         +-- use backup link
         +-- retry

Thank you,
Tina

--
regards,
John

--
regards,
John

---

From: "Huangyong (Oliver)" <[email-masked]>
Date: Wed, 11 Feb 2015 01:17:16 +0000

John,

      The definition you provide is accurate and elegant.  I agree with you.

BR
Oliver

---------------------------
Huangyong (Oliver)
Network research, Huawei

From: Supa [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, February 10, 2015 10:12 PM
To: Tina TSOU; John Strassner
Cc: [email-masked]
Subject: Re: [Supa] ECA policy model definition

Hi Tina,

regards,
John

E.g. If(a>10)  then b++;

Policy
    +--event
         +-- bandwidth usage
         +-- port N status
         +-- TTL value
    +-- condition
         +-- bandwidth usage > x
         +-- port N is up
         +-- TTL < y
    +-- action
         +-- adjust flow
         +-- use backup link
         +-- retry

Thank you,
Tina

--
regards,
John

---

From: Dave Duggal <[email-masked]>
Date: Tue, 24 Feb 2015 18:24:34 +0000

I’m just catching up on the SUPA ListServ after a few weeks of travel and saw Bob Natale’s comment below re: Intent/ECA - Yes, these concepts can be ‘married’ (don’t need discrete components/methods).

We have a high-level object abstraction for managing multi-factor constraint satisfaction over diverse and distributed end-points.

It enables intent to be declaratively described in policy independent of implementation details (technologies, protocols, methods, etc.). It’s based on real-time interpretation of Objects as nested models, each declaring its constraints and assertions. It supports compositions of objects to form linked information models. In short, we use graphs for a flexible, dynamic and arbitrarily extensible application fabric (objects, events, relationships, policies, tasks) making them tractable for distributed transactions / smart, agile processes.

We are members of the TMF and contributed a related metamodel for our “CloudNFV” Catalyst project (it won “Most Innovative” at TMF Live last June). It’s deployed in Carrier labs and the same technology is running human, system and infrastructure processes in other domains too supporting dynamically integrated operations generally.

I support the architectural Top-Down approach espoused by John and Bob.

I’d be happy to brief any interested parties.

Best,
Dave

_________________________
Dave Duggal,

Founder / Managing Director
EnterpriseWeb LLC

+1 (646) 502-8062 x444
www.enterpriseweb.com<http://www.enterpriseweb.com/>

From: Supa [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Tuesday, February 10, 2015 9:34 AM
To: John Strassner; Tina TSOU
Cc: [email-masked]
Subject: Re: [Supa] ECA policy model definition

Or something else?

Avanti,
BobN

Hi Tina,

regards,
John

E.g. If(a>10)  then b++;

Policy
    +--event
         +-- bandwidth usage
         +-- port N status
         +-- TTL value
    +-- condition
         +-- bandwidth usage > x
         +-- port N is up
         +-- TTL < y
    +-- action
         +-- adjust flow
         +-- use backup link
         +-- retry

Thank you,
Tina

--
regards,
John