Subject: [Anima] Not the Intents we were looking for: SUPA Intents

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Aug 2015 15:50:22 -0400

{intentionally not cross-posted to SUPA}

While working on other things today (and being at home with a pink-eyed kid),
I found the tab that was open to watch the IETF93 SUPA BOF.

I also had saved ~80 emails from the SUPA list to read.
I found that the use cases from the SUPA BOF do not really match how we
envision Intents to work with ANIMA ASAs.  In particular, the model that
is envisioned is far more SDN-like; that is with a uber-intelligent
centralized command and control system that interprets SUPA Intents into
things like Virtual Private Cloud (VPC/VPN) configurations, via various
things like YANG/NETCONF/RESTCONF models, (but probably other data models)

It isn't clear to me if SUPA Intents are going to be designed to cross-AS
boundaries, but it seems like they could easily do this.

It seems like the ANIMA ACP is critically important for SUPA to be able to
implement policies, but that's an operator convenience.  They could equally
well use other (more expensive!) management networks.

In the recording, I heard various things about ANIMA... I don't think
anyone overstated the situation, but I think that the message that ANIMA
Intents != SUPA Intents was too understated.

Bert Wijnen (didn't he declare he was retired?) points on the list to
     IBNEMO - https://www.ietf.org/mailman/listinfo/ibnemo

There was a SUPA telecon yesterday morning, but I had a nomcom call,
so I missed it.  It seems that there ought to be significant overlap,
and yet I don't see it.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Aug 2015 08:12:42 +1200

> I found the tab that was open to watch the IETF93 SUPA BOF.

I didn't do that, but having looked at the SUPA minutes, I then looked
at the IBNEMO documents, which make more sense to me than SUPA.
However, both IBNEMO and SUPA are definitely in the top/down north/south
configuration management tradition.

> Intents != SUPA Intents was too understated.

Agreed, judging by the documents. Anyway it seems clear that SUPA is
not yet ready to get chartered.

> Bert Wijnen (didn't he declare he was retired?) 

Well yes, but as I told him when he said that, retirement often
doesn't work first time ;-).

> points on the list to

I don't see much overlap with SUPA.

If IBNEMO comes up with a good data model and syntax for expressing
intent, we should consider using it. I guess one of the authors of
draft-zhou-netmod-intent-nemo and draft-xia-sdnrg-nemo-language
can advise us about that. But actually the Nemo intent language looks
more specific than I expect Anima intent to be: compare with
draft-du-anima-an-intent and
https://tools.ietf.org/html/draft-jiang-anima-prefix-management-01#section-5.1

    Brian

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 19 Aug 2015 08:57:06 +0000

Hi Brian,

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Tuesday, August 18, 2015 11:13 PM
> To: Michael Richardson; [email-masked]

....

> > anyone overstated the situation, but I think that the message that
> > ANIMA Intents != SUPA Intents was too understated.
> 
> Agreed, judging by the documents 

Actually the SUPA BOF minutes (draft minutes at this point) recorded: 

----

* Jabber question, Laurent:  gap analysis relative to the ANIMA activity?  Intent is being used there - similar to what is being described here.
* Anima chair - Sheng Jiang: intent not yet in the charter.  Thinks it is quite different - no overlap
* John explained this with a motivating example.

----

The difference between ANIMA Intents and SUPA Intents (they are called declarative policies there) was clearly expressed by both the ANIMA chair and by John Strassner who authored the SUPA policy IM document. Do you believe that this is not clearly enough expressed in the minutes, or maybe you refer other documents? 

> Anyway it seems clear that SUPA is not
> yet ready to get chartered.
>

Your input on the SUPA readiness or not is welcome on the SUPA mail list. 

Thanks and Regards,

Dan
(SUPA BOF co-chair)

---

From: John Strassner <[email-masked]>
Date: Wed, 19 Aug 2015 13:59:43 -0700

Hi Michael,

I've been involved in SUPA, but also in ANIMA; here is my perspective:

> I found that the use cases from the SUPA BOF do not really match
> how we envision Intents to work with ANIMA ASAs.

<jcs>
I'm not sure what is envisioned with intent in ANIMA; I have
previously posted that I don't think that there is enough
detail on what intent is and what it is supposed to do in ANIMA.
</jcs>

> In particular, the model that is envisioned is far more SDN-like;
> that is with a uber-intelligent centralized command and control
> system that interprets SUPA Intents into things like Virtual Private
> Cloud (VPC/VPN) configurations, via various things like
> YANG/NETCONF/RESTCONF models, (but probably other
> data models)

<jcs>
I'm personally not a big SDN fan for a number of reasons, and at
least in the I-Ds that I've written for SUPA, that is far from the
vision that I have had. But this is just my opinion; others may differ.

SUPA defines an information model (i.e., a model that is
independent of language, protocol, and repository) that consists
of three pieces:

   1) generic policy concepts (e.g., the target of a policy, and
       how policy is represented and structured)
   2) an imperative model (i.e., event-condition-action) that is
       derived from (1)
   3) a declarative model (i.e., propositional or first order logic)
       that is also derived from (1)

This structure enables sets of policies to be defined, where a
declarative policy could then trigger the evaluation of
declarative and/or imperative policies, and vice-versa.

I **think** that in ANIMA, the assumption has been that intent
should be declarative in nature. Please correct me if I am wrong.
Please also realize that SUPA is both more than this, and
models declarative policy as formal logic. This has a large
number of advantages, especially for autonomics; please let
me know if these are not obvious.
</jcs>

> It isn't clear to me if SUPA Intents are going to be designed
> to cross-AS boundaries, but it seems like they could easily
> do this.

<jcs>
Indeed, they are. In my policy work, there is the concept of a
policy domain, which is any domain whose entities are
governed by a common set of policies. So the concept is
actually broader than just ASs.
</jcs>

> It seems like the ANIMA ACP is critically important for
> SUPA to be able to implement policies, but that's an
> operator convenience.  They could equally well use other
> (more expensive!) management networks.

<jcs>
Michael Behringer and I (and others, but I'm old so I have
now forgotten who, sorry!) talked about this at IETF92.
FOCALE (my autonomic architecture) chose the latter
(mainly because ACP did not exist!) and I reflected that I
wished I had thought of doing something like ACP. I feel
that this would have made FOCALE more powerful and
robust.
</jcs>

> In the recording, I heard various things about ANIMA...
> I don't think anyone overstated the situation, but I think
> that the message that ANIMA Intents != SUPA Intents
> was too understated.

<jcs>
I have not seen ANIMA intent formally defined. I think it
would be interesting to determine first, if ANIMA intent
should use declarative logic or not (besides SUPA,
ONF, OpenStack Congress, and to an extent, ODL GBP
all use declarative logic), and second, if ANIMA intent
is not going to use declarative logic, then why not?
</jcs>

>    IBNEMO - https://www.ietf.org/mailman/listinfo/ibnemo

<jcs>
Note that NEMO says that they are defining a declarative
policy, but in reality, NEMO implements this with imperative
(i.e., condition-action) constructs.
</jcs>

> It seems that there ought to be significant overlap, and
> yet I don't see it.

<jcs>
IF ANIMA intent decides to use declarative logic or
imperative logic (in the form of event-condition-action), then I
would hope that the two indeed overlap. However, until
ANIMA formally defines what intent is, it is impossible to say.
</jcs>

regards,
John

On Tue, Aug 18, 2015 at 12:50 PM, Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 19 Aug 2015 14:13:59 -0700

Hi Brian,

> I didn't do that, but having looked at the SUPA minutes, I then
> looked at the IBNEMO documents, which make more sense to
> me than SUPA.

<jcs>
I'd like to know why. This could actually help both SUPA and NEMO.
</jcs>

> However, both IBNEMO and SUPA are definitely in the top/down
> north/south configuration management tradition.

<jcs>
As opposed to what?
</jcs>

> I don't see much overlap with SUPA.

<jcs>
I'd like to know why. Is this because you don't envision using ECA
or logic rules, or some other reason?
</jcs>

> But actually the Nemo intent language looks more specific
> than I expect Anima intent to be: compare with

<jcs>
Please see my earlier reply to Michael Richardson.
One could argue that this example is not "intent" as defined by ONF,
ODL GBP, OpenStack Congress, or SUPA's declarative logic
(though SUPA's ECA policy rule could easily express this). This is
because in other declarative designs, those SDOs have decided
that intent should NOT specify low-level parameters like IP
addresses or port numbers or DSCPs. That of course doesn't
mean that ANIMA couldn't do this, but it would mean that ANIMA's
intent model diverges from the industry.

This also clearly influences the underlying data model that you choose.
</jcs>

regards,
John

-- 
regards,
John

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Thu, 20 Aug 2015 00:22:50 +0000

Does supa have opinions about the reaction time of imperative logic ? If it wants to support fast reaction, that would then imply the logic has to run in eg: the routers as opposed to an sdn controller.

I am also not sure i could decide between declarative and imperative... is an acces list imperative ? Is the name of a well known access list declarative ?

Toerless

Sent from my Samsung Captivate Glide on AT&T

John Strassner <[email-masked]> wrote:
Hi Michael,

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

regards,
John

On Tue, Aug 18, 2015 at 12:50 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-

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

--
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Aug 2015 14:00:02 +1200

Hello John,

> I'd like to know why. This could actually help both SUPA and NEMO.

To be blunt, I found a clear statement of purpose in Sue's draft
(draft-hares-ibnemo-overview) and I have never found that for SUPA except
in language that is too abstract for my thought processes.

>> north/south configuration management tradition.

Interactions between autonomic service agents (ASAs) are peer-to-peer;
there is no assumed hierarchy. Even intent could in theory come from
anywhere (anywhere authorized, that is) although we tend to assume it
will come from a NOC.

> or logic rules, or some other reason?

I could imagine a particular ASA or group of collaborating ASAs
that are designed to use SUPA, for whatever their purpose in life
is. We have to co-exist with traditional NMS methods, and with
NETCONF, so why not with SUPA too?

> intent model diverges from the industry.

It's possible. Personally I want to put myself in the shoes of a NOC
operator or a network designer and ask: what does she want to tell or
authorize the network to do? That will set the level of abstraction or
detail in intent statements.

> This also clearly influences the underlying data model that you choose.

Well, if the syntax is sufficiently flexible, we should be able to
cope with a wide range of levels of abstraction. As for declarative
vs imperative, I think it's too soon to know for sure, but my feeling
is that we will find use cases that need both.

Rgds
   Brian

---

From: Duzongpeng <[email-masked]>
Date: Thu, 20 Aug 2015 02:17:14 +0000

Hi John,

         Some personal understanding to share.

         Although sharing the name “intent”, SUPA intent and ANIMA intent have different motivations and ways to define intent.

         SUPA intent begins with a common information model, while the ANIMA intent will likely be defined by using some use cases first.

         Furthermore, the aim of autonomic is to make intent as less as possible, and as simple as possible to ease the network management jobs.

         ANIMA intent will increase bit-by-bit while the autonomic service agents are being defined bit-by-bit.

IMO, any input from the operator to make the network more autonomic can be considered as an “intent” in ANIMA.

         Currently, perhaps because the use cases are not too many, I do not find too much overlap between SUPA intent and ANIMA intent.

         My suggestion is to develop them separately unless clear evidence is found that autonomic network needs the information model defined in SUPA.

Best Regards
Zongpeng Du

From: Anima [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, August 20, 2015 5:14 AM
To: Brian E Carpenter; John Strassner
Cc: Michael Richardson; Anima WG
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Hi Brian,

<jcs>

<jcs>
As opposed to what?
</jcs>

<jcs>

<jcs>

regards,
John

On Tue, Aug 18, 2015 at 1:12 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

    Brian

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 19 Aug 2015 19:52:35 -0700

Hi Toerless,

I don't think it is that simple, unfortunately. Let's say that a NOC
operator wants to issue something like the following:

   "Any CPU in any VM whose utilization is > 70% should be
    load-balanced."

The imperative version is, well, ugly:

   1) First, you have to translate what this means into a form
       that a device could consume. This isn't particularly hard
       in this example, but it still has to be done.
   2) If the policy repository did not have a matching rule,
       then you have to build one. But, how do you find every
       device that should be affected? Even if we change the
       rule to make it more explicit (e.g., s./CPU/router CPU),
       this is a nightmare, because you now need to look at
       the topology and build n of these rules just to do the
       check, and some smaller number to do the load-balancing.
   3) If the policy repository does have matches, how do you
       know that they cover all of the cases?

