Subject: [Anima] Intent "beginning to end"

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 20 Apr 2016 12:49:20 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Apr 2016 10:16:52 -0400

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Apr 2016 16:25:47 -0400

> Intent is split into sections, one for the ANI itself, others for specific Autonomic Functions

I didn't get this part.

    > Result: target configlet (not applied yet!!).

I disagree with the NB for two reasons.
First, "centrally" might mean "by vendor specific central system", and so we would
       need ANIMA so that different vendors can communicate.

Secondly, we might need to discover the central system that can do the
          interpretation,accounting,or arithmetic.

Consider Intent's relating to bandwidth allocation throughout a network might
need a central place to put all the numbers so that they can be added, and
then the resulting allocations ("configs") can be distributed back to the nodes.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 21 Apr 2016 06:48:11 +0000

>     > Intent is split into sections, one for the ANI itself, others for specific

This is multiplexing (well, de-multiplexing). Intent contains sections which pertain to a certain ASA. So the way I see it either an ASA polls for Intent for itself, or there is a notification to an ASA. 

How could we phrase that better? 
 
>           interpretation,accounting,or arithmetic.

I agree with you. But I'm not sure we're on the same page here in the group. Thus calling it out. 

To me, ANIMA should distribute Intent to nodes, and *nodes* interpret it and "translate" it locally to a config notation that makes sense to that device. 

> Consider Intent's relating to bandwidth allocation throughout a network
> might need a central place to put all the numbers so that they can be added,
> and then the resulting allocations ("configs") can be distributed back to the
> nodes.

I'm not sure which point you're making here? 

Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 21 Apr 2016 06:52:12 +0000

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 20 April 2016 16:17
> To: Michael Behringer (mbehring) <[email-masked]>; Anima WG
> <[email-masked]>
> 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
 
> > 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).
> >
> >     - these goals are formalised in a language --> 2. Intent: is the
> > formalisation of business goals so that computer can deal with them.
> >     - this file must be "given to the network" --> 3. Ingestion: The
> > Intent file(s) get instantiated on an autonomic node
> >     - Now it needs to be distributed --> 4. Intent Distribution:
> > Intent is flooded to all nodes in a network;
> >     - the Intent files must now be interpreted by each node --> 5.
> > Intent splitting (on each node):
> > 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
> >

---

From: Duzongpeng <[email-masked]>
Date: Thu, 21 Apr 2016 12:34:14 +0000

Hi, Michael Richardson

	About the "centrally" and "distributed", I want to suggest that it depends.

	Some simple ones perhaps is easy to handle, and every node can understand and interpret the intent. 

	I think Michael Behringer has suggested to start with some simple functions in the beginning.

	On the other side, I do not think ANIMA means every node make their own decisions for everything. 

	Some central node (maybe elected) may also exist in the ANIMA network for some functions, such as making some high level decision after collecting enough network information.

Best Regards
Zongpeng Du

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Thursday, April 21, 2016 4:26 AM
To: Anima WG
Cc: Michael Behringer (mbehring)
Subject: Re: [Anima] Intent "beginning to end"

I didn't get this part.

Consider Intent's relating to bandwidth allocation throughout a network might need a central place to put all the numbers so that they can be added, and then the resulting allocations ("configs") can be distributed back to the nodes.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 21 Apr 2016 12:58:10 +0000

> From: Duzongpeng [mailto:[email-masked]]
> Sent: 21 April 2016 14:34
> To: Michael Richardson <[email-masked]>
> Cc: Michael Behringer (mbehring) <[email-masked]>; Anima WG
> <[email-masked]>
> Subject: RE: [Anima] Intent "beginning to end"
> 
> Hi, Michael Richardson
> 
> 	Some central node (maybe elected) may also exist in the ANIMA
> network for some functions, such as making some high level decision after
> collecting enough network information.

Absolutely! However, there are two ways of doing that, and neither involves Intent: 

