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: ... >> 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 ?
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. ... >> ... 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... 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. > 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, 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. > 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. Again, "GRASP client" isn't defined. I'll assume "GRASP user". > 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 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 ... >> 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. > >>>> “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. 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. > 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
