Subject: Re: [Anima] Review of ANIMA GRASP

From: "Peloso, Pierre (Nokia - FR)" <[email-masked]>
Date: Fri, 1 Jul 2016 15:50:32 +0000

Hi Brian, Sheng, Michael and all,

Please see additional comments in-line,
Noting that there are two points among my following comments which are linked to discussions held at the workshop on AN we had in Athens.

Thanks for these discussions,

Pierre

> -----Message d'origine-----
> De : Anima [mailto:[email-masked]] De la part de Michael Behringer (mbehring)
> Envoyé : mercredi 29 juin 2016 17:01
> À : Brian E Carpenter; Sheng Jiang; [email-masked]; draft-ietf-anima-
> [email-masked]
> Objet : Re: [Anima] Review of ANIMA GRASP
> 
> > > Before into details, in general the current text still have room to
> > > improve
> > regarding to clearly distinguish the target, role and responsibility
> > of GRASP, ASAs and autonomic network as a whole.
> >
> > Yes, although of course some of that material intersects with the
> > Reference Model document. I think we also need some deep reviews of
> > the Reference Model to get this aspect correct.
> 
> Yes, the reference model should give the general overview, so this discussion should
> to a large extent go there.
Seems fair to me to have some more of these in the reference model.
Inside draft-peloso-anima-autonomic-function, there is text on the role of ASA and their management.
Why not building upon it ?

> 
> Having said this, we haven't seen many comments on that part of the reference model,
> and some reviews would really be helpful. This is in particular section 5, if someone
> wants to dive straight into that part.
> 
> > > Third paragraph of Section 1, “Negotiation is … between the
> > > negotiating
> > devices”.  Is it possible to negotiate between ASAs or instances in a
> > same device?
> >
> > I can answer for my prototype code: yes. I can show you this in
> > Berlin: three ASAs negotiating simultaneously in my laptop, with three
> > instances of GRASP running in fact. (Thanks to Toerless; this works
> > because he persuaded us to change to a separate TCP port for each
> > instance.)
> 
> ... and it MUST be possible. We've just had the workshop on AN in Athens, and one big
> discussion point was the coordination function. While we haven't concluded whether
> this coordination function is itself an ASA or part of the infrastructure, we do NOT
> want to make it technically impossible for a coordination function to be an ASA. This
> is a good example of two ASAs on the same device having to communicate.
At this point 2 comments:
   1 - There may definitely be two different ASAs willing to modify the same device parameter...
   2 - Michael is dealing here with the role of coordination function with regards to GRASP: During the WS discussions,  there was a sort of soft-agreement that: 
           - coordination function can be distributed,
           - coordination function instances should contain a GRASP client,
           - it was not clear yet whether coordination would be completely external to ANI (like ASA sitting on top of ANI), or would have some pieces embedded in ANI.
Could we get feed-back from the WG there (whether the hypothesis stated above are acceptable, and whether they may prevent something from working, are incompatible with something).

A related point is the following naming question:
Shall coordination function instances be categorized as ASA or shall they belong to a different category ?
Of course this different category is expected to be GRASP Clients.
I personally consider a different naming would ease the understanding, for 2 reasons:
  - ASA instances are pieces of an autonomic function, while coordination is a utility which participates in managing autonomic functions.
  - ASA instances duties are different that Coordination instances duties, e.g.
           1. An ASA Instance part of an Autonomic function is meant to self-describe itself for coordination to happen, and should then comply to requirements, while coordination function instances have different requirements.
           2. A coordination function instance may send imperative command to Autonomic Functions (i.e. ASA Instances), while an Autonomic Function is certainly not entitled such permissions over other Autonomic Functions.
