Subject: Re: [Anima] ANIMA intent discussion

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 1 Apr 2016 07:05:24 +0000

We’re starting to call everything that flies through an autonomic network Intent, and the naming is getting very confusing.

To me: Intent = network wide human input policy
everything else: not Intent. Call it signaling, messaging, feedback loops, SNMP, GRASP, whatever.

Of course a node may, looking at Intent, need to negotiate something with a neighbour; or, run a feedback loop with the operator alerting him of an exceptional condition; or there may be specific messages between nodes to resolve a conflict. None of these are Intent.

So a node receives this human input policy, which I suggest we flood across the entire network. Everything after that is NOT Intent.

Michael

From: Anima [mailto:[email-masked]] On Behalf Of Duzongpeng
Sent: 01 April 2016 05:56
To: Laurent Ciavaglia <[email-masked]>; anima <[email-masked]>
Cc: Michael Behringer (mbehring) <[email-masked]>; Pierre Peloso <[email-masked]>
Subject: Re: [Anima] ANIMA intent discussion

Hi, Michael, Laurent, Pierre

         About whether ASA can issue intent, according to my understanding, intent should be issued by human by default.

         But in the discussion, I realize that we may have two kinds of intent.

         The first kind of intents are the ones issued from humans, perhaps not only from one person.

         And another is the intent after the coordination. They are the intent influencing the node directly. I mean coordination does not need to happen on every node, and they only need the result.

         This is an interesting model. If we can find some examples, I think perhaps some ASAs may choose to use intent like this, and ASA can issue the second kind of intent.

         Again, if someone think these are just some signals or messages, we can give it another name, such as “network-level policy” or “intent after coordination”.

Best Regards
Zongpeng Du

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: Thursday, March 31, 2016 12:10 AM
To: anima
Cc: Michael Behringer; Pierre Peloso; Duzongpeng; Laurent Ciavaglia
Subject: ANIMA intent discussion

Dear all,

Michael, Zongpeng, Pierre and I had a discussion on ANIMA intent this morning, trying to clarify some points and progress toward a common understanding.

We used a small, partial set of questions and examples in support.

Below you may find a summary for your information. Comments and further interactions are most welcome.

Thanks,
Michael, Zongpeng, Pierre and Laurent.
---

--- Questions
1-Who writes intents?
2-How many intents?
3-How many domains?
4-What are the intent levels/hierarchy?
5-Where/by what is intent processed/compiled?
6-Flooding: what are the requirements?
Propagation among who? How distributed? How frequent? -> if many “overlapping” intents, (partial) updates may become frequent.
7-How is intent understood by node/ASA? -> model, dictionary...
8-Can an ASA write an intent for another ASA?
What about coordination or knowledge writing/receiving intents? Are these functions ASAs/other things..?

--- Intent examples
A-Do the right thing
B-Freeze network enrollment
C-Arrange VM guest distribution so that (CPU) utilization is < 70%
D-Assign prefixes to RAN nodes
E-Protect premium users traffic
F-Maximize energy savings

--- Discussion
1) Who writes intents?
   Laurent's view:
    Intents are issued by a management function. Can be human / via BSS/OSS.
   Michael's view:
    Origin of intent is "non-technical". i.e., registrar doesn't issue intent.
   Discussion: how to set the cursor on non-technical? In examples D or E, the intent writer has some rough knowledge/understanding of technical aspects of a network (wireless and address aspects for example D ; protection/restoration and traffic engineering for example E).
   Consensus: Intent is originated by human/at OSS level, NOT by a network device / function. (of course Intent can be ingested / inputted on a specific device)

2) How many intents?
   Laurent's view:
    There may be different ones, like "freeze network", "optimize energy savings", cf examples. All are valid and concurrent.
    Can we wrap that into one file?
    How do we share that?

    Discussion:
    We cannot define Intent too precisely today.
    But we can define where Intent is coming from and how to distribute it.

    Can Intent have targets?
        - Ex: an intent for traffic engineering and an intent for energy consumption optimization may need specific (same or different) targets. the functions could have different objectives per set of targets.
        - Ex: two network segments, core and metro. Then intent should be able to say "on core: optimize on availability"; on access: "optimize on energy saving."
        - Therefore we need scopes.

     How do you define "target"?
        - Is a role enough?
        - Pierre: Should be more than role. Example: Metro and core. Need to distinguish between different metro networks for example.
        - Michael: If we have sub-domains, and define intent per sub-domain, would that do?
        - Laurent: a combination of roles and (sub-)domain(s) should be able to cover most cases.

    Consensus: a combination of roles and (sub-)domain(s) should be able to cover most cases.