In contrast, the declarative version is trivial: just do a distributed
transitive closure which finds all of the devices that meet the
criteria, and then apply the load balancing to this set.

So, in theory, you could use declarative to identify what
devices you could then apply imperative policies to.

In contrast, setting an ACL would be trivial with imperative,
but much more difficult with declarative (because you would
have to translate the declarative policy to something the
device could consume).

This is likely one reason I have gray hair.

regards,
John

On Wed, Aug 19, 2015 at 5:22 PM, Toerless Eckert (eckert) <[email-masked]>
wrote:

> Does supa have opinions about the reaction time of imperative logic ? If
> it wants to support fast reaction, that would then imply the logic has to
> run in eg: the routers as opposed to an sdn controller.
>
> I am also not sure i could decide between declarative and imperative... is
> an acces list imperative ? Is the name of a well known access list
> declarative ?
>
> Toerless
>
>
>
>
> On Tue, Aug 18, 2015 at 12:50 PM, Michael Richardson <
> [email-masked]> wrote:
>
>>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 19 Aug 2015 20:02:51 -0700

Hi Brian,

please see <jcs2/>. I'm on a mailer with limited capabilities, so
please excuse the verbosity...

<jcs2>
Does the following help:
>From the abstract of draft-klyus-supa-proposition-02:
   Simplified Use of Policy Abstractions (SUPA) defines an interface
   to a network management function that takes high-level, possibly
   network-wide policies as input and creates element configuration
   snippets as output. SUPA expresses policies using a generic policy
   information model, and outputs generic YANG data models.
</jcs2>

<jcs2>
Yup, this is how FOCALE worked. If you think that SUPA implies a
hierarchy, then that is bad and it should be fixed.
</jcs2>

<jcs>
Indeed, ANIMA should be able to handle other types of policies,
not just those of SUPA.
</jcs>

<jcs2>
I absolutely agree with this. In fact, this is why I stood up in the SUPA
BoF and said that SUPA intent is different than ANIMA, mainly because
ANIMA intent is not yet formally defined. But since ANIMA intent is
not yet formally defined, I don't understand why people immediately
conclude that ANIMA is different from SUPA.

Note that I am not arguing whether ANIMA intent should be different
than SUPA intent (or not); I am simply saying that you cannot compare
something that is not formally defined to anything else.
</jcs2>

<jcs2>
SUPA is (at least right now) envisioned as primarily an effort in modeling.
I have posted on SUPA that a model, all by its lonesome, does NOT
provide any type of policy management solution. A data model is just
a set of data structures, it lacks the logic requirement to implement the
policy. I've also posted that a DSL whose nouns and verbs are
defined by an info model is likely what is needed.

 Rgds
   Brian

regards,
John

On Wed, Aug 19, 2015 at 7:00 PM, Brian E Carpenter <
[email-masked]> wrote:

> ANIMA

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 20 Aug 2015 08:58:31 +0000

To me it is clear that ANIMA Intent is declarative. It describes the desired outcome, not the way to get to it. That’s exactly what Autonomics is all about, in fact. Different devices have different way to achieve things, different capabilities. In an imperative approach those different ways and capabilities would have to be expressed.

The reason the industry is having trouble with ACL management is exactly because it is imperative. It’s just the wrong approach for most use cases.

Autonomics aims to abstract away device specifics and to provide one higher level view of the network. That’s exactly the declarative approach. I really hope we have agreement on that.

Disclaimer: For practical reasons (device capabilities) it may well be required for some time to do some hacks in Intent that are imperative. As long as we all understand it’s a temporary hack, and are explicit about it, that’s ok.

So, do we agree that Intent is declarative? Any objections? We should really get agreement on that…

Michael

From: Anima [mailto:[email-masked]] On Behalf Of John Strassner
Sent: 20 August 2015 04:53
To: Toerless Eckert (eckert); John Strassner
Cc: Michael Richardson; Anima WG
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Hi Toerless,

regards,
John

On Wed, Aug 19, 2015 at 5:22 PM, Toerless Eckert (eckert) <[email-masked]<mailto:[email-masked]>> wrote:
Does supa have opinions about the reaction time of imperative logic ? If it wants to support fast reaction, that would then imply the logic has to run in eg: the routers as opposed to an sdn controller.

Toerless

John Strassner <[email-masked]<mailto:[email-masked]>> wrote:
Hi Michael,

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

regards,
John

--
regards,
John

--
regards,
John

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Thu, 20 Aug 2015 10:18:28 +0000

Why not allow both declarative and imperative in the structure of ANIMA and the delivery through and by the ACP and GRASP.
How the Intent is then used by the end node is up to the developer of that node at that point.
The node could be developed to only digest declarative or always allow declarative and only imperative for a discreet set of items that it supports in that regard.

--
Jason Coleman CCIE#12069
[email-masked]<mailto:[email-masked]>
phone: +1 512-340-3134
Technical Lead Engineer CMS

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

From: Anima on behalf of "Michael Behringer (mbehring)"
Date: Thursday, August 20, 2015 at 3:58 AM
To: John Strassner, "Toerless Eckert (eckert)"
Cc: Michael Richardson, Anima WG
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Michael

Hi Toerless,

regards,
John

Toerless

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

regards,
John

--
regards,
John

--
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 20 Aug 2015 10:53:53 +0000

My view: Let’s keep intent purely declarative. If you need to support imperative concepts, do this through traditional methods, like CLI, netconf, etc.

Imperative says: Device x, do y. To me, that is not autonomic. And we shouldn’t pretend it is.

Now, this is a bit of a purist view, and I’ve heard comments along the lines: “well, if we have this nice Intent concept, we want to use it for everything”. I’d rather keep it separate, but that is just a personal opinion of course ☺  (A strong one though! ☺

Michael

From: Jason Coleman (colemaj)
Sent: 20 August 2015 12:18
To: Michael Behringer (mbehring); John Strassner; Toerless Eckert (eckert)
Cc: Michael Richardson; Anima WG
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Michael

Hi Toerless,

regards,
John

Toerless

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

regards,
John

--
regards,
John

--
regards,
John

---

From: Duzongpeng <[email-masked]>
Date: Thu, 20 Aug 2015 11:29:20 +0000

Hi Michael Behringer:

I agree that declarative intent has advantages.

But IMO, in the beginning, we should start defining intent using the simplest way no matter the intent is imperative or declarative.

         Perhaps in future, when the autonomic node is intelligent enough to understand the declarative intent, we can replace all the imperative ones.

However in this time, we should not preclude imperative intents.

Of course, in your example, “Device x, do y”, this kind of Imperative intent should be avoided.

Best Regartds
Zongpeng Du

From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer (mbehring)
Sent: Thursday, August 20, 2015 6:54 PM
To: Jason Coleman (colemaj); John Strassner; Toerless Eckert (eckert)
Cc: Michael Richardson; Anima WG
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Michael

Michael

Hi Toerless,

regards,
John

Toerless

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

regards,
John

--
regards,
John

--
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 20 Aug 2015 12:03:08 +0000

Probably we need to decide on a case-by-case basis. If (!) we allow imperative statements (I’d still like to see why we couldn’t do it declarative first), I’d like a way to separate them out logically in the structure of whichever encoding we’ll use. At least we can then keep the “clean” Intent separate from temporary workarounds.

Michael

From: Duzongpeng [mailto:[email-masked]]
Sent: 20 August 2015 13:29
To: Michael Behringer (mbehring); Jason Coleman (colemaj); John Strassner; Toerless Eckert (eckert)
Cc: Michael Richardson; Anima WG
Subject: RE: [Anima] Not the Intents we were looking for: SUPA Intents

Hi Michael Behringer:

Best Regartds
Zongpeng Du

Michael

Michael

Hi Toerless,

regards,
John

Toerless

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

regards,
John

--
regards,
John

--
regards,
John

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Thu, 20 Aug 2015 07:32:37 -0700

The question really is what the requirements are to
support us trying to have an opinion about intent (in anima).

Systems to build more intelligent networks start to incooperate
a whole slew of layers/concepts and intent is thrown around
everywhere. Then you have big data and intent is expressed in that
context, and you have semantic reasoners trying to fulfill intent
and so on and so forth.

IMHO, anima would do well try to figure out what problems exist outside
anima in the IETF and how anima can help. In the same was as more
shorter term in bootstrap, this could longer term (re-chartering)
apply to stuff around intent.

IMHO, it seems we already want to break up a system into components
we call ASAs, and Laurent has started to explain in his draft
how multiple ASA need coordination, and the way i read it, that
would come through appropriate declarative information that lays
out eg: dependencies,which can then be resolved. I am not sure
if these dependencies are intent, but they are clearly important
declarative informatoin we need to tackle once we deal with ASAs.

Cheers
    Toerless

On Thu, Aug 20, 2015 at 12:03:08PM +0000, Michael Behringer (mbehring) wrote:
> Probably we need to decide on a case-by-case basis. If (!) we allow imperative statements (I???d still like to see why we couldn???t do it declarative first), I???d like a way to separate them out logically in the structure of whichever encoding we???ll use. At least we can then keep the ???clean??? Intent separate from temporary workarounds.
> 
> Michael
> 
> Of course, in your example, ???Device x, do y???, this kind of Imperative intent should be avoided.
> 
> Best Regartds
> Zongpeng Du
> 
> 
> My view: Let???s keep intent purely declarative. If you need to support imperative concepts, do this through traditional methods, like CLI, netconf, etc.
> 
> Imperative says: Device x, do y. To me, that is not autonomic. And we shouldn???t pretend it is.
> 
> Now, this is a bit of a purist view, and I???ve heard comments along the lines: ???well, if we have this nice Intent concept, we want to use it for everything???. I???d rather keep it separate, but that is just a personal opinion of course ???  (A strong one though! ???
> 
> Michael
> 
> To me it is clear that ANIMA Intent is declarative. It describes the desired outcome, not the way to get to it. That???s exactly what Autonomics is all about, in fact. Different devices have different way to achieve things, different capabilities. In an imperative approach those different ways and capabilities would have to be expressed.
> 
> The reason the industry is having trouble with ACL management is exactly because it is imperative. It???s just the wrong approach for most use cases.
> 
> Autonomics aims to abstract away device specifics and to provide one higher level view of the network. That???s exactly the declarative approach. I really hope we have agreement on that.
> 
> Disclaimer: For practical reasons (device capabilities) it may well be required for some time to do some hacks in Intent that are imperative. As long as we all understand it???s a temporary hack, and are explicit about it, that???s ok.
> 
> So, do we agree that Intent is declarative? Any objections? We should really get agreement on that???
> 
> Michael
> 

-- 
---
Toerless Eckert, [email-masked]

---

From: John Strassner <[email-masked]>
Date: Thu, 20 Aug 2015 07:54:57 -0700

> Although sharing the name “intent”, SUPA intent and ANIMA intent
> have different motivations and ways to define intent.

<jcs>
That will likely confuse people that are not part of ANIMA. Note that in
SUPA,
I try and avoid using the word "intent", because it is used differently in
different SDOs. In SUPA, I call it declarative logic. However, ONF,
OpenStack
Congress, and ODL call it intent.
</jcs>

>        SUPA intent begins with a common information model, while the
>        ANIMA intent will likely be defined by using some use cases first.

<jcs>
SUPA had a large number of use cases, most from operators. The reason
we define an information model is because of 2 reasons:
   1) we envisioned the translation to multiple data models, and
   2) I wanted an information model to build definitions for various
       parts of a language (e.g., nouns and verbs) if we did a DSL