1 - NMS/controller gets feedback; sees that it needs to make some adjustments in some places: In this case it would use a standard NETCONF call (for example) to set corresponding parameters on specific nodes --> outside ANIMA scope; we simply state "every other configuration type overrides Intent". It's clear and easy. 

2 - NMS/controller gets feedback; sees that it needs to make some adjustments, and uses ANIMA signalling to signal directly via GRASP what needs to be done: That *is* in scope, but I think it is "after" Intent, and as such outside scope for the Intent draft. To me, an autonomic function has various ASAs, one of which could be in the NOC. They use GRASP / whatever to communicate. So this is really nothing to do with Intent. We just must make sure in ANIMA that autonomic functions with all related ASAs have the tools they need. 

(Someone might argue here that as a result of the feedback loop Intent should be changed; I would argue: Maybe; but since Intent is on business level, this would should involve some human intervention, thus a manual change of Intent, and the same flow applies again. I think dynamic changes to Intent are NOT a good idea. Put differently, I think Intent should not be touched by the network.)

These are good discussions! Do you agree with this view? If not, where not? 

Michael

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 Apr 2016 10:08:40 -0400

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.

Yours,
Joel

PS: Note that the number of clauses needed to define the intent heere is 
why I don't think about intent as being a single thing, but rather a 
collection of policy descriptions.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Apr 2016 12:53:25 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    >> might need a central place to put all the numbers so that they can be
    >> added and then the resulting allocations ("configs") can be
    >> distributed back to the nodes.

    > I'm not sure which point you're making here?

I'm saying that even when there is no need for a central system to interpret
Intent->Config, the set of nodes may still need (to elect) a central system
in order to coordinate the totals for some configuration.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 21 Apr 2016 16:57:10 +0000

> From: Michael Richardson [mailto:[email-masked]]
> Sent: 21 April 2016 18:53
> To: Michael Behringer (mbehring) <[email-masked]>
> Cc: Anima WG <[email-masked]>
> Intent->Config, the set of nodes may still need (to elect) a central
> Intent->system

Thanks for clarifying - yes, we agree!   But, see my mail to Duzongpeng earlier today, IMO this is outside scope of the Intent discussion, as I see it. The transactions you describe would be part of an Autonomic Function. Agree? 

Michael

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Apr 2016 13:01:28 -0400

Joel M. Halpern <[email-masked]> wrote:
    > intelligence
    > it has, can act on these policies themselves.  Yes, nodes can detect
    > violations, but I can not see how they can remediate independently.

