Re: [Anima] Intent "beginning to end"

[John Strassner <[e-mail]>]

+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]>
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]
>> https://www.ietf.org/mailman/listinfo/anima
>>
>>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>



-- 
regards,
John