8) Can an ASA write an intent?
    Pierre: Example is the coordination function: that function could send out intent directly to modify the behavior of a group of ASAs.
     Multiple ASAs could do conflicting things. The coordination function must resolve that. Should it issue/modify intent itself?
    Laurent: q1: should it output something in the form of an intent? q2: should the coordination function update intent?
    Michael: Isn't it that the behavior of the coordination function must also be resolved by a human originated intent? i.e. the conflicting functions inform the operator via a feedback loop and the operator adjust the intents.
    Laurent: This is possible / complementary. In once case, the operator is the one closing the control loop / changing the behaviors via intent updates. With a coordination function, part/all of that process could be automated/driven by the machine (the coordination function closes the control loop, in the control range allowed by the operator). There may be intermediate steps where unforeseen conflicts will be resolved. This is run time conflict resolution.
    Michael: Do we foresee a case where networks resolve conflicts without human control?
    Laurent: this is possible (has been demonstrated in some projects). We should allow for both approaches to work, possibly in a phased approach.

    When unforeseen conflicts arise, ASAs can signal to each other, but they will not issue Intent themselves.

    Consensus: Cannot say today if other functions can/are allowed to issue intent / intent updates. Functions/ASAs may have to *signal* or *message* somehow, but that this isn’t considered     intent yet.
    For further study: try to design the intent system so that both approaches (feedback loop, coordination) are possible. More investigation/analysis needed.

3) How many domains?
    Naming issue: "domain" by Laurent is a high level concept; could be understood as a DNS domain name. Needs to be clear what we're talking about.
    With domain-name based intent (i.e., access.att.net) and roles (e.g, access devices) we should be able to express what we need for now. Not 100% clear for now.
    Two types of domains: (administrative, technology) domains defined (a priori) by the operator e.g. RAN, MAN, WAN. and the domain of application of a policy i.e. resolving the policy defines a set of target entities to which teh policy applies, this is the domain of application of the given policy.

    Consensus: Need to clarify wording to avoid confusion.

4) What are the intent levels/hierarchy?
    Related to policy based manamegent model: business level, service level, network level, device level, etc. So far in ANIMA we consider only two levels: User and ASA.
    Do we need a service level? e.g, VPN.
    Can we express different levels with using roles? So a role could be very specific (route reflector), or service related (e.g., VPN head-end)?
    But then we may need to nest roles?!
    Maybe we need "business" "service" "network (ASA)" level?

    Consensus: to be further discussed.

Questions 5, 6, 7 were not discussed due to lack of time.
---

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 1 Apr 2016 09:16:02 -0400

I think even with this definition, we do not have a clear scope.

let me use two very similar examples:

1) Intent: Turn of admission of new nodes to the system.  This is human 
generate, in response to observed but unspecified conditions.  It 
applies from now until the human turns it off.  Anima can act on this.

2) Intent: If average network link load exceeds 70%, do not admit any 
new nodes to the system.  This is also a human defined intent.  However, 
I do not see how this intent can be distributed to the Anima 
participants and acted on.  It has to be processed by some other system. 
  And when the condition is observed, the system will generate something 
like intent 1, which will be processed by Anima, even thout it is not 
directly human input.

Yours,
Joel

