Re: [Anima] Intent "beginning to end"

[John Strassner <[e-mail]>]

Hi Michael,

well, now you've done it. :-)
This is an interesting and much needed stake in the ground; please see my
replies inline.

...

> It would help the discussion I think if we formalised the entire flow.

Agreed!

> 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).

I don't understand the term "parameters", but if you mean information
resulting from the intent interpretation/compilation process, I agree.

Note: I also agree that the exchange of such information is NOT intent.

...

> 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 -->

Strongly agree. Since intent is by definition high-level, its primary users
will be people that are not technical network admins (the *CIEs).
Furthermore, another important user is the App Developer, most of which
don't have a clue how to configure a network element. So especially for
the latter, a **declarative** (NOT imperative) language is critical.

However, since intent is abstract by definition, it will need specialized
functions to interpret or compile it, and likely other specialized functions
(I've used a multi-agent approach in the past) to understand intent.
This applies to the rest of my comments below.

...

> 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 -->

While I am happy for this behavior to be documented, and even defined
as a default alternative, I want other behaviors to be possible.

For example, if intent really is business-oriented, I posit that the average
autonomic node will have NO IDEA what to do with it, or how to interpret
it. Furthermore, why should it? In systems that I have seen and have
built, this is a very specialized task.

I would strongly prefer to see intent received by any node, but then sent
to a set of specific nodes for interpretation or compilation. AFTER that,
flood the results to all nodes. But flooding the results before it is
established what intent is introduces too many variables into the mix.


> 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.

You lost me. What is the purpose of splitting intent? This means that
EVERY autonomic node now must have the ability to interpret or
compile intent (perhaps without fully understanding it) AND must be
a "traffic cop" to send the "intentlets" (sorry, low on coffee) to their
proper destination. This means that each autonomic node either
understands both the topology and the autonomic functions that
each node supports (not likely!) or that there is metadata, or bits
in the intent, or something to say where the destination is.

Remember my earlier analogy with phones. Good luck selling
an "intelligent" phone - the consumer will take higher resolution
cameras, or better codecs, or anything other than something
nebulous!


>  6. Intent Interpretation (on each node, by each function):
>   The ANI as well as all ASAs on a node interpret their respective Intent.
...
See above.
...
>    (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!!).

Sorry, I disagree. Why do we no longer need ANIMA? For example,
let's say we replace GRASP with a pub-sub message queue (I'm NOT
advocating this - just making an example). We still need ANIMA,
because a pub-sub message queue does not understand how to
facilitate autonomic behavior - it just delivers bits.


> 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.

This seems very difficult to me.
Case 1: fully autonomic node
How does it understand all of the legacy methods and translate those
to an autonomic equivalent? This is an n^2 problem, and you need a
normalized form so that the node doesn't have to understand the
differences between CLI, private MIBs, etc.

Case 2: fully dumb rock
It won't have a clue what to do with autonomic intent. So again, we
need a translation from the intent to a form that the dumb rock can
understand.

Case 3: node that has a clue about autonomics
Even if we assume that it understands all of the legacy methods,
how does it integrate those methods with intent? We could, for
example, dedicate a set of ASAs to serve as translators.
However, as I've stated in earlier posts, this is a very difficult task.
I contend that we will need both models and ontologies (or some
other form of logic) to do this, which is why I get scared when
all  nodes are assumed to be able to understand 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.

I admire the effort you're putting into this to avoid building a
centralized "God-Box". My problem is not with this step, but with
how we got here. Let's table this.


...

10. Feedback loops to NOC: The NOC needs to know about certain conditions:
 ...
Agreed! We have a draft explaining control loops, but we need to develop
the reference architecture and "day in the life" further to gain better
insight
into how this is done.

regards,
John

On Wed, Apr 20, 2016 at 5:49 AM, Michael Behringer (mbehring) <
[e-mail]> 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
>



-- 
regards,
John