More importantly, SUPA is NOT an "information model of the world."
SUPA is JUST an information model that defines policy.
</jcs>

 >        Furthermore, the aim of autonomic is to make intent as less as
>         possible, and as simple as possible to ease the network
>         management jobs.

<jcs>
You lost me. Why does something as complex as autonomics require
a simple policy?

If you want simplicity, then the easiest way to build that is to have
a model that facilitates translation from some high-level form
to an intermediate form that the system understands.
</jcs>

 >        ANIMA intent will increase bit-by-bit while the autonomic
>         service agents are being defined bit-by-bit.

<jcs>
An information model enables the representation and definition of
policy to grow with time. It seems to me that since you haven't
defined what your policy is, an information model would help.
</jcs>

>       IMO, any input from the operator to make the network more autonomic
can be considered as an “intent” in ANIMA.

>       Currently, perhaps because the use cases are not too many, I do not
find too much overlap between SUPA intent and ANIMA intent.

>       My suggestion is to develop them separately unless clear evidence
is found that autonomic network needs the information model defined in SUPA.
<jcs>
There are plenty of use cases in SUPA, or did you mean ANIMA?
</jcs>

regards,
John

On Wed, Aug 19, 2015 at 7:17 PM, Duzongpeng <[email-masked]> wrote:

>          Although sharing the name “intent”, SUPA intent and ANIMA intent
> have different motivations and ways to define intent.
>
>
>
>          SUPA intent begins with a common information model, while the
> ANIMA intent will likely be defined by using some use cases first.
>
>
>
>          Furthermore, the aim of autonomic is to make intent as less as
> possible, and as simple as possible to ease the network management jobs.
>
>
>
>          Currently, perhaps because the use cases are not too many, I do
> not find too much overlap between SUPA intent and ANIMA intent.
>
>
>
>          My suggestion is to develop them separately unless clear evidence
> is found that autonomic network needs the information model defined in SUPA.
>
>
>
> Best Regards
>
> Zongpeng Du
>
>
>
> *From:* Anima [mailto:[email-masked]] *On Behalf Of *John
> Strassner
> *Sent:* Thursday, August 20, 2015 5:14 AM
> *To:* Brian E Carpenter; John Strassner
> *Cc:* Michael Richardson; Anima WG
> *Subject:* Re: [Anima] Not the Intents we were looking for: SUPA Intents
>
>
>
> Hi Brian,
>
>
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 20 Aug 2015 08:16:04 -0700

I absolutely agree.
However, note that SUPA (and TMF ZOOM, and DEN-ng) all share the same
design:

   There is an abstract top layer that defines common policy concepts
   There are then two sub-layers (in SUPA, 4 in DEN-ng) that define
imperative and declarative policy

This enables declarative to call imperative, and vice-versa, because they
share common concepts, representation, and structure.

In my vision, the top-level of the policy continuum is declarative. That's
because the actor is either a user or an operator. Lower levels have
different actors (e.g., app developers or device admins) whose job is to
translate intent to implement policy.

Even after 18 years, I also believe that the Policy Continuum is a vital
part of autonomics. However, let's agree on declarative first. :-)

regards,
John