On 4/1/16 3:05 AM, Michael Behringer (mbehring) wrote:
> We’re starting to call everything that flies through an autonomic
> network Intent, and the naming is getting very confusing.
>
> Of course a node may, looking at Intent, need to negotiate something
> with a neighbour; or, run a feedback loop with the operator alerting him
> of an exceptional condition; or there may be specific messages between
> nodes to resolve a conflict. None of these are Intent.
>
> So a node receives this human input policy, which I suggest we flood
> across the entire network. Everything after that is NOT Intent.
>
> Michael
>
> *From:*Anima [mailto:[email-masked]] *On Behalf Of *Duzongpeng
> *Sent:* 01 April 2016 05:56
> *To:* Laurent Ciavaglia <[email-masked]>; anima
> <[email-masked]>
> *Cc:* Michael Behringer (mbehring) <[email-masked]>; Pierre Peloso
> <[email-masked]>
> *Subject:* Re: [Anima] ANIMA intent discussion
>
>           About whether ASA can issue intent, according to my
> understanding, intent should be issued by human by default.
>
>           And another is the intent after the coordination. They are the
> intent influencing the node directly. I mean coordination does not need
> to happen on every node, and they only need the result.
>
>           This is an interesting model. If we can find some examples, I
> think perhaps some ASAs may choose to use intent like this, and ASA can
> issue the second kind of intent.
>
>           Again, if someone think these are just some signals or
> messages, we can give it another name, such as “network-level policy” or
> “intent after coordination”.
>
> Best Regards
>
> Zongpeng Du
>
> *From:*Laurent Ciavaglia [mailto:[email-masked]]
> *Sent:* Thursday, March 31, 2016 12:10 AM
> *To:* anima
> *Cc:* Michael Behringer; Pierre Peloso; Duzongpeng; Laurent Ciavaglia
> *Subject:* ANIMA intent discussion
>
> Dear all,
>
> Michael, Zongpeng, Pierre and I had a discussion on ANIMA intent this
> morning, trying to clarify some points and progress toward a common
> understanding.
>
> Propagation among who? How distributed? How frequent? -> if many
> “overlapping” intents, (partial) updates may become frequent.
> _Discussion:_ how to set the cursor on non-technical? In examples D or
> E, the intent writer has some rough knowledge/understanding of technical
> aspects of a network (wireless and address aspects for example D ;
> protection/restoration and traffic engineering for example E).
> _Consensus:_ Intent is originated by human/at OSS level, NOT by a
> network device / function. (of course Intent can be ingested / inputted
> on a specific device)
>
>
> 2) How many intents?
>     Laurent's view:
>      There may be different ones, like "freeze network", "optimize
> energy savings", cf examples. All are valid and concurrent.
> _Discussion:_
>          - Ex: an intent for traffic engineering and an intent for
> energy consumption optimization may need specific (same or different)
> targets. the functions could have different objectives per set of targets.
>          - Ex: two network segments, core and metro. Then intent should
> be able to say "on core: optimize on availability"; on access: "optimize
> on energy saving."
>          - Pierre: Should be more than role. Example: Metro and core.
> Need to distinguish between different metro networks for example.
> _Consensus:_ a combination of roles and (sub-)domain(s) should be able
> to cover most cases.
>
>
>      Pierre: Example is the coordination function: that function could
> send out intent directly to modify the behavior of a group of ASAs.
>       Multiple ASAs could do conflicting things. The coordination
> function must resolve that. Should it issue/modify intent itself?
>      Laurent: q1: should it output something in the form of an intent?
> q2: should the coordination function update intent?
>      Michael: Isn't it that the behavior of the coordination function
> must also be resolved by a human originated intent? i.e. the conflicting
> functions inform the operator via a feedback loop and the operator
> adjust the intents.
>      Laurent: This is possible / complementary. In once case, the
> operator is the one closing the control loop / changing the behaviors
> via intent updates. With a coordination function, part/all of that
> process could be automated/driven by the machine (the coordination
> function closes the control loop, in the control range allowed by the
> operator). There may be intermediate steps where unforeseen conflicts
> will be resolved. This is run time conflict resolution.
>      Laurent: this is possible (has been demonstrated in some projects).
> We should allow for both approaches to work, possibly in a phased approach.
>
> _Consensus:_ Cannot say today if other functions can/are allowed to
> issue intent / intent updates. Functions/ASAs may have to *signal* or
> *message* somehow, but that this isn’t considered     intent yet.
>      For further study: try to design the intent system so that both
> approaches (feedback loop, coordination) are possible. More
> investigation/analysis needed.
>
>
> 3) How many domains?
>      Naming issue: "domain" by Laurent is a high level concept; could be
> understood as a DNS domain name. Needs to be clear what we're talking
> about.
>      With domain-name based intent (i.e., access.att.net) and roles
> (e.g, access devices) we should be able to express what we need for now.
> Not 100% clear for now.
>      Two types of domains: (administrative, technology) domains defined
> (a priori) by the operator e.g. RAN, MAN, WAN. and the domain of
> application of a policy i.e. resolving the policy defines a set of
> target entities to which teh policy applies, this is the domain of
> application of the given policy.
>
> _Consensus:_ Need to clarify wording to avoid confusion.
>
>
>      Related to policy based manamegent model: business level, service
> level, network level, device level, etc. So far in ANIMA we consider
> only two levels: User and ASA.
>      Can we express different levels with using roles? So a role could
> be very specific (route reflector), or service related (e.g., VPN
> head-end)?
> _Consensus:_ to be further discussed.
>
>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Fri, 1 Apr 2016 15:20:51 +0000

I would like to think that Intent can be something that can be defined by a technical person and then in-acted by someone less or non-technical.
I think that Laurent is right that the definition of Intent, how it written, presented, and checked is a project that is quite large and likely outside the scope of ANIMA. I think that ANIMA will closely monitor the definition of Intent and have impact on it as well as others that are interested in using Intent.  Seems that if done properly ANIMA would be one method to deliver Intent, but not the only method.

--
Jason Coleman CCIE#12069
[email-masked]<mailto:[email-masked]>
phone: +1 512-340-3134
Technical Lead Engineer CMS

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

From: Anima <[email-masked]<mailto:[email-masked]>> on behalf of Laurent Ciavaglia <[email-masked]<mailto:[email-masked]>>
Organization: Bell Labs
Date: Thursday, March 31, 2016 at 4:13 AM
To: "Michael Behringer (mbehring)" <[email-masked]<mailto:[email-masked]>>, Martin Vigoureux <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Anima] ANIMA intent discussion

On 31/03/2016 10:40, EXT Michael Behringer (mbehring) wrote:

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Martin
Vigoureux
Sent: 31 March 2016 10:36
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] ANIMA intent discussion

I think that the person should at least be knowledgeable enough to
understand (the implications of) what he/she is asking for.

Agree. But a good user interface can solve that / help with it.

Michael

I agree with both of you ;)
Using some sort of catalog (suggested by John S. few days ago on the list) is a first step: capabilities of the "network" (ASAs, other things...) are expressed, aggregated (maybe annotated) in a common format understandable to the user (technical and/or non-technical). This sets a first bound on what the user can or cannot do.
Other aspects to consider: (properties of) language (or other means) offered to the user to write the intents, ontologies / common lexicon, safeguards on values/syntax checking, etc.
a full project on its own! let's go for a BoF ;)

