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 > -----Message d'origine----- > De : Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Envoyé : samedi 2 juillet 2016 09:50 > À : Peloso, Pierre (Nokia - FR); Michael Behringer (mbehring); Sheng Jiang; > anima@ietf.org; draft-ietf-anima-grasp....@ietf.org > Objet : Re: [Anima] Review of ANIMA GRASP > > 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. 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. > > 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 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: > > - 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. 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). > > > > 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. 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. > > 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. 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] > > 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. > [Where the copy was] > > 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.) 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. > > 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 Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