On Thu, Aug 20, 2015 at 1:58 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> To me it is clear that ANIMA Intent is declarative. It describes the
> desired outcome, not the way to get to it. That’s exactly what Autonomics
> is all about, in fact. Different devices have different way to achieve
> things, different capabilities. In an imperative approach those different
> ways and capabilities would have to be expressed.
>
>
>
> The reason the industry is having trouble with ACL management is exactly
> because it is imperative. It’s just the wrong approach for most use cases.
>
>
>
> Autonomics aims to abstract away device specifics and to provide one
> higher level view of the network. That’s exactly the declarative approach.
> I really hope we have agreement on that.
>
>
>
> Disclaimer: For practical reasons (device capabilities) it may well be
> required for some time to do some hacks in Intent that are imperative. As
> long as we all understand it’s a temporary hack, and are explicit about it,
> that’s ok.
>
>
>
> *Sent:* 20 August 2015 04:53
> *To:* Toerless Eckert (eckert); John Strassner
> On Wed, Aug 19, 2015 at 5:22 PM, Toerless Eckert (eckert) <
> [email-masked]> wrote:
>
> > Bert Wijnen (didn't he declare he was retired?) points
>
> > on the list to

-- 
regards,
John

---

From: "Natale, Bob" <[email-masked]>
Date: Thu, 20 Aug 2015 15:20:19 +0000

[Lurker alert!]

John just wrote on a related posting:
"If you want simplicity, then the easiest way to build that is to have a model that facilitates translation from some high-level form to an intermediate form that the system understands."

Simplicity is required. The model that facilitates translation is required because that is the way the world works from (declarative) high-level business policies to (imperative) executable configuration. The Policy Continuum is one such translation model that I will use for reference purposes here.

One potential problem I see with this overall discussion (not Toerless' posting immediately below, which is very helpful in my judgment) is that the matter of declarative and imperative policies is not, in the general end-to-end PBM case, an either/or situation:

   - Imperative is needed at the policy execution endpoint (roughly the "device" and "instance" views of the policy continuum) -- even though that might be "hidden" to a greater or lesser degree.

   - Declarative is needed at the policy creation point (roughly the "business", "system", and "admin" views of the policy continuum).

The "dividing line" in the middle of the continuum is not clear-cut ... it is very jagged, with spikes of declarative going farther "down" and spikes of imperative going farther "up" ... but a lot more of the latter than the former. And that's the crux of the matter. We have never standardized declarative at the level that it is needed and pushing imperative too far up the continuum ultimately becomes counterproductive.

Autonomic solutions of any kind are attempts to shorten the distance between the declarative and imperative endpoints, usually via greater degrees of "hidden" stuff. Shortening that distance is a good thing but -- to be done correctly (esp. for uptake) -- depends (among other things) on (1) a solution to the declarative problem and (2) transparency on the imperative side.

We have never effectively standardized the declarative capability for policy-based network management (PBNM, using a very liberal meaning for "network management" here). That is a show-stopper requirement. If we don't do that, we will just produce a new breed of partial solutions, resulting ultimately in more fragmentation and operational inefficiency due mainly from the large "expression gap" between how business decision-makers think and speak and how network technologists think and build.

I was really hoping that SUPA would tackle the declarative problem head on and not confound things with the imperative problem as well. I am not convinced that there should be one standard model for both at this stage. Imperative technology is widely deployed already (and growing constantly) ... of necessity. We've been able to survive without enabling the declarative capability, but that has not produced optimal PBNM solutions -- by a long shot! -- and is becoming ever less tenable as the scope, scale, and pace of requirements continue to increase at growing rates.

Regardless, ANIMA needs the declarative solution that SUPA (and/or IBNEMO) will provide.

Avanti,
BobN

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Toerless Eckert (eckert)
Sent: Thursday, August 20, 2015 10:33 AM
To: Michael Behringer (mbehring) <[email-masked]>
Cc: Duzongpeng <[email-masked]>; Michael Richardson <[email-masked]>; Jason Coleman (colemaj) <[email-masked]>; Anima WG <[email-masked]>; John Strassner <[email-masked]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

The question really is what the requirements are to support us trying to have an opinion about intent (in anima).

Systems to build more intelligent networks start to incooperate a whole slew of layers/concepts and intent is thrown around everywhere. Then you have big data and intent is expressed in that context, and you have semantic reasoners trying to fulfill intent and so on and so forth.

IMHO, anima would do well try to figure out what problems exist outside anima in the IETF and how anima can help. In the same was as more shorter term in bootstrap, this could longer term (re-chartering) apply to stuff around intent.

IMHO, it seems we already want to break up a system into components we call ASAs, and Laurent has started to explain in his draft how multiple ASA need coordination, and the way i read it, that would come through appropriate declarative information that lays out eg: dependencies,which can then be resolved. I am not sure if these dependencies are intent, but they are clearly important declarative informatoin we need to tackle once we deal with ASAs.

Cheers
    Toerless

On Thu, Aug 20, 2015 at 12:03:08PM +0000, Michael Behringer (mbehring) wrote:
> So, in theory, you could use declarative to identify what devices you 
> could then apply imperative policies to.
> 
> In contrast, setting an ACL would be trivial with imperative, but much 
> more difficult with declarative (because you would have to translate 
> the declarative policy to something the device could consume).
> 
> > I found that the use cases from the SUPA BOF do not really match how 
> > we envision Intents to work with ANIMA ASAs.
> 
> <jcs>
> previously posted that I don't think that there is enough detail on 
> what intent is and what it is supposed to do in ANIMA.
> </jcs>
> 
> > YANG/NETCONF/RESTCONF models, (but probably other data models)
> 
> <jcs>
> I'm personally not a big SDN fan for a number of reasons, and at least 
> in the I-Ds that I've written for SUPA, that is far from the vision 
> that I have had. But this is just my opinion; others may differ.
> 
> SUPA defines an information model (i.e., a model that is independent 
> of language, protocol, and repository) that consists of three pieces:
> 
> declarative policy could then trigger the evaluation of declarative 
> and/or imperative policies, and vice-versa.
> 
> I **think** that in ANIMA, the assumption has been that intent should 
> be declarative in nature. Please correct me if I am wrong.
> Please also realize that SUPA is both more than this, and models 
> declarative policy as formal logic. This has a large number of 
> advantages, especially for autonomics; please let me know if these are 
> not obvious.
> </jcs>
> 
> > It isn't clear to me if SUPA Intents are going to be designed to 
> > cross-AS boundaries, but it seems like they could easily do this.
> 
> <jcs>
> Indeed, they are. In my policy work, there is the concept of a policy 
> domain, which is any domain whose entities are governed by a common 
> set of policies. So the concept is actually broader than just ASs.
> </jcs>
> 
> > It seems like the ANIMA ACP is critically important for SUPA to be 
> > able to implement policies, but that's an operator convenience.  
> > They could equally well use other (more expensive!) management 
> > networks.
> 
> <jcs>
> Michael Behringer and I (and others, but I'm old so I have now 
> forgotten who, sorry!) talked about this at IETF92.
> FOCALE (my autonomic architecture) chose the latter (mainly because 
> ACP did not exist!) and I reflected that I wished I had thought of 
> doing something like ACP. I feel that this would have made FOCALE more 
> powerful and robust.
> </jcs>
> 
> > I don't think anyone overstated the situation, but I think that the 
> > message that ANIMA Intents != SUPA Intents was too understated.
> 
> <jcs>
> I have not seen ANIMA intent formally defined. I think it would be 
> interesting to determine first, if ANIMA intent should use declarative 
> logic or not (besides SUPA, ONF, OpenStack Congress, and to an extent, 
> ODL GBP all use declarative logic), and second, if ANIMA intent is not 
> going to use declarative logic, then why not?
> </jcs>
> 
> Note that NEMO says that they are defining a declarative policy, but 
> in reality, NEMO implements this with imperative (i.e., 
> condition-action) constructs.
> </jcs>
> 
> > It seems that there ought to be significant overlap, and yet I don't 
> > see it.
> 
> <jcs>
> IF ANIMA intent decides to use declarative logic or imperative logic 
> (in the form of event-condition-action), then I would hope that the 
> two indeed overlap. However, until ANIMA formally defines what intent 
> is, it is impossible to say.
> </jcs>
> 
> regards,
> John
> 
> 
> While working on other things today (and being at home with a 
> pink-eyed kid), I found the tab that was open to watch the IETF93 SUPA BOF.
> 
> I found that the use cases from the SUPA BOF do not really match how 
> we envision Intents to work with ANIMA ASAs.  In particular, the model 
> that is envisioned is far more SDN-like; that is with a 
> uber-intelligent centralized command and control system that 
> interprets SUPA Intents into things like Virtual Private Cloud 
> (VPC/VPN) configurations, via various things like 
> YANG/NETCONF/RESTCONF models, (but probably other data models)
> 
> It isn't clear to me if SUPA Intents are going to be designed to 
> cross-AS boundaries, but it seems like they could easily do this.
> 
> It seems like the ANIMA ACP is critically important for SUPA to be 
> able to implement policies, but that's an operator convenience.  They 
> could equally well use other (more expensive!) management networks.
> 
> Michael Richardson 
> <[email-masked]<mailto:[email-masked]>>, Sandelman 
> Software Works  -= IPv6 IoT consulting =-
> 
> 
> 
>

---

From: "Natale, Bob" <[email-masked]>
Date: Thu, 20 Aug 2015 15:21:18 +0000

+1 (my related posting crossed in the mail).

Avanti,
BobN

From: Anima [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, August 20, 2015 11:16 AM
To: Michael Behringer (mbehring) <[email-masked]>; John Strassner <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Toerless Eckert (eckert) <[email-masked]>; Anima WG <[email-masked]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

I absolutely agree.
However, note that SUPA (and TMF ZOOM, and DEN-ng) all share the same design:

   There is an abstract top layer that defines common policy concepts
   There are then two sub-layers (in SUPA, 4 in DEN-ng) that define imperative and declarative policy

This enables declarative to call imperative, and vice-versa, because they share common concepts, representation, and structure.

In my vision, the top-level of the policy continuum is declarative. That's because the actor is either a user or an operator. Lower levels have different actors (e.g., app developers or device admins) whose job is to translate intent to implement policy.

Even after 18 years, I also believe that the Policy Continuum is a vital part of autonomics. However, let's agree on declarative first. :-)

regards,
John

On Thu, Aug 20, 2015 at 1:58 AM, Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>> wrote:
To me it is clear that ANIMA Intent is declarative. It describes the desired outcome, not the way to get to it. That’s exactly what Autonomics is all about, in fact. Different devices have different way to achieve things, different capabilities. In an imperative approach those different ways and capabilities would have to be expressed.

Michael

From: Anima [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Strassner

Hi Toerless,

regards,
John

Toerless

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

<jcs>

regards,
John

--
regards,
John

--
regards,
John

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 20 Aug 2015 08:25:30 -0700

Hi Jason,

this is exactly what SUPA provides.

That being said, I believe that there is a policy continuum: at the top of
the continuum, you have mostly declarative policies; at the bottom of the
continuum, you have low-level implementations that are mostly imperative
(or perhaps functional if it's an advanced device).

regards,
John

On Thu, Aug 20, 2015 at 3:18 AM, Jason Coleman (colemaj) <[email-masked]>
wrote:

> Why not allow both declarative and imperative in the structure of ANIMA
> and the delivery through and by the ACP and GRASP.
>
> The node could be developed to only digest declarative or always allow
> declarative and only imperative for a discreet set of items that it
> supports in that regard.
>
>
> --
> *Jason Coleman CCIE#12069*
> [email-masked] <[email-masked]>*
> phone: +1 512-340-3134
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
> *From:* Anima [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *John Strassner

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 20 Aug 2015 08:30:18 -0700

I disagree with Zongpeng and agree with Michael.

I don't understand how you can use one type of imperative statement and
allow others. This is like saying you can use a switch statement but not a
while statement.

I believe that you have a policy continuum, and declarative is mostly (or
all) at the top, where you need abstraction. It MAY be easier to express
other forms of commands (e.g., deontic logic) in a non-declarative way,
which is why I said "mostly". That being said, in the autonomic systems I
have built, it was 100% declarative at the top.

The risk with not having a purist view is that you end up with a really bad
language (and model).

regards,
John

On Thu, Aug 20, 2015 at 4:29 AM, Duzongpeng <[email-masked]> wrote:

> But IMO, in the beginning, we should start defining intent using the
> simplest way no matter the intent is imperative or declarative.
>
>
>
>          Perhaps in future, when the autonomic node is intelligent enough
> to understand the declarative intent, we can replace all the imperative
> ones.
>
>
>
> *From:* Anima [mailto:[email-masked]] *On Behalf Of *Michael
> Behringer (mbehring)
> *Sent:* Thursday, August 20, 2015 6:54 PM
> *To:* Jason Coleman (colemaj); John Strassner; Toerless Eckert (eckert)
> My view: Let’s keep intent purely declarative. If you need to support
> imperative concepts, do this through traditional methods, like CLI,
> netconf, etc.
>
>
>
> Now, this is a bit of a purist view, and I’ve heard comments along the
> lines: “well, if we have this nice Intent concept, we want to use it for
> everything”. I’d rather keep it separate, but that is just a personal
> opinion of course J  (A strong one though! J
>
>
>
> Michael
>
>
>
> *From:* Jason Coleman (colemaj)
> *Sent:* 20 August 2015 12:18
> *To:* Michael Behringer (mbehring); John Strassner; Toerless Eckert
> (eckert)
> *http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> <http://www.cisco.com/web/about/doing_business/legal/cri/index.html>*
>
>
>
>
>
> *From: *Anima on behalf of "Michael Behringer (mbehring)"
> *Date: *Thursday, August 20, 2015 at 3:58 AM
> *To: *John Strassner, "Toerless Eckert (eckert)"
> *Cc: *Michael Richardson, Anima WG
> *Subject: *Re: [Anima] Not the Intents we were looking for: SUPA Intents
>
>
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Aug 2015 08:24:04 +1200

One use case that we have buried in the Anima texts somewhere is
definitely imperative: an emergency shutdown of an ASA that is
misbehaving. You could argue that formally that is outside the
scope of autonomics itself, of course, but we'd look pretty silly
if our mechanism for sending out "instructions" from the NOC could
not include this one.

I do agree that in general autonomic intent should be declarative.

Regards
   Brian

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 20 Aug 2015 22:46:23 +0000

FWIW, from another another "lurker":-)

I clearly agree with Michael's earlier post.  Intent by its nature is declarative.  Imperative statements etc have their application, but they do not resemble intent and are something else, not intent.  

I find the word "intent" also a bit overused.  There is clearly a configuration hierarchy (device / network /service configuration), and my impression is that in some cases, where we talk about "intent", really what is being talked about is a network or a service configuration (which needs to be broken down into supporting device configurations and is abstracted from those, but not "intent").  

Whether the ACP can be used carry imperative statements in addition to intent can be debated; the use case is a good example of a case where this makes sense.  But just because it is carried over the ACP does not make an imperative statement "intent", IMHO.  

Cheers
--- Alex

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, August 20, 2015 1:24 PM
To: John Strassner <[email-masked]>; Duzongpeng <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Toerless Eckert (eckert) <[email-masked]>; Jason Coleman (colemaj) <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>; Anima WG <[email-masked]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

One use case that we have buried in the Anima texts somewhere is definitely imperative: an emergency shutdown of an ASA that is misbehaving. You could argue that formally that is outside the scope of autonomics itself, of course, but we'd look pretty silly if our mechanism for sending out "instructions" from the NOC could not include this one.

Regards
   Brian

On 21/08/2015 03:30, John Strassner wrote:
> I don't understand how you can use one type of imperative statement 
> and allow others. This is like saying you can use a switch statement 
> but not a while statement.
> 
> all) at the top, where you need abstraction. It MAY be easier to 
> express other forms of commands (e.g., deontic logic) in a 
> non-declarative way, which is why I said "mostly". That being said, in 
> the autonomic systems I have built, it was 100% declarative at the top.
> 
> The risk with not having a purist view is that you end up with a 
> really bad language (and model).
> 
> regards,
> John
> 
>>          Perhaps in future, when the autonomic node is intelligent 
>> enough to understand the declarative intent, we can replace all the 
>> imperative ones.
>>
>>
>>
>> lines: “well, if we have this nice Intent concept, we want to use it 
>> for everything”. I’d rather keep it separate, but that is just a 
>> personal opinion of course J  (A strong one though! J
>>
>>
>>
>> Michael
>>
>>
>>
>> Why not allow both declarative and imperative in the structure of 
>> ANIMA and the delivery through and by the ACP and GRASP.
>>
>> The node could be developed to only digest declarative or always 
>> allow declarative and only imperative for a discreet set of items 
>> that it supports in that regard.
>>
>>
>>
>> --
>>
>> This email may contain confidential and privileged material for the 
>> sole use of the intended recipient. Any review, use, distribution or 
>> disclosure by others is strictly prohibited. If you are not the 
>> intended recipient (or authorized to receive for the recipient), 
>> please contact the sender by reply email and delete all copies of this message.
>>
>> desired outcome, not the way to get to it. That’s exactly what 
>> Autonomics is all about, in fact. Different devices have different 
>> way to achieve things, different capabilities. In an imperative 
>> approach those different ways and capabilities would have to be expressed.
>>
>>
>>
>> The reason the industry is having trouble with ACL management is 
>> exactly because it is imperative. It’s just the wrong approach for most use cases.
>>
>>
>>
>> Disclaimer: For practical reasons (device capabilities) it may well 
>> be required for some time to do some hacks in Intent that are 
>> imperative. As long as we all understand it’s a temporary hack, and 
>> are explicit about it, that’s ok.
>>
>>
>>
>> *From:* Anima [mailto:[email-masked] 
>> <[email-masked]>] *On Behalf Of *John Strassner
>> Does supa have opinions about the reaction time of imperative logic ? 
>> If it wants to support fast reaction, that would then imply the logic 
>> has to run in eg: the routers as opposed to an sdn controller.
>>
>>
>>
>> I am also not sure i could decide between declarative and 
>> imperative... is an acces list imperative ? Is the name of a well 
>> known access list declarative ?
>>
>>
>>
>> Toerless
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> we envision Intents to work with ANIMA ASAs.  In particular, the 
>> model that is envisioned is far more SDN-like; that is with a

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 21 Aug 2015 01:28:59 +0000

Some clarifications regarding to intents in ANIMA WG with my chair hat on:

a) ANIMA does not have intents as chartered work item although we did mention intent in our charter description text.

It means we enough WG participators to discuss the intent and it usage in autonomic networks. Participators are encouraged to submit intent documents as individual drafts, discuss in mail list and apply time slots (giving priority to current chartered work items). But we are unlikely to do some formal work, like adopt intent documents, before rechartering, which it is not expected to happen before September 2016.

b) technically, if we included intent content in our next charter, what ANIMA would concentrate on should be the intent oriented autonomic networks rather than general intent. It mains: a) the intent should be able to understood and performed by every autonomic node, although how to execute on these nodes may be implementation specific, therefore out of ANIMA scope; b) since autonomic network would like to minimize the human input, so the ANIMA intent should carry only the necessary information from network administrators or network customers.

With the above understanding, my individual hat on, I think policy work that SUPA proposed is different from potential ANIMA intent. But when the time for ANIMA to work on ANIMA intent come, we may need to check what SUPA already provided. If something from SUPA are helpful, for example ANIMA intent may be a specific subset or sub-version of SUPA general policy, we may reuse it or start with it.

Best regards,

Sheng

>Sent: Wednesday, August 19, 2015 4:13 AM

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 21 Aug 2015 14:44:51 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 20 August 2015 22:24
> To: John Strassner; Duzongpeng
> Cc: Michael Richardson; Toerless Eckert (eckert); Jason Coleman (colemaj);
> Anima WG; Michael Behringer (mbehring)
> misbehaving. You could argue that formally that is outside the scope of
> autonomics itself, of course, but we'd look pretty silly if our mechanism for
> sending out "instructions" from the NOC could not include this one.

Very good example. And I agree that *autonomics* needs to provide a solution, but that solution doesn't have to be *Intent*.

So in my view, Intent tells an autonomic function "do the right thing" (very declarative, that!). If one of the ASAs of that autonomic function hangs, you solve that with "normal" management methods, for example ssh to that platform and issue a reset. Or, maybe we'll foresee a feedback loop for that purpose, later on. I think we can deal with it, but: it's not Intent. 
 
There is another reason why that particular transaction shouldn't be solved with Intent: To me, Intent has a long term scope. (Maybe that's an even better way to define it). A re-set of an ASA is a one-off. Not the right thing in a long-term policy. 

Maybe we need to define it through the backdoor:  Intent should be generic enough to be flooded through the network, so that every node gets a copy. That clearly doesn't make sense for short-lived actions. 

> I do agree that in general autonomic intent should be declarative.

That, I think we're all converging on. (Especially the "should" part of it ;-) 

Michael

> > really bad language (and :model).
> >
> > regards,
> > John
> >

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Fri, 21 Aug 2015 15:07:39 +0000

-----Original Message-----

>So in my view, Intent tells an autonomic function "do the right thing" (very declarative, that!). If one of the ASAs of that autonomic function hangs, you solve that with "normal" management methods…
	<JC> If we have an AN network with ACP and GRASP, why would we not want to use AN to ask the Node to perform a reset or some other action that is required?  If not called Intent that is fine, but I think that we have to provide a way for this type of communication</JC>

>There is another reason why that particular transaction shouldn't be solved with Intent: To me, Intent has a long term scope. (Maybe that's an even better way to define it). A re-set of an ASA is a…
	<JC> It appears to me that many people in the discussion have thoughts on WHAT Intent means to them, HOW Intent should be used, and WHAT Intent is NOT.  Do we have a definition of Intent that states the purpose of Intent and the scope that has consensus to back that definition?  Seems a bit like we have different people using different definitions or interpretations of the a definition and moving straight to how it will be used instead of coming to an agreement on what it is.  Or perhaps I missed that part.  If so, please point me to where I can read a definition of Intent that is driving this topic for everyone </JC>

