Re: [Anima] Intent "beginning to end"

["Natale, Bob" <[e-mail]>]

Make that +2.

(As far as I can tell and from an operations perspective, you cannot do Intent-based policy management without the Policy Continuum, or an equivalent conceptual construct).

Avanti,
BobN

From: Anima [mailto:[e-mail]] On Behalf Of John Strassner
Sent: Thursday, April 21, 2016 4:47 PM
To: Joel M. Halpern <[e-mail]>; John Strassner <[e-mail]>
Cc: Anima WG <[e-mail]>; Michael Behringer (mbehring) <[e-mail]>
Subject: Re: [Anima] Intent "beginning to end"

+1.

In particular, doing this has a number of advantages:

   1) The Policy Continuum was built to mimic the flow of abstract
       policies being translated into different forms that were
       applicable to each user. Business intent will need several
       such translations from experience.
   2) Context can be taken into account in a uniform way (as opposed
       to having each individual node report context)
   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?

I do think that ASAs should be used to do the interpreting/compiling
and understanding tasks.


regards,
John

On Wed, Apr 20, 2016 at 7:16 AM, Joel M. Halpern <[e-mail]<mailto:[e-mail]>> wrote:
It seems to me that for many kinds of business intentions, as translated into "intents", there will need to be an intelligent processing step that determines how this intent relates to the network state, and how the network needs to respond to this.  While there are cases where this can be done at each AN, there are also many cases where this needs intermediate work.

As I understand it, those intermediaries are AN, which produce results usable by other AN.  While they will produce parameters for the AN, they will also, I expect produce refined intents.

Yours,
Joel

On 4/20/16 8:49 AM, Michael Behringer (mbehring) 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/anima

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



--
regards,
John