Subject: Re: [Anima] Intent "beginning to end"

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Thu, 21 Apr 2016 14:28:33 +0000

One of the things that I would like to see us all agree upon is the understanding of what we are attempting to define with respect to Intent.  When we talk about Intent in this mailer are we talking about ‘Autonomic Intent’ or how an Autonomic Network deals with ‘Intent’.

To me the difference is that Autonomic Intent is something that is wholly defined and used inside of an Autonomic network, and an Autonomic network that is dealing with Intent is accepting Intent from an outside source, perhaps Autonomic/perhaps not, and then distributing it through the AN via AN principles, flows, and definitions.

If we are discussing Autonomic Intent then I assume that we are not worried or concerned about other definitions of Intent that are created outside of AN.  Then we can focus discussions about AN Intent as only living on AN enabled and connected devices and the implications of that.  If we are talking about a more general idea of Intent, then we do need to think about other definitions, and also how an AN network will work with Intent that comes from or moves to non-AN network elements.
--
Jason Coleman

On 4/20/16, 7:49 AM, "Anima on behalf of Michael Behringer (mbehring)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

After the IETF discussions it is clear that we still don't have the same model in our head when we're discussing how Intent is handled. Let's see whether we can get some naming agreement.

draft-du-anima-an-intent describes some of the content below (e.g., distribution, interpretation), but there is no "beginning to end" flow on how Intent "flows" through the network. It would help the discussion I think if we formalised the entire flow. For example, in the below flow it is clear that parameters you exchange as a result of interpreting Intent are not called Intent. (I think this was one point we don't have agreement on).

Let me try to write down this "flow", as I see it, as a starting point for discussion.

1. Business goals: The network owner wants the network to follow some business goals.
   (These goals are initially not formalised, in a computer science sense. )
   - these goals are formalised in a language -->
2. Intent: is the formalisation of business goals so that computer can deal with them.
   (encoded as a file; or several files)
   - this file must be "given to the network" -->
3. Ingestion: The Intent file(s) get instantiated on an autonomic node
   On a particular node, an intent file is "ingested".
   - Now it needs to be distributed -->
4. Intent Distribution: Intent is flooded to all nodes in a network;
   Every node has a copy of the original "Intent" file(s), without modification.
   Each node re-distributes the original Intent files, without modification.
   Therefore, Intent is optional and transitive in nature.
   - the Intent files must now be interpreted by each node -->
5. Intent splitting (on each node):
   Intent is split into sections, one for the ANI itself, others for specific Autonomic Functions
   ASAs are notified if there is new Intent for them.
   Some intent sections may not apply to a particular  node
   Now each component of a node (ANI, all ASAs) know their respective Intent.
6. Intent Interpretation (on each node, by each function):
   The ANI as well as all ASAs on a node interpret their respective Intent.
   It gets translated into a "target configuration", taking into account local state.
   For this translation, it may be necessary for ASAs to communicate with ASAs on other nodes,
   to pass on resources (IP addresses), to negotiate, etc.
   All such communications may be triggered by Intent, but the communications themselves
   are NOT Intent.
   (NB: This interpretation could also be done centrally, and the resulting configs distributed;
    This is of course an option, but for that we don't need ANIMA. Therefore I suggest for the
    ANIMA work to focus on interpreting Intent locally on each node)
   Result: target configlet (not applied yet!!).
7. Conflict Resolution with non-autonomic management (on each node):
   The target configlet resulting from Intent has the lowest prio; any other management
   method (CLI, NETCONF, etc) overrides Intent.
8. Conflict Resolution between autonomic components (on each node):
   Each autonomic function needs to register with a "conflict resolution function"
   which parameters it modifies; in case of conflict the conflict resolution function
   takes a decision and feeds that back to the autonomic functions. This may modify
   the target configlet.
9. Applying the target configlet
   A type of "commit" of the configlet.
10. Feedback loops to NOC: The NOC needs to know about certain conditions:
   Conflicts with non-autonomic management (FYI)
   Not all conflicts can be resolved automatically. (may require NOC actions)
   Undesirable states (deviations from expected default behaviour) may have to be communicated;
   To some extent, Intent itself can specify which conditions should trigger feedback
   loops to the NOC.
   Feedback loops may happen at other phases as well (ex: 8)

I'm conscious that there are different views in the team; like I believe in point 6 we're not yet aligned. Please take this list just as a basis for discussion, nothing more.

When we have consensus, I believe such a flow should be documented in draft-du-anima-an-intent in its entirety, to give a full picture.

Feedback?
Michael

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

---

From: "jmh.direct" <[email-masked]>
Date: Thu, 21 Apr 2016 10:41:58 -0700

I am used to conflict resoluti OK now being used for the issue of actual conflicts between policies, rather than for the quasi-centraluzed resource allocation issues.  I will wait for Lauren's return.
Yours,Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Michael Behringer (mbehring)" <[email-masked]> Date: 4/21/2016  10:01 AM  (GMT-08:00) To: "Joel M. Halpern" <[email-masked]>, Anima WG <[email-masked]> Subject: RE: [Anima] Intent "beginning to end" 
> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 21 April 2016 16:09
> To: Michael Behringer (mbehring) <[email-masked]>; Anima WG
> <[email-masked]>
> Subject: Re: [Anima] Intent "beginning to end"
> 
> It would be nice if the problem is simpler than I think it is.
> 
> An example that occurs to me is the usual set of traffic prioritization
> policies:
> 
> Ensure that high quality traffic from Platinum customers gets priority,
>   +
> ... other traffic selection policies
>   +
> Policies that identify traffic
>   +
> Ensure that no link is more than 70% utilized.
> 
> Someone is going to have to decide which traffic goes where.  I do not
> believe each network node independently, no matter how much AN
> intelligence it has, can act on these policies themselves.  Yes, nodes can
> detect violations, but I can not see how they can remediate independently.

Now I understand, thanks for clarifying. That, to me, this should be covered in point 
8. Conflict Resolution between autonomic components (on each node):

Since, these are different autonomic functions that produce results that need a conflict resolution. 

In other words, also here, I think this is outside Intent and Intent distribution. 

Laurent is the specialist for conflict resolution - would be good to get his perspective (but he's offline this week, afaik)

Does that make sense, Joel, or am I over-simplifying? 
Michael

---

From: "jmh.direct" <[email-masked]>
Date: Thu, 21 Apr 2016 21:20:01 -0400

Reasonable, but I was responding to Michael B.s table, which started from humans and had no translation.
Yours,Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: Brian E Carpenter <[email-masked]> Date: 4/21/2016  9:12 PM  (GMT-05:00) To: "jmh.direct" <[email-masked]>, John Strassner <[email-masked]>, "Joel M. Halpern" <[email-masked]> Cc: Anima WG <[email-masked]>, "Michael Behringer (mbehring)" <[email-masked]> Subject: Re: [Anima] Intent "beginning to end" 
On 22/04/2016 12:23, jmh.direct wrote:
> From what I have seen, at the business level the needed information is spread across multiple sources.  So if, as diagrammed, Intent starts at the human, then something needs to compile it together.

Certainly. So in fact we are talking about two different things.

Intent (H): what humans generate, that must be sanity checked, reconciled, and compiled into
Intent (A): a consistent form of Intent that can be interpreted by an algorithm in any autonomic node.

I believe that Anima should focus on Intent (A).

   Brian

> Yours,Joel
> 
> 
> Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: Brian E Carpenter <[email-masked]> Date: 4/21/2016  5:02 PM  (GMT-05:00) To: John Strassner <[email-masked]>, "Joel M. Halpern" <[email-masked]> Cc: Anima WG <[email-masked]>, "Michael Behringer (mbehring)" <[email-masked]> Subject: Re: [Anima] Intent "beginning to end" 
> On 22/04/2016 08:46, John Strassner wrote:
> ...
>>     3) I believe that interpreting/compiling intent will be HARD, and
>>         that understanding intent will be MUCH HARDER. Why does
>>         every autonomic node need to do that?
> 
> Surely that depends on the detailed design of Intent syntax and semantics,
> by which I mean the Intent that is distributed to all autonomic nodes
> and hence to all ASAs. Given that we know it needs to be interpreted by
> individual ASAs, shouldn't we design it to be readily interpreted?
> (If there is some more abstract format of Intent that is *not* distributed
> everywhere, that's fine, but it's not our concern for designing Anima.
> We have to worry about the concrete Intent that's sent to all AN nodes.)
> 
> An ASA that manages resource X, which involves negotiation with other
> ASAs also managing resource X, and setting configuration for itself and
> perhaps for subsidiary non-autonomic devices using resource X, will need
> to interpret statements about settings the affect resource X, as well as
> statements about generic settings. So they need to be readily interpretable.
> 
>     Brian
>