>That, I think we're all converging on. (Especially the "should" part of it ;-)
	<JC> Based on these examples and discussion I think that general communication of intent, they way described here, should be declarative.  However, I also think that we should be able to pass a communication of some type of action that we want to take that is less general, such as the example of a reset.  If that is not to be called intent then perhaps it has a different name.  One could argue that asking for a reset is declarative in that I am not asking for how to accomplish that reset (IE: port bounce, service restart, node restart, etc).  It is not as declarative as a non-specific general request, but not as specific as to stated restart node.  I think that this is where the lines begin to cross, and the need for a definition of terms to look upon is imperative. </JC>

Jason Coleman

---

From: "Natale, Bob" <[email-masked]>
Date: Fri, 21 Aug 2015 16:13:22 +0000

Hi Jason,

Dave Lenrow's definition of intent-based networking in the attached slide deck* might help to answer some of the questions you raise below.

As I said (albeit obvious) in an earlier posting, a complete policy-based management solution requires both declarative (intent) and imperative (which Lenrow calls "prescriptive") capabilities. While the two endpoints where each fits best are fairly clear, the middle area can be interleaved in various ways. Lenrow's observation in the first bullet on slide #13 does a good job, IMHO, of defining the boundary in terms that are reminiscent of the Policy Continuum:

	"Intent is completely abstract. It does not include references to specific instances of infrastructure devices or state."

Clearly, his statement is to be read in the context of what precedes it in the deck ... and (my recommendation) in awareness of the different views represented in the Policy Continuum and the need for translation across those views.