Laurent.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Apr 2016 13:48:58 +1300

> Seems that if done properly ANIMA would be one method to deliver Intent, but not the only method.

Absolutely. That's one reason that GRASP is agnostic about the content (value)
of any objective, including a synchronization objective used to transport Intent.
The only rule is that it must have a defined CBOR encoding, which is a pretty
general rule.

We do need to get a feeling for how big that object will be though. It affects
whether we can flood it via multicast.

Regards
   Brian

---

From: John Strassner <[email-masked]>
Date: Sat, 2 Apr 2016 08:31:25 -0700

Hi Laurent, et al.,

thanks for doing this. I'm shortening to just provide my opinions...

1) Who writes intents?
       ...
   *Consensus:* Intent is originated by human/at OSS level, NOT by a
network device / function. (of course Intent can be ingested / inputted on
a specific device)

<jcs>
Intent is originated by humans at the OSS/BSS level. Intent is one
of many expressions of policies. It is translated to lower-level
forms that are eventually consumed by devices.
</jcs>

2) How many intents?
...
  *Discussion**:*

<jcs>
It is unlikely to have one set of intent APIs or DSL. This is
because people have different concepts, terminologies,
and vocabularies. Common models will help interoperability.

I do not think that it is necessary to combine disparate
intents into a single file.
</jcs>

  Can Intent have targets?
      - Ex: an intent for traffic engineering and an intent for energy
consumption optimization may need specific (same or different) targets. the
functions could have different objectives per set of targets.
      - Ex: two network segments, core and metro. Then intent should be
able to say "on core: optimize on availability"; on access: "optimize on
energy saving."
      - Therefore we need scopes.

<jcs>
Policy management theory, dating back to at least 1994, has defined the
concepts of Policy Subjects and Policy Targets. The main difference
between intent and imperative (CA/ECA) policies is that intent should not
need to explicitly specify either, whereas imperative policies do need to
explicitly specify at least targets.
</jcs>

     How do you define "target"?
          ...
    *Consensus:* a combination of roles and (sub-)domain(s) should be able
to cover most cases.

<jcs>
Many past works have used the combination of role, domains, and context.
Context is critical to enable the autonomic network to "do the right thing"
in
response to change.
</jcs>

8) Can an ASA write an intent?
    Pierre: Example is the coordination function: that function could send
out intent directly to modify the behavior of a group of ASAs.
     Multiple ASAs could do conflicting things. The coordination function
must resolve that. Should it issue/modify intent itself?
    Laurent: q1: should it output something in the form of an intent? q2:
should the coordination function update intent?

<jcs>
The fundamental difference between intent and other types of policies
is that intent is at a higher level of abstraction. Therefore, an ASA
would have to understand the nature of the intent (e.g., its grammar)
in order to modify or generate intent.

In systems that I have seen, this is typically done by the (equivalent of
an ASA) sending instructions in its own grammar, and having a set of
agents translate to intent and distribute it. Note that this has been
typically done using a pub-sub bus; I don't personally know of any
systems that used (hopefully constrained) flooding.

Regarding conflict - IFF intent is truly declarative, then it should not
(at least in principle) produce conflicts. Even if different subjects
authored conflicts, when they are all combined into a declarative
logic function, they MUST be resolved. (Note that here, I am using
logic programming as an example of "truly declarative".)
</jcs>

    Michael: Isn't it that the behavior of the coordination function must
also be resolved by a human originated intent? i.e. the conflicting
functions inform the operator via a feedback loop and the operator adjust
the intents.
    Laurent: This is possible / complementary. In once case, the operator
is the one closing the control loop / changing the behaviors via intent
updates. With a coordination function, part/all of that process could be
automated/driven by the machine (the coordination function closes the
control loop, in the control range allowed by the operator). There may be
intermediate steps where unforeseen conflicts will be resolved. This is run
time conflict resolution.
    Michael: Do we foresee a case where networks resolve conflicts without
human control?
    Laurent: this is possible (has been demonstrated in some projects). We
should allow for both approaches to work, possibly in a phased
approach.

<jcs>
Agreed. What's important is closing the loop. While there are
some simple behaviors that can be automatically resolved by
the network, this is the exception, not the rule. (In FOCALE,
as well as other OODA-based control loops, this is facilitated
by recognizing past and new states, and matching behavior
to those states.)
</jcs>

When unforeseen conflicts arise, ASAs can signal to each other, but they
will not issue Intent themselves.

<jcs>
Agree.
</jcs>

*Consensus:* Cannot say today if other functions can/are allowed to issue
intent / intent updates. Functions/ASAs may have to *signal* or *message*
somehow, but that this isn’t considered     intent yet.
    For further study: try to design the intent system so that both
approaches (feedback loop, coordination) are possible. More
investigation/analysis needed.

<jcs>
In some systems, such as FOACLE, intent update was done
by matching state (and its desired behavior) to context. Again,
this is the exception, not the common case. In general, systems
that I have worked on provide the operator with enough data
to enable the operator to decide what to do. Even if the system
thinks it knows what to do, it can still present this conclusion
to the operator. (Aside: this is why I like logic-based declarative
systems, as it is relatively simple to provide explanations of the
decisions taken.)
</jcs>

