Subject: Re: [Anima] [ANIMA] Self-Managed Networks

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 1 Nov 2015 06:59:18 -0500

No, BGP was not a typo.  I wish it were.

For clarity, I was not objecting to ACP.  I think we need to be clearer 
about the relationship between Bootstrap, GRASP, and ACP.  But that is a 
relatively minor issue.

My point was that including a good distribution design in GRASP gives us 
a good toolkit.  In its absence, people do things like BGP-LS, using BGP 
as an information distribution technique.

Yours,
Joel

On 10/30/15 10:12 AM, Michael Richardson wrote:
>
> Joel M. Halpern <[email-masked]> wrote:
>      > While i think we should be cautious about attepting to boil the ocean,
>      > I certainly prefer GRASP plus good distribution design as an
>      > information distribution mechanism rather than BGP.
>
> Is "BGP" a typo? Did you mean ACP?
>
> If so, are you suggesting that we shouldn't have an IP-based ACP, but
> should rather run things on top of GRASP?
>
> If GRASP is going to do all these things, such as prioritzation of events,
> then wouldn't we be better off to start some place like MMTQ or that other
> protocol that starts with D, which I can't recall, sitting here on the
> airplane.  (But I'll reply once I look it up)
>

---

From: John Strassner <[email-masked]>
Date: Sun, 1 Nov 2015 04:44:04 -0800

Hi Toerless,

> Before anima, every distributed function we designed in the IETF
> used its own reinvented communication paradigm. The only common
> mechanism was use of IP packets, but not even that was the lowest
> common denominator (IS-IS anybody).

At the risk of rocking the boat, I'm less interested in using autonomics
for "plumbing" issues, such as healing broken routes, as I am in
correcting user- and business-oriented functions and services.

We are engineers. We have a natural affinity for playing with bright,
shiny knobs that provide new technologies with which to design.
However, this rarely directly pays the bills. The business person
typically does not care what technologies and features are used, as
long as his or her service works. If it exceeds an SLA, then its
scotch time as well.

But there is no "gold service enable" CLI command that I've ever seen.
This is why many of the autonomic projects have tried to reach above
forwarding and routing and try and translate business concepts to
drive network services and resources that the business needs.

We've failed, rather spectacularly, so far. After 500+ conferences on
Future Internet, Next Generation Networking, yada-yada-yada, we
still do not have a replacement for SNMP.

NFV was stillborn - it has the management capabilities of a walnut.
SDN is a bit more like an apple (tastier and prettier, but still no
management).

I know the IETF loves to work bottom-up. But perhaps we need to
have a top-down approach as well to fix this. Otherwise, the network
that never fails but still doesn't provide business value is just another
cool journal paper.

regards,
John

On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert <[email-masked]> wrote:

> The way i see it:
>
> Before anima, every distributed function we designed in the IETF
> used its own reinvented communication paradigm. The only common
> mechanism was use of IP packets, but not even that was the lowest common
> denominator (IS-IS anybody).
>
> So the question really is what are the pragmatic common communication
> mechanisms we can come up with to make future distributed functions
> easier to implement, deploy and operate. With focus on "deploy" because
> thats what we want to be autonomic. And start with what our own "anima"
> distributed functions realized via "agents" need.
>
> We know p2p with common presentation layer and set of session transaction
> types, and some limited discovery, eg: mp2mp transactions.
>
> The discussion now is what's logically next. Once we have an idea, then
> we can figure whether it makes sense to call/put-into GRASP and/or if/how
> to deal with it in ANIMA.
>
>
> On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner wrote:
> > Hi all,
> >
> > Sorry, I'm a bit confused.
> >
> > To me, this thread is starting to discuss generic messaging system
> > capabilities (e.g., at the minimum, a message broker, at the other
> > end of the scale, a full-blown ESB). I didn't think that the purpose
> > of the ACP included such capabilities.
> >
> > In other words, there is a huge difference between GRASP
> > generating a notification and GRASP functioning as a full
> > messaging system, complete with message transformation and
> > routing, queuing, etc.
> >
> > I was assuming the former, not the latter.
> >
> > Please correct me if I am wrong.
> >
> > (Note that FOCALE used an ESB for inter-agent communication.)
> >
> > regards,
> > John
> >
> >
> >
> > On Mon, Oct 19, 2015 at 12:35 PM, Brian E Carpenter <
> > [email-masked]> wrote:
> >
> > > On 20/10/2015 08:04, Joel M. Halpern wrote:
> > > > There are at least two different factors to consider in terms of what
> > > events are communicated to the operator.
> > > >
> > > > First, for initial deployment of autonomic technologies, operators
> will
> > > want ways to observe all the events so they can gain
> > > > confidence in the technology.  (We received these requests with
> existing
> > > self-organizing network technologies.)
> > > >
> > > > Secondly, different operators have different degrees of information
> > > harvesting and display relative to the state of the
> > > > network.  Even if the network is taking care of itself perfectly,
> some
> > > operators will want visibility to any internal state
> > > > change.  These operators currently monitor their routing protocol
> state
> > > for similar effects.
> > >
> > > What I get from this is a requirement that all ASAs are capable of
> > > notifying events,
> > > but whether and how those events are reported live to operators is a
> > > separate issue.
> > >
> > > (However, I have never forgotten that at Three Mile Island, the system
> was
> > > so busy
> > > reporting minor alarms that it took hours before the underlying alarm
> > > message
> > > saying what was really wrong got printed. TMI, indeed.)
> > >
> > >    Brian
> > >
> > > >
> > > > Yours,
> > > > Joel
> > > >
> > > > On 10/19/15 2:58 PM, Reddy Pallavali wrote:
> > > >> Michael,
> > > >>
> > > >> Yes, for every small issue there is no need to contact operator
> except,
> > > >> if it is a complex one.
> > > >> Even for self-healing we can use Swarm Intelligence or Artificial
> > > >> Intelligence techniques, but for learning may take some time.
> However,
> > > >> these are scalable techniques.
> > > >> Here, also there is a need of consensus, if the system is fully
> > > >> distributed and asynchronous need to know which object is crashed,
> how
> > > >> to schedule the loads and coverage issues as well.
> > > >>
> > > >> On Mon, Oct 19, 2015 at 6:39 PM, Michael Richardson
> > > >> <[email-masked] <mailto:[email-masked]>> wrote:
> > > >>
> > > >>
> > > >>     John Strassner <[email-masked] <mailto:[email-masked]>>
> > > wrote:
> > > >>          > When an autonomic system self-heals, why would the
> operator
> > > >>     need to
> > > >>          > know? This is comparable to routing doing its job and
> > > >>     changing the
> > > >>          > path. There is no reason that the operator has to be
> alerted
> > > >>     on every
> > > >>          > change in the system - there are already WAY TOO MANY of
> > > >>     these for the
> > > >>          > operator to handle.
> > > >>
> > > >>     Yes, but just the same, the healing activity needs to be an
> audited
> > > >>     event.
> > > >>     The ACP should be involved in capturing these events.
> > > >>
> > > >>     Sometimes things don't heal perfectly; often moving traffic from
> > > >>     one system to another causes a load spike, and while things
> > > continue to
> > > >>     function, the performance is different.
> > > >>
> > > >>     --
> > > >>     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
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Thank you very much for your time and consideration.
> > > >>
> > > >>
> > > >> Yours sincerely,
> > > >>
> > > >> P Radha Krishna Reddy, M.Sc, M.Tech,
> > > >>
> > > >> Junior Researcher/Ph.D Student,
> > > >>
> > > >> COPE LABS, Universidade Lusofona, Lisboa - Portugal.
> > > >>
> > > >> Author of: Security Issues of Cloud Computing over General & IT
> Sector
> > > >> Mobile: +351923095671
> > > >> www.prkreddy.webs.com
> > > >> http://pt.linkedin.com/in/reddypallavali/
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> Anima mailing list
> > > >> [email-masked]
> > > >> https://www.ietf.org/mailman/listinfo/anima
> > > >>
> > > >
> > > > _______________________________________________
> > > > Anima mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/anima
> > > >
> > >
> > > _______________________________________________
> > > Anima mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/anima
> > >
> >
> >
> >
> > --
> > regards,
> > John
>
> > _______________________________________________
> > Anima mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/anima
>
>
> --
> ---
> Toerless Eckert, [email-masked]
>

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Sun, 1 Nov 2015 21:15:12 +0000

John, in my opinion, if we get to the point of a solid autonomic infrastructure with the right base services, such as discovery, messaging, built on a self-managing ACP, developpers will have all the tools to write the functions that you want.

The AN infrastructure is the new IP: like IP enabled folks to write networking applications really easily, the ANI allows to write self-management functions really easily.

If we get ANI right, we enable a whole new eco-system of network programming.

Michael

From: Anima [mailto:[email-masked]] On Behalf Of John Strassner
Sent: 01 November 2015 21:44
To: Toerless Eckert (eckert) <[email-masked]>; John Strassner <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]; Anima WG <[email-masked]>
Subject: Re: [Anima] [ANIMA] Self-Managed Networks