[* - Apologies to those -- including you, Jason -- who might have already seen this deck of Dave's presentation at the Intent Based Network Summit.]

Avanti,
BobN

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Jason Coleman (colemaj)
Sent: Friday, August 21, 2015 11:08 AM
To: Michael Behringer (mbehring) <[email-masked]>; Brian E Carpenter <[email-masked]>; John Strassner <[email-masked]>; Duzongpeng <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Toerless Eckert (eckert) <[email-masked]>; Anima WG <[email-masked]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

-----Original Message-----

On 8/21/15, 9:44 AM, "Michael Behringer (mbehring)" <[email-masked]> wrote:

>> Cc: Michael Richardson; Toerless Eckert (eckert); Jason Coleman 
>> (colemaj); Anima WG; Michael Behringer (mbehring)
>> misbehaving. You could argue that formally that is outside the scope 
>> of autonomics itself, of course, but we'd look pretty silly if our 
>> mechanism for sending out "instructions" from the NOC could not include this one.
>

Jason Coleman

>> > and allow others. This is like saying you can use a switch 
>> > statement but not a while statement.
>> >
>> > non-declarative way, which is why I said "mostly". That being said, 
>> > in the autonomic systems I have built, it was 100% declarative at the top.
>> >
>> >> But IMO, in the beginning, we should start defining intent using 
>> >> the simplest way no matter the intent is imperative or declarative.
>> >>
>> >>
>> >>
>> >> enough to understand the declarative intent, we can replace all 
>> >> the imperative ones.
>> >>
>> >>
>> >>
>> >> *From:* Anima [mailto:[email-masked]] *On Behalf Of 
>> >> *Michael Behringer (mbehring)
>> >> My view: Let’s keep intent purely declarative. If you need to 
>> >> support imperative concepts, do this through traditional methods, 
>> >> like CLI, netconf, etc.
>> >>
>> >>
>> >>
>> >> lines: “well, if we have this nice Intent concept, we want to use 
>> >> it for everything”. I’d rather keep it separate, but that is just 
>> >> a personal opinion of course J  (A strong one though! J
>> >>
>> >>
>> >>
>> >> Michael
>> >>
>> >>
>> >>
>> >> This email may contain confidential and privileged material for 
>> >> the sole use of the intended recipient. Any review, use, 
>> >> distribution or disclosure by others is strictly prohibited. If 
>> >> you are not the intended recipient (or authorized to receive for 
>> >> the recipient), please contact the sender by reply email and 
>> >> delete all copies of this
>> message.
>> >>
>> >> To me it is clear that ANIMA Intent is declarative. It describes 
>> >> the desired outcome, not the way to get to it. That’s exactly what 
>> >> exactly because it is imperative. It’s just the wrong approach for 
>> >> most use
>> cases.
>> >>
>> >>
>> >>
>> >> Autonomics aims to abstract away device specifics and to provide 
>> >> one higher level view of the network. That’s exactly the declarative approach.
>> >> Disclaimer: For practical reasons (device capabilities) it may 
>> >> well be required for some time to do some hacks in Intent that are 
>> >> imperative. As long as we all understand it’s a temporary hack, 
>> >> and are explicit about it, that’s ok.
>> >>
>> >>
>> >>
>> >> If it wants to support fast reaction, that would then imply the 
>> >> logic has to run in eg: the routers as opposed to an sdn controller.
>> >>
>> >>
>> >>
>> >> how we envision Intents to work with ANIMA ASAs.  In particular, 
>> >> the model that is envisioned is far more SDN-like; that is with a 
>> >> They could equally well use other (more expensive!) management networks.
>> >>
>> >> In the recording, I heard various things about ANIMA... I don't 
>> >> think anyone overstated the situation, but I think that the 
>> >> There was a SUPA telecon yesterday morning, but I had a nomcom 
>> >> call, so I missed it.  It seems that there ought to be significant 
>> >> overlap, and yet I don't see it.
>> >>
>> >> --

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Aug 2015 14:05:26 +1200

> Dave Lenrow's definition of intent-based networking in the attached slide deck* might help to answer some of the questions you raise below.

Interesting slides, thanks. I can't resist commenting on one of
his points: that Intent is "independent of protocol, vendor, media, etc."

I don't think that can be strictly true in all cases. To give an example,
Intent for prefix assignment will be different for IPv6 vs IPv4. It might
need to be different for a radio access network vs a cable access network.
Some other Intent might need to be different for Android vs iOS devices.

   Brian

---

From: Duzongpeng <[email-masked]>
Date: Sat, 22 Aug 2015 03:55:32 +0000

Hi BobN,

I have read the slides. It is attractive.

However, it looks to me that the intent defined in that slide is more like a human language, and far from being applicable at this time.

I agree that in SDN, the intent can be the only interface to the SDN black box. 

But I doubt that in autonomic network, when directly talking to a device like a router is needed, we still can *only* have that interface.

So, as said by Sheng, if it is proved that SUPA has provided a better solution for any use case of autonomic network, we can just reuse it. However, if not, my suggestion is that we still can use some other solutions that are not defined in SUPA. 

IMO, the intent in anima does not need to MUST fulfill all the requirements in the slide. It makes sense to me even the intent in anima can only help to make an instruction vendor-independent. It may not be that powerful compared to what is defined in the slide, but it is more applicable at this time.

Best Regards
Zongpeng Du

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Natale, Bob
Sent: Saturday, August 22, 2015 12:13 AM
To: Jason Coleman (colemaj); Michael Behringer (mbehring); Brian E Carpenter; John Strassner; Duzongpeng
Cc: Michael Richardson; Toerless Eckert (eckert); Anima WG
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Hi Jason,

Avanti,
BobN

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Jason Coleman (colemaj)
Sent: Friday, August 21, 2015 11:08 AM
To: Michael Behringer (mbehring) <[email-masked]>; Brian E Carpenter <[email-masked]>; John Strassner <[email-masked]>; Duzongpeng <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Toerless Eckert (eckert) <[email-masked]>; Anima WG <[email-masked]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

-----Original Message-----

Jason Coleman

---

From: John Strassner <[email-masked]>
Date: Sun, 23 Aug 2015 14:02:49 -0700

Hi Bob,

> One potential problem I see with this overall discussion (not
> Toerless' posting immediately below, which is very helpful in
> my judgment) is that the matter of declarative and imperative
> policies is not, in the general end-to-end PBM case, an
> either/or situation:

<jcs> +1 </jcs>

 ...

> We have never standardized declarative at the level that it is
> needed and pushing imperative too far up the continuum
> ultimately becomes counterproductive.

<jcs> +1 </jcs>

> Autonomic solutions of any kind are attempts to shorten the
> distance between the declarative and imperative endpoints,
> usually via greater degrees of "hidden" stuff. Shortening that
> distance is a good thing but -- to be done correctly (esp. for
> uptake) -- depends (among other things) on (1) a solution to
> the declarative problem and (2) transparency on the
> imperative side.

<jcs> It's actually harder than this. For example, if I wanted to
ensure that every CPU in every VM operated between some
minimum and maximum utilization, FINDING the set of devices
to affect in a declarative language is TRIVIAL (a distributed
transitive closure); FINDING the set of devices to affect in an
imperative language is VERY DIFFICULT.

In contrast, enforcing this policy in a declarative language is
much harder than in an imperative one. This is one reason
why SUPA was built to enable declarative and imperative
policies to be used together.

The second reason was because of the policy continuum,
and the elegant description that you made above. </jcs>

...

> I was really hoping that SUPA would tackle the
> declarative problem head on and not confound things
> with the imperative problem as well.

<jcs> See above reason for why SUPA combined them. </jcs>

> I am not convinced that there should be one standard
> model for both at this stage.

<jcs> SUPA's goal is to standardize the concepts and the
representation of both declarative and imperative policies.
Unless you do that, then it will be difficult to (for example)
have a declarative policy call an imperative one, and
vice-versa. </jcs>

regards,
John

On Thu, Aug 20, 2015 at 8:20 AM, Natale, Bob <[email-masked]> wrote:

> "If you want simplicity, then the easiest way to build that is to have a
> model that facilitates translation from some high-level form to an
> intermediate form that the system understands."
>
> Simplicity is required. The model that facilitates translation is required
> because that is the way the world works from (declarative) high-level
> business policies to (imperative) executable configuration. The Policy
> Continuum is one such translation model that I will use for reference
> purposes here.
>
> One potential problem I see with this overall discussion (not Toerless'
> posting immediately below, which is very helpful in my judgment) is that
> the matter of declarative and imperative policies is not, in the general
> end-to-end PBM case, an either/or situation:
>
>    - Imperative is needed at the policy execution endpoint (roughly the
> "device" and "instance" views of the policy continuum) -- even though that
> might be "hidden" to a greater or lesser degree.
>
>    - Declarative is needed at the policy creation point (roughly the
> "business", "system", and "admin" views of the policy continuum).
>
> The "dividing line" in the middle of the continuum is not clear-cut ... it
> is very jagged, with spikes of declarative going farther "down" and spikes
> of imperative going farther "up" ... but a lot more of the latter than the
> former. And that's the crux of the matter. We have never standardized
> declarative at the level that it is needed and pushing imperative too far
> up the continuum ultimately becomes counterproductive.
>
> Autonomic solutions of any kind are attempts to shorten the distance
> between the declarative and imperative endpoints, usually via greater
> degrees of "hidden" stuff. Shortening that distance is a good thing but --
> to be done correctly (esp. for uptake) -- depends (among other things) on
> (1) a solution to the declarative problem and (2) transparency on the
> imperative side.
>
> We have never effectively standardized the declarative capability for
> policy-based network management (PBNM, using a very liberal meaning for
> "network management" here). That is a show-stopper requirement. If we don't
> do that, we will just produce a new breed of partial solutions, resulting
> ultimately in more fragmentation and operational inefficiency due mainly
> from the large "expression gap" between how business decision-makers think
> and speak and how network technologists think and build.
>
> I was really hoping that SUPA would tackle the declarative problem head on
> and not confound things with the imperative problem as well. I am not
> convinced that there should be one standard model for both at this stage.
> Imperative technology is widely deployed already (and growing constantly)
> ... of necessity. We've been able to survive without enabling the
> declarative capability, but that has not produced optimal PBNM solutions --
> by a long shot! -- and is becoming ever less tenable as the scope, scale,
> and pace of requirements continue to increase at growing rates.
>
> Cc: Duzongpeng <[email-masked]>; Michael Richardson <
> [email-masked]>; Jason Coleman (colemaj) <[email-masked]>;
> Anima WG <[email-masked]>; John Strassner <[email-masked]>
> Systems to build more intelligent networks start to incooperate a whole
> slew of layers/concepts and intent is thrown around everywhere. Then you
> have big data and intent is expressed in that context, and you have
> semantic reasoners trying to fulfill intent and so on and so forth.
>
> anima in the IETF and how anima can help. In the same was as more shorter
> term in bootstrap, this could longer term (re-chartering) apply to stuff
> around intent.
>
> IMHO, it seems we already want to break up a system into components we
> call ASAs, and Laurent has started to explain in his draft how multiple ASA
> need coordination, and the way i read it, that would come through
> appropriate declarative information that lays out eg: dependencies,which
> can then be resolved. I am not sure if these dependencies are intent, but
> they are clearly important declarative informatoin we need to tackle once
> we deal with ASAs.
>
> Cheers
>     Toerless
>
>
> > Probably we need to decide on a case-by-case basis. If (!) we allow
> imperative statements (I???d still like to see why we couldn???t do it
> declarative first), I???d like a way to separate them out logically in the
> structure of whichever encoding we???ll use. At least we can then keep the
> ???clean??? Intent separate from temporary workarounds.
> >
> > Michael
> >
> > My view: Let???s keep intent purely declarative. If you need to support
> > Now, this is a bit of a purist view, and I???ve heard comments along the
> lines: ???well, if we have this nice Intent concept, we want to use it for
> everything???. I???d rather keep it separate, but that is just a personal
> opinion of course ???  (A strong one though! ???
> >
> > Michael
> >
> desired outcome, not the way to get to it. That???s exactly what Autonomics
> because it is imperative. It???s just the wrong approach for most use cases.
> >
> higher level view of the network. That???s exactly the declarative
> approach. I really hope we have agreement on that.
> >
> long as we all understand it???s a temporary hack, and are explicit about
> it, that???s ok.
> >
> [email-masked]<mailto:[email-masked]>> wrote:
> > I am also not sure i could decide between declarative and imperative...
> is an acces list imperative ? Is the name of a well known access list
> declarative ?
> >
> > Toerless
> >
> >
> >
> >
> [email-masked]<mailto:[email-masked]>> wrote:
> >

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 23 Aug 2015 14:07:22 -0700

HI Brian,

the reason that Dave says that is because that is how we are building
intent in the ONF (see the associated white paper, now v3). The point would
be that the operator should not have to know if it was IPv4 or IPv6, the
system translating the intent expression to a form for general consumption
would know that based on the context (e.g., the target of the intent) of
the intent expression.

That is why nothing close in any SDO currently exists - the translation
from declarative intent to something consumable is really hard.

It's also probably not something the IETF will do. For example, think of a
MIB or a YANG module. Can I monitor, let alone configure, a device using
JUST a MIB or a YANG module? Of course not! I need associated logic to look
at the data structures defined by the MIB or YANG module. I need (for
example) an agent to go process it. Etc.

The point is that building the best data model in the world is NOT the
COMPLETE solution. So even if we standardized a model, or a protocol, or
both, so what? You would have to standardize the processing of the model,
the business logic, etc. to have a complete solution. I don't think that
will happen in any SDO. The closest we would get would be standardizing an
architecture with reference points.

So far, no discussion in the IETF has gone there, hence my skepticism.

regards,
John

On Fri, Aug 21, 2015 at 7:05 PM, Brian E Carpenter <
[email-masked]> wrote:

> > Dave Lenrow's definition of intent-based networking in the attached
> slide deck* might help to answer some of the questions you raise below.
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 23 Aug 2015 14:52:19 -0700

Hi Jason,

<JC> If we have an AN network with ACP and GRASP, why would we not want to
use AN to ask the Node to perform a reset or some other action that is
required?  If not called Intent that is fine, but I think that we have to
provide a way for this type of communication</JC>

<jcs> Absolutely agree. The AN SHOULD be responsible for this. A hard
requirement of any autonomic solution is interoperability. As you say
below, it doesn't matter if "reset" is defined directly by an intent
expression or intent is translated to reset. </jcs>

<JC> It appears to me that many people in the discussion have thoughts on
WHAT Intent means to them, HOW Intent should be used, and WHAT Intent is
NOT.  Do we have a definition of Intent that states the purpose of Intent
and the scope that has consensus to back that definition?  Seems a bit like
we have different people using different definitions or interpretations of
the a definition and moving straight to how it will be used instead of
coming to an agreement on what it is.  Or perhaps I missed that part.  If
so, please point me to where I can read a definition of Intent that is
driving this topic for everyone </JC>

<jcs> If you look at my work in OpenStack Congress, ONF, TMF, or IETF SUPA,
I have tried to consistently say that intent is implemented using
declarative programming principles. Simplistically, people describe this as
"say what you want, but do not define how it should be implemented". More
technically, declarative programming uses a formal logic system. Happy to
send specific documents; just didn't want to flood everyone's mail. </jcs>

<JC> Based on these examples and discussion I think that general
communication of intent, they way described here, should be declarative.
However, I also think that we should be able to pass a communication of
some type of action that we want to take that is less general, such as the
example of a reset.  If that is not to be called intent then perhaps it has
a different name.  One could argue that asking for a reset is declarative
in that I am not asking for how to accomplish that reset (IE: port bounce,
service restart, node restart, etc).  It is not as declarative as a
non-specific general request, but not as specific as to stated restart
node.  I think that this is where the lines begin to cross, and the need
for a definition of terms to look upon is imperative. </JC>

<jcs> This is why we engineering TMF ZOOM and SUPA to support both. </jcs>

regards,
John

On Fri, Aug 21, 2015 at 8:07 AM, Jason Coleman (colemaj) <[email-masked]>
wrote:

> >Very good example. And I agree that *autonomics* needs to provide a
> solution, but that solution doesn't have to be *Intent*.
> >
> >So in my view, Intent tells an autonomic function "do the right thing"
> (very declarative, that!). If one of the ASAs of that autonomic function
> hangs, you solve that with "normal" management methods, for example ssh to
> that platform and issue a reset. Or, maybe we'll foresee a feedback loop
> for that purpose, later on. I think we can deal with it, but: it's not
> Intent.
>         <JC> If we have an AN network with ACP and GRASP, why would we not
> want to use AN to ask the Node to perform a reset or some other action that
> is required?  If not called Intent that is fine, but I think that we have
> to provide a way for this type of communication</JC>
>
> >
> >
> >There is another reason why that particular transaction shouldn't be
> solved with Intent: To me, Intent has a long term scope. (Maybe that's an
> even better way to define it). A re-set of an ASA is a one-off. Not the
> right thing in a long-term policy.
>         <JC> It appears to me that many people in the discussion have
> thoughts on WHAT Intent means to them, HOW Intent should be used, and WHAT
> Intent is NOT.  Do we have a definition of Intent that states the purpose
> of Intent and the scope that has consensus to back that definition?  Seems
> a bit like we have different people using different definitions or
> interpretations of the a definition and moving straight to how it will be
> used instead of coming to an agreement on what it is.  Or perhaps I missed
> that part.  If so, please point me to where I can read a definition of
> Intent that is driving this topic for everyone </JC>
>
> >
> >
> >Maybe we need to define it through the backdoor:  Intent should be
> generic enough to be flooded through the network, so that every node gets a
> copy. That clearly doesn't make sense for short-lived actions.
> >
>         <JC> Based on these examples and discussion I think that general
> communication of intent, they way described here, should be declarative.
> However, I also think that we should be able to pass a communication of
> some type of action that we want to take that is less general, such as the
> example of a reset.  If that is not to be called intent then perhaps it has
> a different name.  One could argue that asking for a reset is declarative
> in that I am not asking for how to accomplish that reset (IE: port bounce,
> service restart, node restart, etc).  It is not as declarative as a
> non-specific general request, but not as specific as to stated restart
> node.  I think that this is where the lines begin to cross, and the need
> for a definition of terms to look upon is imperative. </JC>
>
> Jason Coleman
>
> >
> >
> >Michael
> >
> >
> >> Regards
> >>    Brian
> >>
> >> >> please contact the sender by reply email and delete all copies of
> this
> >> message.
> >> >>

-- 
regards,
John

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 24 Aug 2015 12:43:25 +0000

Thanks for the additional perspective, John … wrt this point in particular:
<jcs> SUPA's goal is to standardize the concepts and the representation of both declarative and imperative policies. Unless you do that, then it will be difficult to (for example) have a declarative policy call an imperative one, and vice-versa. </jcs>

As you know, I do applaud the valiant effort that you and other active participants in the SUPA work are making and I understand how difficult the task is. However, I believe that for this next step in more effective PBNM standardizing the declarative framework is the major step forward that is achievable … it is, as you know better than anyone I can think of, a really large step … and one that has never been completed in the NM domain. I understand the difficulty that will remain in the translation of declarative to imperative, but am looking forward to more advanced semantic technologies (writ large here) to provide that bridge. Reducing the declarative side of that problem from NLP to a standardized constrained language (using the term loosely) will facilitate (and hopefully hasten) that development.

All of that is merely IMHO and FWIW, of course, and possibly a little distracting from the good work at hand in SUPA, ANIMA, and other efforts within and outside the IETF that you have cited in related messages.

Avanti,
BobN

From: John Strassner [mailto:[email-masked]]
Sent: Sunday, August 23, 2015 5:03 PM
To: Natale, Bob <[email-masked]>; John Strassner <[email-masked]>
Cc: Toerless Eckert (eckert) <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>; Duzongpeng <[email-masked]>; Michael Richardson <[email-masked]>; Jason Coleman (colemaj) <[email-masked]>; Anima WG <[email-masked]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Hi Bob,

<jcs> +1 </jcs>

 ...

<jcs> +1 </jcs>

...

regards,
John

On Thu, Aug 20, 2015 at 8:20 AM, Natale, Bob <[email-masked]<mailto:[email-masked]>> wrote:
[Lurker alert!]

Avanti,
BobN

-----Original Message-----
From: Anima [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Toerless Eckert (eckert)
Sent: Thursday, August 20, 2015 10:33 AM
To: Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>>
Cc: Duzongpeng <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>; Jason Coleman (colemaj) <[email-masked]<mailto:[email-masked]>>; Anima WG <[email-masked]<mailto:[email-masked]>>; John Strassner <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Cheers
    Toerless

On Thu, Aug 20, 2015 at 12:03:08PM +0000, Michael Behringer (mbehring) wrote:
> From: Duzongpeng [mailto:[email-masked]<mailto:[email-masked]>]
> From: Anima [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael
> Behringer (mbehring)
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> phone: +1 512-340-3134<tel:%2B1%20512-340-3134>
> On Wed, Aug 19, 2015 at 5:22 PM, Toerless Eckert (eckert) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> John Strassner <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Hi Michael,
>
> On Tue, Aug 18, 2015 at 12:50 PM, Michael Richardson <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Sandelman
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

--
---
Toerless Eckert, [email-masked]<mailto:[email-masked]>

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 24 Aug 2015 19:50:21 -0700

Hi Bob,

you wrote:

As you know, I do applaud the valiant effort that you and other active
participants in the SUPA work are making and I understand how difficult the
task is. However, I believe that for this next step in more effective PBNM
standardizing the declarative framework is the major step forward that is
achievable … it is, as you know better than anyone I can think of, a really
large step … and one that has never been completed in the NM domain. I
understand the difficulty that will remain in the translation of
declarative to imperative, but am looking forward to more advanced semantic
technologies (writ large here) to provide that bridge. Reducing the
declarative side of that problem from NLP to a standardized constrained
language (using the term loosely) will facilitate (and hopefully hasten)
that development.

<jcs>
I of course agree with you.

To date, the only real example of a declarative language for networking is
OpenStack Congress, where I helped write a parser that extends Datalog a
bit to make it easier for administrative applications.

However, none of the operators, CCIEs, or JCIEs that I know of know
Datalog, so while the Datalog variant in Congress (and Datalog in
general) is computationally efficient, I don't think that this is a
workable solution for autonomics.

I've played with putting a simple (restricted) natural language front-end
on Congress - I think that this is closer to what operators would want.

I think the chance of standardizing a restricted natural language front end
for declarative policies is ZERO. Thus, I think that the only chance we
have is to pick some type of formal logic - I do not care which - and then
define some APIs that restrict what people do with the language. That's
why, in SUPA, I am defining two types of formal logic for declarative
policies - propositional logic and first order logic. The former is much
simpler than Datalog, while the latter is more robust (but of course has to
be restricted or it may not be computable).

I am TRYING to convince myself that this is all we need. I haven't
succeeded :-( because where do the semantics go? That's why (as you know)
FOCALE used models (to represent facts) AND ontologies with description
logic (to reason about the facts). The use of a formal logic is mandatory
to make this work, and ontologies + logic enable a host of open source
reasoners to be used. I HAVE convinced myself that this will work, but this
is a heavyweight solution. I welcome the thoughts of you and others -
publicly or privately.
</jcs>

regards,
John

On Mon, Aug 24, 2015 at 5:43 AM, Natale, Bob <[email-masked]> wrote:

> <jcs> SUPA's goal is to standardize the concepts and the representation of
> both declarative and imperative policies. Unless you do that, then it will
> be difficult to (for example) have a declarative policy call an imperative
> one, and vice-versa. </jcs>
>
>
>
> As you know, I do applaud the valiant effort that you and other active
> participants in the SUPA work are making and I understand how difficult the
> task is. However, I believe that for this next step in more effective PBNM
> standardizing the declarative framework is the major step forward that is
> achievable … it is, as you know better than anyone I can think of, a really
> large step … and one that has never been completed in the NM domain. I
> understand the difficulty that will remain in the translation of
> declarative to imperative, but am looking forward to more advanced semantic
> technologies (writ large here) to provide that bridge. Reducing the
> declarative side of that problem from NLP to a standardized constrained
> language (using the term loosely) will facilitate (and hopefully hasten)
> that development.
>
>
>
> All of that is merely IMHO and FWIW, of course, and possibly a little
> distracting from the good work at hand in SUPA, ANIMA, and other efforts
> within and outside the IETF that you have cited in related messages.
>
>
>
> Avanti,
>
> BobN
>
>
>
> *From:* John Strassner [mailto:[email-masked]]
> *Sent:* Sunday, August 23, 2015 5:03 PM
> *To:* Natale, Bob <[email-masked]>; John Strassner <[email-masked]>
> *Cc:* Toerless Eckert (eckert) <[email-masked]>; Michael Behringer
> (mbehring) <[email-masked]>; Duzongpeng <[email-masked]>;
> Michael Richardson <[email-masked]>; Jason Coleman (colemaj) <
> [email-masked]>; Anima WG <[email-masked]>

-- 
regards,
John

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Aug 2015 10:14:37 -0400

> I've been involved in SUPA, but also in ANIMA; here is my perspective:

Thank you!

    > should be declarative in nature. Please correct me if I am wrong.

Yes, it must be declarative in nature, and but most importantly is that the
(signed) Intent will be interpreted in many places to form local logic.

    > actually broader than just ASs.

I think that ANIMA Intents are not intended to cross-AS.
At least: we don't intend that the Intents be validatable cross-AS.
This may mean that they can simpler, or it may have no impact at all.

    > FOCALE (my autonomic architecture) chose the latter

pointer to FOCALE?

    > is not going to use declarative logic, then why not?

We have intentionally left Intent out of scope at this point.
It could be that we can leave it partially out of scope if we can leverage
SUPA; likely we would write some kind of profile of SUPA in that case.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Aug 2015 10:17:28 -0400

> imperative concepts, do this through traditional methods, like CLI,

I would suggest that a reasonable ASA that might exist is a device
that can perform declarative Intent -> CLI translation :-)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Aug 2015 10:38:46 -0400

> "Any CPU in any VM whose utilization is > 70% should be

I wouldn't write it that way, btw.

I would write:

  "Arrange VM guest distribution so that (CPU) utilization is < 70%"

(I might also write:
  "Arrange VM guest distribution so that power utilization is > 70%"
or: "Arrange VM guest distribution so that (RAM) utilization is > 20%
    on each host machine", or maybe some other energy saving rules)

I would then expect an the system to realize:
  1) it needs a system to collect CPU and power utilization.
     [this would turn into a service discovery]
  2) VM hosts need to report that information to supervisor.
  3) VM hosts with ILOMs need to delegate credentials to supervisor
     that enable power control; specifically power-on control.
  4) that NAS needs to be setup to enable migration of VMs
  5) that it needs to turn on enough hosts, and configure them as VM
     servers, such that:
         a) there are enough hosts to keep CPU utilization < 70%.
         b) there are few enough hosts powered so that electicity
            isn't wasted