3) How many domains?
    ...

<jcs>
>From my book "Policy-Based Network Management":

    A **policy domain** is a collection of manageable entities that
    are operated on using a common set of policies. The policies
    are used to administer and control the set of characteristics
    and behavior of these manageable entities.

This is a generalization of RFC1930. The idea is to define a
collection of manageable entities whose behavior is governed
by a common set of policies.

Sub-domains MUST use the policies of their parent domains,
but are free to define new policies as long as they do not
conflict with the behavior of their parent domains.
</jcs>

4) What are the intent levels/hierarchy?
    Related to policy based manamegent model: business level, service
level, network level, device level, etc.
       ...

<jcs>
The above is the first four parts of the Policy Continuum. When I
defined this, I also stated that the explicit number of continua is
not that important - what is important is the set of constituencies
that are using each continuum.

In other words, if it is important to the system to differentiate
between the roles of customer-facing and internal-facing
application developers, then that should be reflected in the
number of policy continua defined.
</jcs>

Questions 5, 6, 7 were not discussed due to lack of time.
5-Where/by what is intent processed/compiled?
6-Flooding: what are the requirements? Propagation among who? How
distributed? How frequent? -> if many “overlapping” intents, (partial)
updates may become frequent.
7-How is intent understood by node/ASA? -> model, dictionary...

<jcs>
5:  Intent is processed/compiled by dedicated entities (in my
case, these are agents). This is because it takes specific
resources and specific knowledge to do this.

6: I prefer pub-sub. If flooding, then it should be constrained.

7:  In general, Intent is NOT understood by nodes or ASAs.
This is because the node or ASA would have to have access
to additional significant resources.

In my experience, nodes and ASAs will implement the lower
levels of the Policy Continuum only, and assume that any
higher levels of policy are first transformed to a form that
they can consume.
</jcs>

regards,
John

On Wed, Mar 30, 2016 at 9:10 AM, Laurent Ciavaglia <
[email-masked]> wrote:

> 6-Flooding: what are the requirements? Propagation among who? How
> distributed? How frequent? -> if many “overlapping” intents, (partial)
> updates may become frequent.
> 8-Can an ASA write an intent for another ASA? What about coordination or
> knowledge writing/receiving intents? Are these functions ASAs/other
> things..?
>
>
> --- Intent examples
> A-Do the right thing
>    *Discussion:* how to set the cursor on non-technical? In examples D or
>    *Consensus:* Intent is originated by human/at OSS level, NOT by a
> network device / function. (of course Intent can be ingested / inputted on
> a specific device)
>
>
> 2) How many intents?
>    Laurent's view:
>     There may be different ones, like "freeze network", "optimize energy
> savings", cf examples. All are valid and concurrent.
>     *Discussion**:*
>         - Ex: an intent for traffic engineering and an intent for energy
> consumption optimization may need specific (same or different) targets. the
> functions could have different objectives per set of targets.
>         - Ex: two network segments, core and metro. Then intent should be
> able to say "on core: optimize on availability"; on access: "optimize on
> energy saving."
>         - Pierre: Should be more than role. Example: Metro and core. Need
> to distinguish between different metro networks for example.
>     *Consensus:* a combination of roles and (sub-)domain(s) should be
> able to cover most cases.
>
>
>     Pierre: Example is the coordination function: that function could send
> out intent directly to modify the behavior of a group of ASAs.
>      Multiple ASAs could do conflicting things. The coordination function
> must resolve that. Should it issue/modify intent itself?
>     Laurent: q1: should it output something in the form of an intent? q2:
> should the coordination function update intent?
>     Michael: Isn't it that the behavior of the coordination function must
> also be resolved by a human originated intent? i.e. the conflicting
> functions inform the operator via a feedback loop and the operator adjust
> the intents.
>     Laurent: This is possible / complementary. In once case, the operator
> is the one closing the control loop / changing the behaviors via intent
> updates. With a coordination function, part/all of that process could be
> automated/driven by the machine (the coordination function closes the
> control loop, in the control range allowed by the operator). There may be
> intermediate steps where unforeseen conflicts will be resolved. This is run
> time conflict resolution.
>     Laurent: this is possible (has been demonstrated in some projects). We
> should allow for both approaches to work, possibly in a phased approach.
>
>     *Consensus:* Cannot say today if other functions can/are allowed to
>     With domain-name based intent (i.e., access.att.net) and roles (e.g,
> access devices) we should be able to express what we need for now. Not 100%
> clear for now.
>     Two types of domains: (administrative, technology) domains defined (a
> priori) by the operator e.g. RAN, MAN, WAN. and the domain of application
> of a policy i.e. resolving the policy defines a set of target entities to
> which teh policy applies, this is the domain of application of the given
> policy.
>
>     *Consensus:* Need to clarify wording to avoid confusion.
>
>
> level, network level, device level, etc. So far in ANIMA we consider only
> two levels: User and ASA.
>     Can we express different levels with using roles? So a role could be
> very specific (route reflector), or service related (e.g., VPN head-end)?
>     *Consensus:* to be further discussed.
>
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Apr 2016 13:09:30 +1200