Hi Toerless,

regards,
John

On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:
The way i see it:

On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner wrote:
> [email-masked]<mailto:[email-masked]>> wrote:
>
> > > First, for initial deployment of autonomic technologies, operators will
> > > confidence in the technology.  (We received these requests with existing
> > > network.  Even if the network is taking care of itself perfectly, some
> > > change.  These operators currently monitor their routing protocol state
> > for similar effects.
> >
> > (However, I have never forgotten that at Three Mile Island, the system was
> > so busy
> > >> Yes, for every small issue there is no need to contact operator except,
> > >> if it is a complex one.
> > >> Intelligence techniques, but for learning may take some time. However,
> > >> distributed and asynchronous need to know which object is crashed, how
> > >> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > >>
> > >>
> > >>     John Strassner <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> > wrote:
> > >>          > When an autonomic system self-heals, why would the operator
> > >>     need to
> > >>          > path. There is no reason that the operator has to be alerted
> > >>     on every
> > >>     Yes, but just the same, the healing activity needs to be an audited
> > >>     event.
> > >>     Michael Richardson <[email-masked]<mailto:[email-masked]>
> > >>     <mailto:[email-masked]<mailto:[email-masked]>>>, Sandelman Software Works
> > >>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > >> Author of: Security Issues of Cloud Computing over General & IT Sector
> > >> Mobile: +351923095671<tel:%2B351923095671>
> > >> www.prkreddy.webs.com<http://www.prkreddy.webs.com>
> > >> [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

--
---
Toerless Eckert, [email-masked]<mailto:[email-masked]>

--
regards,
John

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 1 Nov 2015 18:55:39 -0500

If I understand you, I agree that a strong ACP layer is valuable for the 
work we want to do.

But if we do not provide some (significant) interoperable value on top 
of that, I don't see folks implementing it.

Yours,
Joel

On 11/1/15 4:15 PM, Michael Behringer (mbehring) wrote:
> John, in my opinion, if we get to the point of a solid autonomic
> infrastructure with the right base services, such as discovery,
> messaging, built on a self-managing ACP, developpers will have all the
> tools to write the functions that you want.
>
> The AN infrastructure is the new IP: like IP enabled folks to write
> networking applications really easily, the ANI allows to write
> self-management functions really easily.
>
> *From:*Anima [mailto:[email-masked]] *On Behalf Of *John Strassner
> *Sent:* 01 November 2015 21:44
> *To:* Toerless Eckert (eckert) <[email-masked]>; John Strassner
> <[email-masked]>
> *Cc:* Michael Richardson <[email-masked]>; Joel M. Halpern
> <[email-masked]>; [email-masked]; Anima WG
> <[email-masked]>
> *Subject:* Re: [Anima] [ANIMA] Self-Managed Networks
>
> Hi Toerless,
>
>     >[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > > >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     > > >>
>     > > >>
>     > > >>     John Strassner <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > > wrote:
>     > > >>     Michael Richardson <[email-masked] <mailto:[email-masked]>
>     > > >>     <mailto:[email-masked] <mailto:[email-masked]>>>,
>     Sandelman Software Works
>     > > >>[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > > >> Mobile:+351923095671 <tel:%2B351923095671>
>     > > >>www.prkreddy.webs.com <http://www.prkreddy.webs.com>
>     Toerless Eckert, [email-masked] <mailto:[email-masked]>
>
>
>
>
> --
>
> regards,
>
> John
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 2 Nov 2015 00:28:54 +0000

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 02 November 2015 08:56
> To: Michael Behringer (mbehring) <[email-masked]>; John Strassner
> <[email-masked]>; Toerless Eckert (eckert) <[email-masked]>
> Cc: Michael Richardson <[email-masked]>;
> [email-masked]; Anima WG <[email-masked]>
> If I understand you, I agree that a strong ACP layer is valuable for the work
> we want to do.
> 
> But if we do not provide some (significant) interoperable value on top of
> that, I don't see folks implementing it.

Completely agree. 

Michael

---

From: John Strassner <[email-masked]>
Date: Sun, 1 Nov 2015 16:41:12 -0800

Hi Michael and Joel,

I completely agree that we need a solid autonomic infrastructure.
Without a solid foundation, we don't have anything to build upon.

My point is that AFTER we have such a foundation, we need to
turn our focus northwards (towards the app developers and
customers), instead of staying down in the weeds.

So, as Joel opined, once we have that foundation, let's (for once)
look at how to enable the business to use these functions. For
example, in FOCALE, we used the concept of capabilities and
requirements to self-organize NEs in different ANIs to
"communities" that could support similar autonomic functions.
This provided several benefits, both at the infrastructure as well
as at higher layers.

regards,
John

-- 
regards,
John

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Nov 2015 09:56:24 +0900

>> Before anima, every distributed function we designed in the IETF used
    >> its own reinvented communication paradigm. The only common mechanism
    >> was use of IP packets, but not even that was the lowest  common

    > At the risk of rocking the boat, I'm less interested in using
    > autonomics for "plumbing" issues, such as healing broken routes, as I
    > am in correcting user- and business-oriented functions and services.

    > long as his or her service works. If it exceeds an SLA, then its scotch
    > time as well.

okay, so I hear your point, and I generally tend to agree.
But, I want to argue for the business value of the plumbing.

I've built a few small ISPs, and worked with entities like root-name server
deployments.  In each case it was very very difficult to do the justification
for the needed out-of-band access (telco's called it "craft terminal") that
is needed during initial deployment and disaster recovery.

Serial console servers are ridiculously expensive for what they do, and when
you need only one or two ports in a shared cabinet, but you have 40 to 70 of
these spread around the world... (as anycase root server operators have),
it's a real financial pain.

The ACP as plumbing of last resort really deals with this problem.

The fact that it can also be substrate for something new is good.

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

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 2 Nov 2015 01:56:24 +0100

Dear all,

I also agree that the infrastructure is an essential building block to 
enable autonomic networking.
To assess the "quality" of such an infrastructure, we would need to 
analyze how well this infrastructure covers the needs and specificities 
of autonomic functions.

Jumping on one point mentioned by John on capabilities and requirements: 
in draft-peloso-anima-autonomic-function-00, we use similar 
capabilities/requirements approach to see how to provide value to the 
operator when deploying autonomic functions. This is a first version, 
and we welcome your feedback/collaboration to progress on the topic.

Best regards, Laurent.

On 02/11/2015 01:41, John Strassner wrote:
> On Sun, Nov 1, 2015 at 3:55 PM, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     If I understand you, I agree that a strong ACP layer is valuable
>     for the work we want to do.
>
>     But if we do not provide some (significant) interoperable value on
>     top of that, I don't see folks implementing it.
>
>     Yours,
>     Joel
>
>         *From:*Anima [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *John Strassner
>         *To:* Toerless Eckert (eckert) <[email-masked]
>         <mailto:[email-masked]>>; John Strassner
>         <[email-masked] <mailto:[email-masked]>>
>         *Cc:* Michael Richardson <[email-masked]
>         <mailto:[email-masked]>>; Joel M. Halpern
>         <[email-masked] <mailto:[email-masked]>>;
>         [email-masked]
>         <mailto:[email-masked]>; Anima WG
>         <[email-masked] <mailto:[email-masked]>>
>         autonomics
>         On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             The way i see it:
>
>             we can figure whether it makes sense to call/put-into
>         GRASP and/or
>             if/how
>             >[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>             >
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>             <mailto:[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>             > > >>
>             > > >>
>             > > >>     John Strassner <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>             > > wrote:
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>             > > >>     <mailto:[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>>,
>             Sandelman Software Works
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>         <tel:%2B351923095671>
>         <http://www.prkreddy.webs.com>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>
>
>
>         --
>
>         regards,
>
>         John
>
>
>
>
> -- 
> regards,
> John
>
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: John Strassner <[email-masked]>
Date: Sun, 1 Nov 2015 17:18:56 -0800

Hi Michael,

agreed. In my last note, my example of building "communities" of NEs that
shared the ability to provide autonomic functions to other (authenticated
and authorized) NEs, as well as similar "communities" of NEs that requested
the use of such capabilities, is (I hope!) one simple example of the
business value of the plumbing. More specifically, this enabled the
different autonomic networks to self-organize according to changes in
context.

Building that capability was in reality a compromise between the bottom-up
capabilities of the autonomic network elements and the top-down needs of
what was currently important, and how those needs affected the services
currently provided.

regards,
John

On Sun, Nov 1, 2015 at 4:56 PM, Michael Richardson <[email-masked]>
wrote:

> used
> scotch

-- 
regards,
John

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 2 Nov 2015 02:21:01 +0100

Joel, all,

I fully agree on the need for "good distribution design in GRASP" (or 
other mechanism).
Access to and use of information play a vital role in autonomic 
networks, thus it is key to identify the different needs and then to 
conceive the right mechanisms.
The issue I see for the moment is that there are different set of 
requirements (wrt. information exchange), so the question is whether a 
single mechanism (currently GRASP) is suitable to cover the requirements 
or if more than one mechanism is a better option.

Just to illustrate the above, some of the "information" to need to be 
exchanged/accessed are (not exclusive): intent/policy, 
manifest/mandate/meta-data, sensed/monitored data/measurements, learned 
information/beliefs, alarms/notifications, operations 
reporting/feedback/call for governance...

Entities involved, frequencies and volumes, topologies/peers involved 
are quite different and poses specific requirements/constraints...

Separating the concerns / decomposing into smaller problems/areas is 
okay, however when need a comprehensive view/framework otherwise we 
expose to (major) gaps and inconsistencies...

What would be a good way forward?

Best regards, Laurent.

On 01/11/2015 12:59, Joel M. Halpern wrote:
> For clarity, I was not objecting to ACP.  I think we need to be 
> clearer about the relationship between Bootstrap, GRASP, and ACP. But 
> that is a relatively minor issue.
>
> My point was that including a good distribution design in GRASP gives 
> us a good toolkit.  In its absence, people do things like BGP-LS, 
> using BGP as an information distribution technique.
>
> Yours,
> Joel
>

-- 

*Laurent Ciavaglia*

Secure Cloud Networking

phone: +33 160 402 636

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Nov 2015 10:25:22 +0900

> No, BGP was not a typo.  I wish it were.

okay.

    > about the relationship between Bootstrap, GRASP, and ACP.  But that is
    > a relatively minor issue.

    > us a good toolkit.  In its absence, people do things like BGP-LS, using
    > BGP as an information distribution technique.

Ah, okay. I understand, and very much agree.
Being able to reuse GRASP is important, but we should be clear what kinds
of things it is good for.

Homenet wound up with HNCP rather than overloading a routing protocol (OSPF).

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Mon, 2 Nov 2015 02:13:30 +0000

Hi all,

I am also convinced we need to be clear on the roles and duties allotted to GRASP with regards to the ones allotted to ACP and Bootstrap.

This is building a big part of the ANI and certainly not all. As Mikael mentioned earlier ANI is the toolbox allowing for the easy dev of autonomic distributed functions.
But the ANI must have on top of that the ability to control these functions otherwise those may well mess the whole network at the expense of the operator. Hence there is little chance this one would go to an ANIMA solution if we do not give minimal guarantees that ANI can control these AF.
I'm convinced this implies that these autonomic functions must have duties back with regards to the ANI, as we've attempted depicting in the draft we've just been submitted, these autonomic functions must comply to: 
 1. advertize what they do (ok with John and Laurent),
 2. to be deployable at will/under command (as john mentioned),
  
Which brings back to the roles and duties allotted to the different ANI protocols, which ones should take in charge these exchange. And which entities of the ANI should be the one offering some control on the autonomic functions?
I'm sure the week will provide opportunities to discuss these matters (possibly even round a block of paper/white board that would be great).

Regards,

Pierre

> -----Message d'origine-----
> De : Anima [mailto:[email-masked]] De la part de Michael Richardson
> Envoyé : lundi 2 novembre 2015 10:25
> À : Joel M. Halpern
> Cc : Anima WG
> Objet : Re: [Anima] [ANIMA] Self-Managed Networks
> 
> 
> Being able to reuse GRASP is important, but we should be clear what kinds of
> things it is good for.
> 
> Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6
> IoT consulting =-
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2015 08:16:50 +1300

> I am also convinced we need to be clear on the roles and duties allotted to GRASP with regards to the ones allotted to ACP and Bootstrap.

The discussion on the GRASP open issues yesterday was very helpful, I think.
GRASP shouldn't be taking decisions that can only be taken by the ASA, because
the ASA "knows" the semantics of a particular use case. GRASP is a carrier
that supports certain styles of interactions between ASAs.

(This doesn't exclude that GRASP can take default decisions if the ASA
designer fails to make a choice. A simple example is that GRASP has a
default loop count for a negotiation, but of course an ASA can change it.)

When we discover a style of interaction between ASAs that GRASP doesn't support,
we will have two choices:

1) extend GRASP
2) just use the ACP directly

>  2. to be deployable at will/under command (as john mentioned),

Sure. The features mentioned in draft-peloso-anima-autonomic-function are important.

> I'm sure the week will provide opportunities to discuss these matters (possibly even round a block of paper/white board that would be great).

A question I have (because of the "imperative" commands) is whether we should
add a generic message feature to GRASP. It would be a carrier for any kind of
direct message between two GRASP-using entities. The advantage compared to raw
usage of the ACP would be that a message could refer to a specific objective,
so that all the GRASP discovery and cache mechanisms would apply.

Regards
   Brian