---

From: "Natale, Bob" <[email-masked]>
Date: Tue, 25 Aug 2015 14:48:48 +0000

> It could be that we can leave it partially out of scope if we can leverage SUPA; likely we would write some kind of profile of SUPA in that case.

This strikes me as a very smart approach ... with the caveat that ANIMA contributors would monitor SUPA work in the meantime to ensure that an appropriate profile (i.e., one that meets the needs of ANIMA) can, in fact, be constructed.

(I am not certain that the notion of profiling is currently in the SUPA work plan, but it seems like it should be ... or maybe John knows that it will emerge naturally.)

Avanti,
BobN

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, August 25, 2015 10:15 AM
To: John Strassner <[email-masked]>
Cc: Anima WG <[email-masked]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

Thank you!

pointer to FOCALE?

We have intentionally left Intent out of scope at this point.
It could be that we can leave it partially out of scope if we can leverage SUPA; likely we would write some kind of profile of SUPA in that case.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Aug 2015 12:34:18 -0400

Natale, Bob <[email-masked]> wrote:
    >> It could be that we can leave it partially out of scope if we can
    >> leverage SUPA; likely we would write some kind of profile of SUPA in
    >> that case.

    > This strikes me as a very smart approach ... with the caveat that ANIMA
    > contributors would monitor SUPA work in the meantime to ensure that an
    > appropriate profile (i.e., one that meets the needs of ANIMA) can, in
    > fact, be constructed.