On 03/04/2016 03:31, John Strassner wrote:

<snipped even more vigorously>
...
> intents into a single file.

That seems to mean that each recipient of multiple files has to
performance consistency checks and conflict resolution, unless
you have a watertight definition of 'disparate'.

...
> resources and specific knowledge to do this.

Well, we definitely need to talk about that. Do you mean that
each autonomic node would contain such an agent, or that such
agents would be few in number?

> 6: I prefer pub-sub. If flooding, then it should be constrained.

Constrained flooding is the hardest case. If Intent is small, why
can't we flood it, with unicast pub/sub to fill in any gaps?

> to additional significant resources.

If there is Intent support code in each node, is that a problem?
Also, if there is Intent that is meaningful only to certain ASAs,
how can that semantic be handled in a generic Intent handler?

Rgds
  Brian

---

From: John Strassner <[email-masked]>
Date: Sun, 3 Apr 2016 07:59:27 -0700

Hi Brian,

...

> you have a watertight definition of 'disparate'.

No, it means that:

   a) I don't believe that network elements are, in general, autonomic
   b) I believe that higher level autonomic managers are needed
       to perform these and other tasks.

> agents would be few in number?

That is dependent on the overall architectural approach. In
systems that I have built, I have kept to the classic definition of
agent, where it knows how to do a few things well. So, as in
the AAMAS set of conferences, there are many types of agents
that each perform one (or a few) tasks very well.

In this approach, the nodes use however many agents they need.

> can't we flood it, with unicast pub/sub to fill in any gaps?

Because I fail to see why most nodes would care about intent.
The nodes are not autonomic, the autonomic managers are.
You can't build an autonomic system by making every
component autonomic - you can build an autonomic system
by having the components collaborate to produce autonomic
behavior. That's where we differ.

> If there is Intent support code in each node, is that a problem?

If intent support code is present, then it is there for a good reason
(or at least I hope so), and hence, no, that is not a problem.
However, I don't believe that this is the normal case, since in my
view, Intent is not a PERL script, a python program, or a set of
APIs - it is instead a (restricted) natural language. Putting a
compiler for this on a router or switch is not a good idea, since
you would also need ontologies or some type of computational
linguistic processing to handle not just synonyms, but variations
in phrasing, etc. That's why I keep saying that these and other
support functions should be in a (distributed) autonomic manager,
and that the autonomic manager translate intent to a form that
is consumable by the device.

I haven't seen a good argument against this approach. To my
knowledge, this approach is what has been commonly built.

> how can that semantic be handled in a generic Intent handler?

That's why I prefer pub-sub to flooding.

regards,
John

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 4 Apr 2016 08:14:36 +1200

John,
>        to perform these and other tasks.

Of course, see my next comment.

> The nodes are not autonomic, the autonomic managers are.

Ah, I see that we have a slight terminology mismatch. When I write
"flood" I mean, very specifically, something sent to all autonomic
nodes. (Even more specifically, to all GRASP nodes, which listen
to the GRASP link-local multicast address.) Certainly, each such
node may be managing any number of non-autonomic nodes that don't
understand Intent and will not receive it.

>> If there is Intent support code in each node, is that a problem?

Read "node" as "autonomic node".

> compiler for this on a router or switch is not a good idea, since

Well, IMHO it would be an interpreter...

> in phrasing, etc. 

... and IMHO the Intent language would *not* be like that; it would
be algorithmic. What's the value in allowing it to be sloppy? Also,
how can that approach be correctly internationalised? Whatever we do
must be very straightforward whatever language the human operator
speaks, which means that its syntax has to be rigid (and preferably
1:1 translatable from an English-like presentation to any other
language).

> That's why I keep saying that these and other

If you mean that an autonomic node will manage (configure) any
number of subsidiary non-autonomic devices, we agree. And I think
this is something we should state explicitly in the reference model,
which I believe is missing at the moment. It is stated in the
GRASP spec, which is probably the wrong place for it:
   It is understood that in realistic deployments, not all devices will
   support GRASP.  It is expected that some autonomic service agents
   will directly manage a group of non-autonomic nodes, and that other
   non-autonomic nodes will be managed traditionally.

> That's why I prefer pub-sub to flooding.

I find that contradictory with your description of it as pseudo-natural
language; what we deliver to ASAs needs to be straightforward to interpret.

Rgds
  Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Apr 2016 10:48:02 -0400

> To me: Intent = network wide human input policy

okay. So to use the server load situation, the Intent from the human might be:
   "Keep all CPUs between 50% and 70% utilization"

