Re: [Anima] Intent "beginning to end"

[John Strassner <[e-mail]>]

Hi Michael,

>> 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.
>
> This is where I have a hard time. If "Intent" is a business policy,
> how can a node modify it?!? To me that seems impossible. I
> would really like to keep Intent exactly the thing a human throws
> into the network; everything else is, well, something else.

Why does a node have to modify intent? I think of intent as coming
from a business person or an app developer; neither of these
typically knows how to configure a network service. The purpose
of intent is to enable them to express what services they would
like to use, and then have something else do the hard work.

This is why other systems I know of put a compiling/interpreting
step between the ingestion of the intent and the delivery of the
**translated** intent to other autonomic nodes.

regards,
John

On Wed, Apr 20, 2016 at 11:52 PM, Michael Behringer (mbehring) <
[e-mail]> wrote:

> > -----Original Message-----
> > From: Joel M. Halpern [mailto:[e-mail]]
> > Sent: 20 April 2016 16:17
> > To: Michael Behringer (mbehring) <[e-mail]>; Anima WG
> > <[e-mail]>
> > Subject: Re: [Anima] Intent "beginning to end"
> >
> > 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.
>
> Can you give an example? I think the model I've noted down below is
> reasonably simple, and having intermediate steps might make it a lot more
> complicated. Not saying we shouldn't consider that, but only if we have to
> :-)
>
> > 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.
>
> This is where I have a hard time. If "Intent" is a business policy, how
> can a node modify it?!? To me that seems impossible. I would really like to
> keep Intent exactly the thing a human throws into the network; everything
> else is, well, something else.
>
> Again, maybe an example would make this clearer?
>
> Michael
>
> > 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