In order for us to do this, we (ANIMA) need to have some well described
reference use cases.  I don't think we have this in our charter (just
checked, no).  I'm hesistant to suggest adding it at this time, though.

I would suggest that we go for something like two very simple, very
concrete use cases, and two more "pie-in-the-sky" ideas.  Our charter does
give us one example:

  "A simple example is assigning address prefixes to network segments in a
  large and constantly changing network."

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Aug 2015 08:20:01 +1200

>   large and constantly changing network."

And that's the one where we do have some sketchy intent statements
already written down:
https://tools.ietf.org/html/draft-jiang-anima-prefix-management-01#section-5.1

    Brian

---

From: John Strassner <[email-masked]>
Date: Tue, 25 Aug 2015 13:42:09 -0700

Hi Michael,

> This may mean that they can simpler, or it may have no impact

<jcs>
I think that this DOES make life simpler, both from the security
side as well as from the expression of the intent (and its
subsequent translation. Perhaps we could talk more at
the Yokohama meeting.
</jcs>

...

> pointer to FOCALE?

<jcs>
The original architecture was defined in 2005. Here's a
reference to the first journal paper:

J. Strassner, N. Agoulmine, E. Lehtihet, “FOCALE – A Novel
Autonomic Networking Architecture”, ITSSA Journal,
Vol. , No. 1, May 2007, pages 64-79, ISSN 1751-1461

I can send you a copy if you like; just didn't want to flood
everyone's email unnecessarily
</jcs>

...

> It could be that we can leave it partially out of scope if we
> can leverage SUPA; likely we would write some kind of
> profile of SUPA in that case.
<jcs>
This is a good idea. SUPA hasn't considered that yet, but
I would do everything I could to help support this.
</jcs>

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 25 Aug 2015 13:48:35 -0700

HI Michael and Michael,

While I agree that intent SHOULD be declarative, in order
to facilitate adoption, I think that we SHOULD consider
such translations; this will help interoperability with
legacy systems. The Policy Engine, and its interface to
the operator in draft-klyus-supa-proposition-02, contains
a Policy Translation function to perform this function.
This is also talked about in my IETF93 SUPA BoF
presentation.

best regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 25 Aug 2015 13:57:22 -0700

Hi Michael,

good point, I like your formulation better.

Now, when you say that the system performs a
service discovery when collecting CPU and power
utilization information, why is this discovering a
service, instead of simply querying the appropriate
resources? I actually like the idea of service
discovery, but what wondering if I was missing
something important.

One other quick point; your example (which I very much
like, btw) also helps illustrate that even the best info
and/or data model can NOT perform the logic that you
have outlined. This ties back into my earlier discussion
about using models and ontologies (with some type of
formal logic) to do the reasoning that you have
outlined below.

best regards,
John

-- 
regards,
John

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 25 Aug 2015 20:58:06 +0000

IMHO, in many implementations, of course you need a way to “render” intent and translate it into legacy commands, but this should presumably be considered implementation matter and irrelevant for interoperability at the level of the AS, hence outside the scope.  Trying to define how legacy translations need to occur would IMHO hinder and slow down, not facilitate adoption.  Just my 2 cents
--- Alex

From: Anima [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Tuesday, August 25, 2015 1:49 PM
To: Michael Richardson <[email-masked]>; John Strassner <[email-masked]>
Cc: Toerless Eckert (eckert) <[email-masked]>; Jason Coleman (colemaj) <[email-masked]>; Anima WG <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>
Subject: Re: [Anima] Not the Intents we were looking for: SUPA Intents

HI Michael and Michael,

best regards,
John

On Tue, Aug 25, 2015 at 7:17 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 25 Aug 2015 13:58:15 -0700

So far, SUPA has NOT considered profiling - but I
personally think it is an excellent idea.

best regards,
John

On Tue, Aug 25, 2015 at 7:48 AM, Natale, Bob <[email-masked]> wrote:

> leverage SUPA; likely we would write some kind of profile of SUPA in that
> case.
>
> appropriate profile (i.e., one that meets the needs of ANIMA) can, in fact,
> be constructed.
>
> (I am not certain that the notion of profiling is currently in the SUPA
> work plan, but it seems like it should be ... or maybe John knows that it
> will emerge naturally.)
>
> Avanti,
> BobN
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 25 Aug 2015 14:03:48 -0700

Hi Michael,

> In order for us to do this, we (ANIMA) need to have some well
> described reference use cases.  I don't think we have this in our
> charter (just checked, no).  I'm hesistant to suggest adding it at
> this time, though.

<jcs>
I agree. We should think about it and work informally, but not add
it to our charter just yet.
</jcs>

> I would suggest that we go for something like two very simple,
> very concrete use cases, and two more "pie-in-the-sky" ideas.

<jcs>
I very much agree!
</jcs>

bet regards,
John

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Aug 2015 10:08:48 +1200

> discovery, but what wondering if I was missing

As you know, when you have a hammer, everything looks like
a nail. In Anima, we expect ASAs to discover each other
in order to request synchronization data or to negotiate
parameters. Of course, if you've already discovered the
relevant peer, you would immediately query (i.e request synch).
However, the discovery cache will eventually time out, so then
you'd need to repeat discovery.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 26 Aug 2015 03:51:37 +0000

>checked, no).  I'm hesistant to suggest adding it at this time, though.

I would suggest you and others to work on such use cases. It would be individual submission and out of the current charter. But if the discussion went well, it would give us a good foundation to take it into next charter.

Regards,

Sheng

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Aug 2015 14:43:20 -0400

> discovery, but what wondering if I was missing

What I'm saying is occuring is that something would have to
realize that CPU/power utilizations needs to be collected.
That requires a system to do the collection (either something
to receive data, or something to poll for it).

It could be driven by a VM host ("dom0") realizing (upon interpretation of
the Intent) that in it's inventory of pre-built VMs, it has a data collection
VM.  Or it might be that the dom0 hosts, would do a ANIMA service discovery
for a place to send data, and that would cause such a service to be
instantiated.

    > formal logic) to do the reasoning that you have

Agreed.  The data-model just tells us what can be tweaked, but not
the why.