(The Human might even specify this more abstractly as:
     "Minimize power consumption, while protecting against CPU load spikes
     of up to 30%")

    > loops, SNMP, GRASP, whatever.

So, a node that finds itself at lower than 50% utilization wants to migrate
it's load elsewhere, and so it needs to signal that it is looking for
something to take over so that it can turn itself off.  That's a signal.

Is that signal in scope?

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Apr 2016 10:52:07 -0400

Joel M. Halpern <[email-masked]> wrote:
    > generate, in response to observed but unspecified conditions.  It applies
    > from now until the human turns it off.  Anima can act on this.

I don't like this Intent; and I don't think that ANIMA Intents can be turned
on/off, but rather given expiration dates which may be extended.  Maybe
that's a detail, but I think it's important that ANIMA Intents are never
withdrawn.

    > 2) Intent: If average network link load exceeds 70%, do not admit any new
    > nodes to the system.  This is also a human defined intent.  However, I do not
    > see how this intent can be distributed to the Anima participants and acted
    > on.  It has to be processed by some other system. And when the condition is
    > observed, the system will generate something like intent 1, which will be
    > processed by Anima, even thout it is not directly human input.

The proxy/registrar, upon seeing this ANIMA Intent would have to do an ASA search
for a system that would provide them with *AVERAGE* "network link load".

An NMS might be able to respond to such an ASA search, but might then issue an ASA
asking all nodes to report "network link load" to that NMS.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Apr 2016 10:54:06 -0400

> you have a watertight definition of 'disparate'.

Yes/no.

That could be a service from a device on the network to resolve them and
issue revised Intents.  For instance, de-corolating conflicting policies.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Apr 2016 10:56:17 -0400

I must be missing something.  You say "I don't think that ANIMA Intents 
can be turned on/off."  I can't parse that.  Two attempts:

A) Clearly, there can be an intent not to allow something.  WHether the 
intent it to turn off all admissions, or to prohibit all miliious 
traffic (if only we could), there are clearly negative intents as well 
as positive intents.

B) Equally clearly, the human beings who originate intents can change 
their minds temporarily or permanently.  Policies get changed 
(permanent), and sometimes people decide based on information outside 
the system scope taht policies need to be temporarily changed.

So I don't know what you mean when you say that intents can't be turned off.

Yours,
Joel

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Apr 2016 14:38:34 -0400

Joel M. Halpern <[email-masked]> wrote:
    > I must be missing something.  You say "I don't think that ANIMA Intents can
    > be turned on/off."  I can't parse that.  Two attempts:

    > intent it to turn off all admissions, or to prohibit all miliious traffic (if
    > only we could), there are clearly negative intents as well as positive
    > intents.

Yes, an Intent could be published to permit or deny something.
That would be an ANIMA Intent to turn off traffic, and you'd have to 'Turn
on' (publish) such an Intent.

    > B) Equally clearly, the human beings who originate intents can change their
    > minds temporarily or permanently.  Policies get changed (permanent), and
    > sometimes people decide based on information outside the system scope taht
    > policies need to be temporarily changed.

    > So I don't know what you mean when you say that intents can't be turned

I'm saying that I don't think that ANIMA Intents should be published ("turned
on") and then "withdrawn" (turned off).  I think that they should only be
published so that we don't have to worry about having old things lingering in
systems.

So this leaves us with two non-mutually exclusive possible ways to do things:

1) the CRL way -- you publish a new Intent identifying the ANIMA Intent that
   you want to anul by unique ID, and say that it's dead.  New Intent is
   subject to the same flooding/distribution as the old one.

2) the expiry way -- all Intents should expire.  If not renewed, they just
   die on their own.

PKIX uses both mechanism, but the trend it towards using short expiry times
and online renewals. (ACME is doing that).  While we do have the OCSP, I find
it silly in many ways... why even have a certificate authority if you are
going to ask everyone online.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Apr 2016 07:54:38 +1200

> something to take over so that it can turn itself off.  That's a signal.

IMHO, definitely. It sounds like a classical negotiation, where the load-management
ASA concerned discovers and negotiates with another load-management ASA to migrate
some or all of its load. And if two nodes running at 30% each found each other,
the negotiation would need a tie-break rule to decide which one took the load
and which one closed down.

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Apr 2016 16:49:31 -0400

Hmmm.

Yes, the system could work by having policies expire quickly, and be 
refreshed in a timely fashion.  However, since policy may change at any 
time, there would still need to be a way to say that some policy no 
longer applies, and a new policy has superceded it.

If we really want no delete / over-ride, we have to keep the timeouts 
very short, and spend a lot of resource reflooding identical policies 
with new expirations.  I am not seeing the benefits of such a behavior. 
  We are not dealing with a highly loosely coupled system, such as web 
certifications.

Yours,
Joel

---

From: John Strassner <[email-masked]>
Date: Tue, 5 Apr 2016 11:47:28 -0700

(Hmmm)^2

I agree with Joel. In past implementations, the intent writer is tightly
coupled to the agent (or node) that is transforming the intent into a form
that is consumable by the ANI. While the ANI is highly distributed, I do
not think that it is loosely coupled either.

regards,
John

On Mon, Apr 4, 2016 at 1:49 PM, Joel M. Halpern <[email-masked]> wrote:

> time, there would still need to be a way to say that some policy no longer
> applies, and a new policy has superceded it.
>
> If we really want no delete / over-ride, we have to keep the timeouts very
> short, and spend a lot of resource reflooding identical policies with new
> expirations.  I am not seeing the benefits of such a behavior.  We are not
> dealing with a highly loosely coupled system, such as web certifications.
>
> Yours,
> Joel
>
>> traffic (if
>>      > So I don't know what you mean when you say that intents can't be
>> turned
>>      > off.
>>

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 5 Apr 2016 19:59:27 +0000

MichaelR: What’s wrong with:

-          Intent(1):

o   freeze network enrolment (just as an example)

-          Intent(2):

o   unfreeze network enrolment (just as an example)

-          Intent(3):

o   freeze network enrolment (just as an example)

or even:

-          Intent(4):

o   (empty) – meaning, go back to default behaviour

(ignore here whether “freeze” is the right way to stop enrolment, it’s just an example)
Michael

From: Anima [mailto:[email-masked]] On Behalf Of John Strassner
Sent: 05 April 2016 15:47
To: Joel M. Halpern <[email-masked]>; John Strassner <[email-masked]>
Cc: Michael Richardson <[email-masked]>; anima <[email-masked]>
Subject: Re: [Anima] ANIMA intent discussion

(Hmmm)^2

I agree with Joel. In past implementations, the intent writer is tightly coupled to the agent (or node) that is transforming the intent into a form that is consumable by the ANI. While the ANI is highly distributed, I do not think that it is loosely coupled either.

regards,
John

On Mon, Apr 4, 2016 at 1:49 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
Hmmm.

Yes, the system could work by having policies expire quickly, and be refreshed in a timely fashion.  However, since policy may change at any time, there would still need to be a way to say that some policy no longer applies, and a new policy has superceded it.

If we really want no delete / over-ride, we have to keep the timeouts very short, and spend a lot of resource reflooding identical policies with new expirations.  I am not seeing the benefits of such a behavior.  We are not dealing with a highly loosely coupled system, such as web certifications.

Yours,
Joel

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

_______________________________________________
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: Wed, 6 Apr 2016 10:49:09 +1200

On 06/04/2016 06:40, John Strassner wrote:
> Carrying on the snipping tradition...
> 
> I don't have a strong feeling either way, but why (more out of
> curiosity)?

Oh, just because it avoids having a separate process to do the
compilation, that's all. It's certainly not a standardization issue.

>> be algorithmic. What's the value in allowing it to be sloppy?
> 
> Who says that natural language has to be sloppy?
> 
> What I mean by restricted natural language is that it has a grammar
> that matches the needs of the constituency that is using it. For me,
> intent is not specifying an algorithm, it is specify what needs to be
> done, and let the machine implement the algorithm.

Well sure, and I guess it's true that COBOL was originally touted as a
natural language, because you could write DIVIDE WAGES BY HOURS GIVING PAYRATE.
In that sense, sure.
>> Also,
> Agreed. In past work, we've done exactly that. See above comment.
> 
> Agreed
> How is it contradictory? The intent is translated to a form that the ASAs
> can handle.

Right, and that is where we aren't quite in agreement. I've been
assuming that the Intent as distributed by GRASP *is* in the form
that ASAs can handle.

Rgds
   Brian

> 
> regards,
> John
> 
> On Sun, Apr 3, 2016 at 1:14 PM, Brian E Carpenter <

---

From: John Strassner <[email-masked]>
Date: Tue, 5 Apr 2016 11:40:46 -0700

Agreed
...

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 5 Apr 2016 11:50:38 -0700

I agree as well

regards,
John

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 5 Apr 2016 20:34:12 -0700

> assuming that the Intent as distributed by GRASP *is* in the form

Perhaps we are closer than you think :-)

IFF we ignore the initial transformation (which I readily concede COULD
be done by an ASA), then I actually agree with you - the output of the
transformation SHOULD (MUST?) be in a form that ASAs can handle.

regards,
John

-- 
regards,
John

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Apr 2016 08:25:24 -0400

> o unfreeze network enrolment (just as an example)

As long as there are expiry dates so that nodes know how long to cache this
information, and how long until they should expect a new set of intents, I
don't care.
I'm also happy if Intent(2) says, "Intent(1) is cancelled"

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Apr 2016 10:40:15 -0400

I would expect that most policies will have an indefinite lifetime from 
the user perspective.  We can inssit on some limited lifetime, but I 
would like to understand why we would want to.

Yours,
Joel

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 6 Apr 2016 15:02:01 +0000

+1

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 06 April 2016 11:40
> To: Michael Richardson <[email-masked]>; Michael Behringer
> (mbehring) <[email-masked]>
> Cc: John Strassner <[email-masked]>; anima <[email-masked]>
> I would expect that most policies will have an indefinite lifetime from the
> user perspective.  We can inssit on some limited lifetime, but I would like to
> understand why we would want to.
> 
> Yours,
> Joel
> 
> > As long as there are expiry dates so that nodes know how long to cache
> > this information, and how long until they should expect a new set of
> > intents, I don't care.