Yes, this is a good example of the why we might need to elect a central
(bandwidth) manager, even though each AN can comprehend the Intent directly
itself.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 21 Apr 2016 17:01:59 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 21 April 2016 16:09
> 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: Michael Richardson <[email-masked]>
Date: Thu, 21 Apr 2016 13:04:35 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > (Someone might argue here that as a result of the feedback loop Intent
    > should be changed; I would argue: Maybe; but since Intent is on

I agree that the Intent should be immutable.
Maybe the NMS might tell the business person that the Intent is unreasonable
after trying to implement it, but that would result in a New Intent.

---

From: John Strassner <[email-masked]>
Date: Thu, 21 Apr 2016 13:34:47 -0700

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.

...

> (These goals are initially not formalised, in a computer science sense.

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.

...

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

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

>   The ANI as well as all ASAs on a node interpret their respective Intent.
...
See above.
...
>   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.

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

>   takes a decision and feeds that back to the autonomic functions. This
may modify

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

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 21 Apr 2016 13:46:40 -0700

+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 <[email-masked]>
wrote:

> into "intents", there will need to be an intelligent processing step that

-- 
regards,
John

---

From: "Natale, Bob" <[email-masked]>
Date: Thu, 21 Apr 2016 20:53:46 +0000

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:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, April 21, 2016 4:47 PM
To: Joel M. Halpern <[email-masked]>; John Strassner <[email-masked]>
Cc: Anima WG <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>
Subject: Re: [Anima] Intent "beginning to end"

+1.

regards,
John

On Wed, Apr 20, 2016 at 7:16 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> 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

Feedback?
Michael

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

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

--
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Apr 2016 09:02:07 +1200

On 22/04/2016 08:46, John Strassner wrote:
...
>        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

---

From: John Strassner <[email-masked]>
Date: Thu, 21 Apr 2016 14:10:18 -0700

>> Intent is split into sections, one for the ANI itself, others for
specific
>> Autonomic Functions

> This is multiplexing (well, de-multiplexing). Intent contains sections
> which pertain to a certain ASA. So the way I see it either an ASA
> polls for Intent for itself, or there is a notification to an ASA.
>

Sorry, I'm lost.

If we have a generic, abstract intent (e.g., ensure that no node exceeds
70% processor utilization, or ensure that Gold and Platinum Service
always get the best possible service for a set of particular applications),
then how does the node know that it is the target? A higher-level
management entity must decide that this particular node is indeed
involved, and this can change dynamically.

Since we don't necessarily want intent policies of the form
   "Ethernet 1/1/2 gets AF31" :-)
then we need something (an ASA?) to select the set of target nodes
(hopefully based on context). This is part of my argument for
post-processing the (raw) intent that is received by the first
autonomic node in the network, and then try to understand intent.

regards,
John

On Wed, Apr 20, 2016 at 11:48 PM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> >     > Intent is split into sections, one for the ANI itself, others for
> specific
> > Autonomic Functions
> >
> > I didn't get this part.
>
> This is multiplexing (well, de-multiplexing). Intent contains sections
> which pertain to a certain ASA. So the way I see it either an ASA polls for
> Intent for itself, or there is a notification to an ASA.
>
> >     > 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,
> >     > (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
> > First, "centrally" might mean "by vendor specific central system", and
> so we
> > would
> To me, ANIMA should distribute Intent to nodes, and *nodes* interpret it
> and "translate" it locally to a config notation that makes sense to that
> device.
>
> added,

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 21 Apr 2016 17:25:56 -0700

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) <
[email-masked]> wrote:

> into
> 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
> :-)
>
> usable
> 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.
>
> > > Let me try to write down this "flow", as I see it, as a starting point
> for
> > discussion.
> > >
> > >     The target configlet resulting from Intent has the lowest prio;
> any other
> > management
> > >     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.
> > >     To some extent, Intent itself can specify which conditions should
> trigger
> > feedback
> > >     loops to the NOC.

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 21 Apr 2016 17:36:35 -0700

> (Someone might argue here that as a result of the feedback loop
> Intent should be changed; I would argue: Maybe; but since Intent
> is on business level, this would should involve some human
> intervention, thus a manual change of Intent, and the same flow
> applies again.

It depends. I think that ANIMA SHOULD (in the IETF sense) work
on what you describe above, and decouple intent from the control
loops. However, we need to be careful of the edge cases. For
example, if intent is to give a customer Platinum Service, and that
cannot be done, hopefully the system realizes that Gold is the best
we can do and proceeds (as opposed to giving the customer
nothing).

> I think dynamic changes to Intent are NOT a good idea. Put
> differently, I think Intent should not be touched by the network.)

Now I'm confused. If intent in its raw form is flooded to every node
in the network, clearly some node is going to have to touch it and/or
transform it into a form that other nodes can understand. Joel and I
have given some examples of when this is needed. This is why I
objected to the overhead of all nodes having to be able to parse
intent, let alone understand and act on it.

I think (and hope) that what you are saying is that the network
SHOULD NOT alter the "intent of the intent" (sorry!). This means
that transformation (without changing meaning) is perfectly fine,
but changing the semantics would, for example, not be allowed.
Is this correct?

regards,
John

On Thu, Apr 21, 2016 at 5:58 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