During Athens WS, Michael named this category "management blobs", what would be naming that could be agreed on?
> 
> > (I think the 'infrastructure ASAs' such as bootstrap and ACP-formation
> > might have some special technical requirements, but they should be out
> > of scope
> > here.)
> 
> Why? (agree it's out of scope for GRASP, but for my understanding). To me, bootstrap
> function is just another autonomic function, consisting of a registrar ASA, a proxy
> ASA and a new_node ASA. Why would that be different to any other ASA? (Apart from the
> fact that we may declare the proxy ASA and new_device ASA for example mandatory to
> implement.
> 
> > > First paragraph of Section 2, is it multiple ASAs might manage a
> > > same
> > technical objective? If yes, it should also be mentioned.
> >
> > OK (of course this raises the coordination issue, but that is out of
> > scope here).
> 
> Agree they should be able to, and agree needs to be mentioned. The coordination is
> one way to cope with that issue.
> 
> > > D3 in Section 2.1, “When an ASA starts up, it must require no
> > > information
> > about any peers in order to discover them.” It is worth to clarify the
> > another
> > side: if there are existing information, ASA may use it.
> >
> > Are you sure? I think any discovery results obtained before a crash
> > should be flushed, for example. Maybe the point is that we require no
> > *configured* information in an autonomic network.
> 
> Configuration (or NETCONF, etc) can override an autonomic behaviour. Where it exists,
> it MUST be respected. RFC7575 explains that. So Sheng is right that we need to think
> about this. But.... If there is configuration that conflicts, it's not optional, so I
> have an issue with the "may"...
> 
> I suggest the current text allows all of the above, and I would just leave it as is.
> 
> > >
> > > D4 in Section 2.1, “so discovery needs to be repeated to find
> > > counterparts
> > for each objective.” The word “repeat” may imply the linear time order.
> > Maybe replaced by “separated”, “splitted”?
> 
> To me "repeated" is clearer.
> 
> > > N5 in Section 2.2, “the protocol … must be capable of running in any
> > > device
> > that would otherwise need human intervention.” This looks like too
> > strong for me with the word “must” and “any”, unless we are talking
> > about full autonomic network, which exclude any human intervention,
> > although it may be our ultimate goal. The same with N6, the word
> > “must” and “any” may be too strong.
> >
> > I think that's probably true; we need to make this text more logical.
> > Actually there is an interaction here with the reference model, which
> > should discuss constrained vs unconstrained nodes.
> 
> In the reference model we declare constrained devices out of scope for now. I thought
> we had decided on that?
> 
> However, this is a design goal, not a protocol requirement, as I read it. So the
> "must" is lowercase, and it's meant for the protocol designers rather than
> implementors? In any case, it's not an uppercase "MUST", so I think uncritical.
> 
> > > N7 in Section 2.2, if a dependency chain become too long, it may
> > > slow down
> > the decision too much. If so, the performance of the total AN may also
> > be damaged. So, I guess a mechanism to avoid the long-chain of
> > dependencies is also needed. However, whether it is matter for ASAs or
> > GRASP, I am not sure.
> >
> > I don't think the protocol itself can help with this.
> 
> Why not? We could define a "max dependency count"?  A bit like maximum recursion
> depth.  (Not arguing for, just trying to understand your statement, Brian.)
> 
> > > “Objective” in Section 3.1, third paragraph, “That node is generally
> > expected to contain an ASA which may itself manage other nodes.” In my
> > understanding, an ASA could only manage local nodes although it may
> > influence other nodes by negotiating with the peer ASAs on them.
> 
> No, I don't think so. For a long time we'll have networks where not all nodes are
> autonomic. I think it is likely that we have ASAs that also "manage" other, non-
> autonomic nodes. Now, you could argue, that is out of scope for GRASP and that's
> probably true. But we shouldn't forget this model.
From a deployment point of view, there are plenty of different ways of linking an ASA instance with a device instance, the ASA instance can be inside the device OS, but can be hosted on a remote host and interact with the device through OpenFlow, SNMP, CLI ... The constraints may come from the ASA code or from the device capacities, hence I definitely agree with Michael on that. 

> > > “Organizing of synchronization or negotiation content” bullet point
> > > in
> > Section 3.2. I believe this point should be rewritten as a
> > recommendation for ASA. GRASP is a generic platform. Consequently, it
> > is independent from content organizing.
> >
> > Correct. From the work I've done on the reference model and the GRASP
> > API, I think we will need a document all about ASAs and how they are
> > organized.
> 
> Agree. This should probably be another section in the reference model.  Any volunteer
> for some text?
Some short text for the reference model is on my work table.
A full document about ASA and how there management already exists, the work is not complete, but there is already a bunch of material there: draft-peloso-anima-autonomic-function-01, so maybe not worth starting from scratch a new doc why not building upon it?

Additionally, this document and the presentations of it made both in Yokohama and Buenos Aeres explicit the needs and the fields required for ASA self-description (e.g. on startup) (see section 6).
During Athens WS, there was a soft consensus on using the GRASP discovery message to disclose the ASAs self-description. A still pending question is whether, we should embed the full self-description in a single objective, or should we split each section in a different objectives as the objective modifiers should be different depending whether the part of the self description discloses metrics or parameters.
Could there be some additional feed-back? Should I clarify the question first?
> > >
> > > “Self-aware network device” bullet point in Section 3.2, last
> > > sentence “A
> > device has no pre-configuration for the particular network in which it
> > is installed.” I am not sure the purpose of this sentence although it
> > looks like a requirement. If so, it is too strong. I think a “may” should be added.
> >
> > I wonder whether this whole paragraph even belongs in this document.
> > It seems like an extract from the reference model.
> 
> Agreed.
> 
> > >
> > > Section 3.3, more description may be added regarding to use GRASP to
> > signal between two Autonomic networks/domains.
> >
> > Agreed, but at the moment I'm not sure what to say.
> 
> I suggest, for this version of ANIMA, we restrict ourselves to single-domain only.
> Multi-domain will raise many other questions. The current reference model has "cross
> domain" (6.5) labelled as out of scope. So, I think, nothing needed in GRASP right
> now.
> 
> > > In section 3.3, “Discovery Procedures”, “the device MAY respond to
> > > the
> > link-local multicast”. Why “MAY”? As an important behavior for
> > successful discovery, I think it should be “SHOULD”.
> >
> > Good question. Actually this is a very old MAY - it is present in
> > section 5.2.2 of draft-carpenter-anima-gdn-protocol-00, in slightly different
> wording.
> > I have always assumed that it was because an ASA might wish to hide
> > for some time (for example, if it has no free resources to offer,
> > there is no point in being discovered). Maybe we could say "SHOULD
> > respond unless temporarily unavailable", or something like that?
> 
> Hmmmm... I think if an ASA can't process a request, it should send back an according
> error message rather than be silent. I can't argue precisely why, but my feeling is
> that "hiding" may cause all sorts of subsequent issues. I would have written "MUST"
> respond even. At least in the single-domain case. Why would it want to hide?!?
> 
> > > In multiple interfaces scenarios, “it MUST relay the query by
> > > re-issuing a
> > Discovery message as a link-local multicast on its other interfaces.”
> > I do NOT think “MUST” is right here. It means an objective that does
> > not support by any devices or only support by a few devices would
> > certainly cause a signal storm. I suggest to soft this to “SHOULD” and make it
> changeable by intent.
> >
> > Why would it cause a storm? There are various mechanisms to prevent
> > that. I don't think there is any discovery mechanism possible without
> > relaying discovery. So I think all multi-interface nodes MUST relay by default.
> >
> > You are correct, there might be objectives which are only useful if
> > on-link, so being able to restrict discovery to on-link would be valuable in that
> case.
> 
> Agree up to here.
> 
> > That does seem like Intent.
> 
> Not sure I agree here. Why Intent? What would such an Intent look like? Do you have
> an example in mind?
> 
> > > Section 3.3.4.1, I am not sure whether the Rapid mode is only used
> > > on-link
> > or not, in another word. The discovery message with a negotiation
> > objective option should or should not be relayed. Either way, it
> > should be clarified further.
> >
> > I have no real opinion about that. To be honest I am not convinced by
> > the argument for Rapid mode. It seems like complexity for quite a
> > small gain, since discovery results will normally be cached. Let's discuss...
> 
> My feeling as well.
> 
> > > The same paragraph, “synchronization objectives that are flooded
> > > SHOULD
> > NOT contain unencrypted sensitive information.” There is not
> > definition of “sensitive information”. Therefore, the meaning of this
> > sentence is questionably.
> 
> Really, this is a recommendation to users of GRASP, not for the protocol. I wonder
> whether this belongs here...
> 
> > > The second paragraph of section 3.3.5.2, “This rapid synchronization
> > function SHOULD be configured off by default.” Why off by default?
> > More explanation are needed for this design choice.
> >
> > That's because all nodes in the network need to agree whether Rapid
> > Mode is in use or not, I think. In any case the failure modes could
> > get quite complicated (if one peer responds with just a discovery
> > response, and another one several hops away responds with a
> > negotiation response, but the initiator has already started negotiating with the
> nearest neighbor).
> 
> Feeling - keep it simple, let's not do rapid at all.  But, need to think more...
> 
> I'm taking the points regarding the reference model out, and add it to that work
> stream.
> 
> Thanks Brian and Sheng - good discussion!
> Michael
> 
> > Thanks again,
> >    Brian
> >
> >
> >
> > _______________________________________________
> > Anima mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Jul 2016 19:50:19 +1200

Pierre,

Let me try to answer your points below. I have deleted a lot of text to make
the message short enough to read. Also, please note that my main concern for
now is to ensure that GRASP does everything we need; many aspects that are
specific to ASA design do not affect this.
On 02/07/2016 03:50, Peloso, Pierre (Nokia - FR) wrote:
...
> Why not building upon it ?

Certainly, but we need a common view and the reference model must not become
too long and complex, or nobody will read it. So I still suspect we need a
separate document on ASA design.

...
>    1 - There may definitely be two different ASAs willing to modify the same device parameter...

Yes, but a device parameter is not the same thing as a GRASP objective. I have
great difficulty with the thought of two ASAs *in the same device* that are both
actively negotiating the same GRASP objective.

If two ASAs modify the same underlying device parameter, that must of course
be coordinated at device level. It seems like a quite traditional problem
needing a lock and/or a token.

If two ASAs in *different* devices negotiate the same GRASP objective that is
of course absolutely normal and might not create any coordination issue,
depending on the semantics of the objective.

>            - coordination function can be distributed,

Of course (and that's the reason I recently became interested in
distributed consensus algorithms).

>            - coordination function instances should contain a GRASP client,

What's a GRASP client? We have initiators and responders in GRASP. You
can think of the initiator as a client and the responder as a server,
but any ASA can be both initiator and responder.

>            - it was not clear yet whether coordination would be completely external to ANI (like ASA sitting on top of ANI), or would have some pieces embedded in ANI.

My opinion: the semantics of coordination are very dependent on the individual
use case. So I am not sure what generic support we could provide, beyond
basic GRASP. If you can specify the sort of interaction required between two
coordinators *in the general case* we can then see whether it needs any
new GRASP message types.

> Of course this different category is expected to be GRASP Clients.

Again, "GRASP client" isn't defined. I'll assume "GRASP user".

> During Athens WS, Michael named this category "management blobs", what would be naming that could be agreed on?

I can have no opinion about this until you can answer my question above
about message types. If we can map the coordination interactions onto
the existing GRASP interactions (discover, negotiate, synchronize, flood)
then I would suggest to minimize the terminology by calling them CASAs
(Coordinating ASAs). If we need new GRASP messages, we can discuss.
When considering this, remember that a GRASP Objective can have any
data structure and any semantics that you want in its 'value' field.

I am thinking about six ASAs each supporting its own objective:
"leg", "tail", "trunk", "ear", "belly", "tusk"*. But they each also synchronize
an objective called "coordinate_elephant" which is supported by a CASA.
We define the semantics of "coordinate_elephant" so that each ASA obeys
the instructions of the CASA.

* https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

...

> From a deployment point of view, there are plenty of different ways of linking an ASA instance with a device instance, the ASA instance can be inside the device OS, but can be hosted on a remote ho…

We all agree. The ASA uses the GRASP API for its autonomic interactions, but
how it actually manages its target device(s) is completely open.

> Some short text for the reference model is on my work table.

As I already said, I made some updates to the reference model on GitHub,
but we are not done yet.

> Additionally, this document and the presentations of it made both in Yokohama and Buenos Aeres explicit the needs and the fields required for ASA self-description (e.g. on startup) (see section 6).

I haven't looked at that for a while, but again I can see how we can map that
to a GRASP objective, for example if the ASA is called "abc" then its manifest
could be a synchronization objective called "abc.manifest" or whatever convention
we choose.

> During Athens WS, there was a soft consensus on using the GRASP discovery message to disclose the ASAs self-description. 

That would be discover() followed by synchronize(). If you agree with the
"abc.manifest" convention we can write the code in Python tomorrow.

> A still pending question is whether, we should embed the full self-description in a single objective, or should we split each
section in a different objectives as the objective modifiers should be different depending whether the part of the self
description discloses metrics or parameters.

Again, that is only a matter of how we choose to define it. I don't see either
approach creating a technical diffculty. I think we'd need to play with some
real examples to discover the best approach. (And before we go too far, this
seems like an area where we definitely need an information model.)

> Could there be some additional feed-back? Should I clarify the question first?

A concrete example would be very helpful.

I think I caught all your points, Pierre, please tell me if not.

Regards
    Brian

---

From: "Peloso, Pierre (Nokia - FR)" <[email-masked]>
Date: Wed, 13 Jul 2016 12:16:40 +0000

Hi Brian and all,

Though coming late, I take some of the points discussed there are worth being pushed further.
By the way, I renamed the discussion thread in ASA management were the main concerns addressed in these snipped points.
A way to make clear that these points go beyond GRASP design, but concern ANIMA WG as a whole.

Thanks for your answers....

Pierre

> De : Brian E Carpenter [mailto:[email-masked]]
> Envoyé : samedi 2 juillet 2016 09:50
> À : Peloso, Pierre (Nokia - FR); Michael Behringer (mbehring); Sheng Jiang;
> [email-masked]; [email-masked]
> Let me try to answer your points below. I have deleted a lot of text to make the
> message short enough to read. Also, please note that my main concern for now is to
> ensure that GRASP does everything we need; many aspects that are specific to ASA
> design do not affect this.
> >> Yes, the reference model should give the general overview, so this
> >> discussion should to a large extent go there.
> Certainly, but we need a common view and the reference model must not become too long
> and complex, or nobody will read it. So I still suspect we need a separate document
> on ASA design.

I think we reached this point:
 - having some light additions to the reference model to keep it readable,
 - having a separate document on ASA design: just need augmenting/modifying the draft we proposed from before IETF 94th.
 
> ...
> >> ... and it MUST be possible. We've just had the workshop on AN in
> >> Athens, and one big discussion point was the coordination function.
> >> While we haven't concluded whether this coordination function is
> >> itself an ASA or part of the infrastructure, we do NOT want to make
> >> it technically impossible for a coordination function to be an ASA. This is a good
> example of two ASAs on the same device having to communicate.
> Yes, but a device parameter is not the same thing as a GRASP objective. I have great
> difficulty with the thought of two ASAs *in the same device* that are both actively
> negotiating the same GRASP objective.

If a device parameter modified by an ASA is not one of the ASA objectives, then what is an objective ? Can you provide example of what you have in mind ?

> 
> If two ASAs modify the same underlying device parameter, that must of course be
> coordinated at device level. It seems like a quite traditional problem needing a lock
> and/or a token.
> 
> If two ASAs in *different* devices negotiate the same GRASP objective that is of
> course absolutely normal and might not create any coordination issue, depending on
> the semantics of the objective.
> 
> >    2 - Michael is dealing here with the role of coordination function with regards
> to GRASP: During the WS discussions,  there was a sort of soft-agreement that:
> Of course (and that's the reason I recently became interested in distributed
> consensus algorithms).
> 
> What's a GRASP client? We have initiators and responders in GRASP. You can think of
> the initiator as a client and the responder as a server, but any ASA can be both
> initiator and responder.
In my understanding there is in each Autonomic Node a GRASP Engine. From that I derive there is a sort of API the ASA should have to push a message to GRASP and receives the coming ones. So basically, a client is the API for both the initiator and the responder.

The point above mentioning that coordination function should contain a GRASP client, was just to mean that coordination function should be capable of initiating and responding to GRASP signaling (hence bind to a GRASP engine). 
Which may not be clear here is the implicit:
Coordination function is not an ASA (at least in my opinion).
Why not? Because an ASA is an agent of an autonomic function. Coordination function is not an autonomic function.
It is a meta function in charge of insuring coordination between autonomic functions.
Then why not generalize and state that nevertheless let it be an ASA?
Because all we've been stressing since the beginning of ANIMA is that ASA have to comply to a life-cycle* and duties (like self-describing). Though coordination function may have a life-cycle and duties, I am sure those are different than the ones.
That is why I place the generalization 1 level higher: ASA and Coordination function contain a GRASP client. 
 
* Btw, I saw you just draw some deployment of ASA, and this deployment is just one of the point we've pointed as being part of the ASA life-cycle.

> >            - it was not clear yet whether coordination would be completely external
> to ANI (like ASA sitting on top of ANI), or would have some pieces embedded in ANI.
> 
> My opinion: the semantics of coordination are very dependent on the individual use
> case. So I am not sure what generic support we could provide, beyond basic GRASP. If
> you can specify the sort of interaction required between two coordinators *in the
> general case* we can then see whether it needs any new GRASP message types.

If you're not convinced that a generic support to coordinate AF is feasible, I then encourage you to attend the presentations that Laurent will be giving during ANIMA meeting in Berlin. It specifically addresses this point.
There are some requirements to signaling in this presentation (same as the one already presented at Yokohama and Buneos Aeres): mainly having command type of messages.

> 
> > Could we get feed-back from the WG there (whether the hypothesis stated above are
> acceptable, and whether they may prevent something from working, are incompatible
> with something).
> >
> >   - ASA instances are pieces of an autonomic function, while coordination is a
> utility which participates in managing autonomic functions.
> >            1. An ASA Instance part of an Autonomic function is meant to self-
> describe itself for coordination to happen, and should then comply to requirements,
> while coordination function instances have different requirements.
> >            2. A coordination function instance may send imperative command to
> Autonomic Functions (i.e. ASA Instances), while an Autonomic Function is certainly
> not entitled such permissions over other Autonomic Functions.
> I can have no opinion about this until you can answer my question above about message
> types. If we can map the coordination interactions onto the existing GRASP
> interactions (discover, negotiate, synchronize, flood) then I would suggest to
> minimize the terminology by calling them CASAs (Coordinating ASAs). If we need new
> GRASP messages, we can discuss.

Referring to one of the previous point of the email, coordination function not being an autonomic function but one of the management function of autonomic function, I do not like naming them ASA nor something ASA 

> When considering this, remember that a GRASP Objective can have any data structure
> and any semantics that you want in its 'value' field.
> 
> "leg", "tail", "trunk", "ear", "belly", "tusk"*. But they each also synchronize an
> objective called "coordinate_elephant" which is supported by a CASA.
> We define the semantics of "coordinate_elephant" so that each ASA obeys the
> instructions of the CASA.
> 
> >> No, I don't think so. For a long time we'll have networks where not
> >> all nodes are autonomic. I think it is likely that we have ASAs that
> >> also "manage" other, non- autonomic nodes. Now, you could argue, that
> >> is out of scope for GRASP and that's probably true. But we shouldn't forget this
> model.
> 
> > From a deployment point of view, there are plenty of different ways of linking an
> ASA instance with a device instance, the ASA instance can be inside the device OS,
> but can be hosted on a remote host and interact with the device through OpenFlow,
> SNMP, CLI ... The constraints may come from the ASA code or from the device
> capacities, hence I definitely agree with Michael on that.
> 
> We all agree. The ASA uses the GRASP API for its autonomic interactions, but how it
> actually manages its target device(s) is completely open.
> 
> >
> >>> recommendation for ASA. GRASP is a generic platform. Consequently,
> >>> it is independent from content organizing.
> >>>
> >>> Correct. From the work I've done on the reference model and the
> >>> GRASP API, I think we will need a document all about ASAs and how
> >>> they are organized.
> >>
> >> Agree. This should probably be another section in the reference
> >> model.  Any volunteer for some text?
> As I already said, I made some updates to the reference model on GitHub, but we are
> not done yet.
> 
> > A full document about ASA and how there management already exists, the work is not
> complete, but there is already a bunch of material there: draft-peloso-anima-
> autonomic-function-01, so maybe not worth starting from scratch a new doc why not
> building upon it?
> >
> > Additionally, this document and the presentations of it made both in Yokohama and
> Buenos Aeres explicit the needs and the fields required for ASA self-description
> (e.g. on startup) (see section 6).
> 
> I haven't looked at that for a while, but again I can see how we can map that to a
> GRASP objective, for example if the ASA is called "abc" then its manifest could be a
> synchronization objective called "abc.manifest" or whatever convention we choose.
I am convinced there is a stronger tie between objectives and manifest fields see below
[Recopied]
A still pending question is whether, we should embed the full
self-description in a single objective, or should we split each
section in a different objectives as the objective modifiers should be different
depending whether the part of the self description discloses metrics or parameters.
[end of copy]
> "abc.manifest" convention we can write the code in Python tomorrow.
[Where the copy was]
> approach creating a technical diffculty. I think we'd need to play with some real
> examples to discover the best approach. (And before we go too far, this seems like an
> area where we definitely need an information model.)

In order to gain in mutual understanding on this specific aspect, and before working on examples (which is fine), I encourage you to have a deeper look in what is the Instance manifest and the life-cycle we propose (see draft-peloso-anima-autonomic-function-01 section 6 and 7 and Laurent's presentation). These items have not been built out of pure theory, but out of confronting ourselves to many examples and generalizing the exemplified solutions.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jul 2016 04:17:16 +1200

Hi,

Comments in line.

> If a device parameter modified by an ASA is not one of the ASA objectives, then what is an objective ? Can you provide example of what you have in mind ?

Perhaps I was not clear. There are two parts to this:

1) An objective is (quoting the GRASP spec)
"  o  Technical Objective (usually abbreviated as Objective): A
      technical objective is a configurable parameter or set of
      parameters of some kind, which occurs in three contexts:
      Discovery, Negotiation and Synchronization.  In the protocol, an
      objective is represented by an identifier and if relevant a value.
      Normally, a given objective will not occur in negotiation and
      synchronization contexts simultaneously."

By definition, an Objective is managed by an ASA, using the synchronization
or negotiation method when it needs to communicate with a peer ASA.
So what would be the meaning of having two ASAs *in the same node*
managing the same Objective?

2) A traditional device parameter might normally be mapped 1:1 into
an Objective, but do we want to make that a rule? Do we want to exclude
cases where an autonomic objective is more abstract than that, so that
the same device parameter is affected by more than one Objective? For
example consider a QoS Objective and a Congestion Objective. They might
both want to change some underlying queueing parameters in a router.
There's a coordination problem within the node, to be solved by the ASAs.

> In my understanding there is in each Autonomic Node a GRASP Engine. From that I derive there is a sort of API the ASA should have to push a message to GRASP and receives the coming ones. So basical…

There is an API and there is a draft:
https://tools.ietf.org/html/draft-liu-anima-grasp-api

> That is why I place the generalization 1 level higher: ASA and Coordination function contain a GRASP client. 

That's just terminology; I don't object, but as far as GRASP is concerned
a coordination function looks exactly like an ASA.

> * Btw, I saw you just draw some deployment of ASA, and this deployment is just one of the point we've pointed as being part of the ASA life-cycle.

Yes, certainly.

> There are some requirements to signaling in this presentation (same as the one already presented at Yokohama and Buneos Aeres): mainly having command type of messages.

A command is an imperative request, so I think can probably be mapped directly
onto a GRASP Request Negotiation message. It's probably a negotiation with a loop
count = 1 since no negotiation is possible, but that depends on the exact semantics
you need. If that doesn't work out, we could add a new GRASP message type,
but since it would presumably need a command/response cycle, I think the
existing request/end messages should work well.

> Referring to one of the previous point of the email, coordination function not being an autonomic function but one of the management function of autonomic function, I do not like naming them ASA no…

Well, arguing about names is not very interesting, but I would suggest that
this will turn out to be a recursive matter ("Quis custodiet ipsos custodes").

> depending whether the part of the self description discloses metrics or parameters.

I think we have full liberty to decide this later. In fact that's one of the
reasons that the naming rule for Objectives, and the format of the value field
of an Objective, are both extremely flexible at the level of the GRASP protocol:
we can defer the question until we know the answer.

> In order to gain in mutual understanding on this specific aspect, and before working on examples (which is fine), I encourage you to have a deeper look in what is the Instance manifest and the life…

I'm sure of that. As I have said, my concern for now, given the Anima WG charter,
is to ensure that GRASP has all the flexibility needed.

Regards,
    Brian