> 1 - NMS/controller gets feedback; sees that it needs to make some
> adjustments in some places: In this case it would use a standard NETCONF
> call (for example) to set corresponding parameters on specific nodes -->
> outside ANIMA scope; we simply state "every other configuration type
> overrides Intent". It's clear and easy.
>
> 2 - NMS/controller gets feedback; sees that it needs to make some
> adjustments, and uses ANIMA signalling to signal directly via GRASP what
> needs to be done: That *is* in scope, but I think it is "after" Intent, and
> as such outside scope for the Intent draft. To me, an autonomic function
> has various ASAs, one of which could be in the NOC. They use GRASP /
> whatever to communicate. So this is really nothing to do with Intent. We
> just must make sure in ANIMA that autonomic functions with all related ASAs
> have the tools they need.
>
> should be changed; I would argue: Maybe; but since Intent is on business
> level, this would should involve some human intervention, thus a manual
> change of Intent, and the same flow applies again. I think dynamic changes
> to Intent are NOT a good idea. Put differently, I think Intent should not
> be touched by the network.)
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 21 Apr 2016 17:52:56 -0700

While waiting for Laurent to return, I'd like to offer my view
(I've graduated a couple of Ph.D. students in this subject, btw).

I don't see this as conflict resolution IFF this is a declarative
intent. (If it is procedural or imperative, then possibly, but even
then, I'm not convinced). This is because a set of traffic selection
and action policies could be defined that have no conflicts at all.
Furthermore, just because different functions are involved does not
mean that they conflict - they only have the potential to conflict.
For example, a service chain has different functions, and they better
not conflict...

As yet another example, if I implemented this using a declarative
logic program, then by definition there would not be any conflicts.
I would instead call this "service compatibility checking" (a horrible
name, sorry, but the problem is that "conflict resolution" has very
defined semantics in the policy world).

All this being said, if there is a conflict, then:

   1) some type of sanity checking SHOULD be done, but I'm assuming
      that this is done BEFORE the intent is sent to the network
   2) if an actual conflict does occur, then I do agree that this is
      NOT an intent or intent distribution problem.

regards,
John

On Thu, Apr 21, 2016 at 10:01 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

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

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Thu, 21 Apr 2016 18:15:29 -0700

...

> 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.
I disagree. Look at the programming world. Visual Basic is much
more used and popular than other languages that are more * (insert
whatever you'd like - elegant, concise, extensible, performant, ...).
Even for my personal favorite (Prolog), there are differences
between ISO and Edinburgh Prolog as well as differences in
implementations.

The fact that we are defining this to address the business user (at
least in part) makes it that much harder. We could never agree on
CLI - and we knew what we were doing in CLI. MIBs were worse. Sorry,
but based on this, I have no confidence whatsoever we will agree on a
standard high-level language that is declarative in nature.
Furthermore, even if we could accomplish a miracle and do this, I
still don't understand why EVERY node has to have this function.
Look at DiffServ - one Carrier uses AF4x, another uses AF3x, a
third might use CS4 or CS5. Nodes don't know how to do this
mapping - something else (typically a human) does.

> Given that we know it needs to be interpreted by individual
> ASAs, shouldn't we design it to be readily interpreted?

Of course. The problem is, no such proposal, or even spec, exists.
I've spent over a year in the ONF discussing a white paper that
still is having problems defining precisely what intent is. Same
in the TMF. The only working examples that one could argue are
declarative (OpenStack Congress and ODL GBP) that I am familiar
with are nowhere close to being able to be consumed by a business
user. Even good application developers have trouble with them.

...

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

Not necessarily. Take any of Joel's or my examples - how does an
ASA know what Platinum Service is for ONE Carrier, let alone many?
Wouldn't it be (much) simpler to offload this to a specialized ASA
that had the processing power, as well as access to other resources
(e.g., ontologies, FOL processing, computational linguistics) to
do the transformation? Then, once the intent is translated to a form
that the ASA can understand, it can proceed while needing much less
resources and processing power.

regards,
John

-- 
regards,
John