Re: [Anima] Fwd: New Version Notification for draft-du-anima-an-intent-04.txt

[Laurent Ciavaglia <[e-mail]>]

Hi Brian,

The drawing is interesting...

Some questions/remarks come to mind:
-Could an ASA handle both objectives (A,B)?
-Could ASAs be of different implementations, or from different vendors?
-What are the possible options
     . for intra-AF-inter-node-ASAs communication? 
(developer's/operator's choice, GRASP, other options?)
     . for intra-AF-intra-node-ASAs communication? 
(developer's/operator's choice, GRASP, node OS bus/protocols, other 
options?)
-Although I think it is a possible model, why having ASA1 and ASA2 on 
node X? I mean what is the criteria that decides if an AF is 
instantiated by one or multiple ASAs on a given node?
-Are ASA1 and ASA2 managing different resources on node X? In case they 
are, what does it mean to "attach" them to node X (instead of the set of 
resources they manage)?
-Could ASAs have a hierarchy?
-A case to add is one ASA managing a remote node (the ASA is installed 
on an "installation host").
-A case to add is one ASA managing multiple nodes.
-Do we have examples of AFs that can illustrate the (variations in the) 
diagram? (secure bootstrap seems like a workable case...)
-Constraints in the deployment/instantiation should be captured at some 
point, i.e. matching between the ASA capabilities (e.g. what types of 
resources it can control,
    what types of hosts it can be installed on...), the installation 
hosts capabilities (e.g. support dynamic installation, location and 
reachability...) and the operator's needs (what deployment schemes are 
favored, functionality coverage vs. cost trade-off...).

Sections 3 and 4 of draft-peloso-anima-autonomic-function-01 provides 
explanations on some of the above questions/remarks.
Section 2.2 describes a series of variations in line (but broader / mode 
detailed) with "Brian's" drawing.

HTH, best regards, Laurent.


On 11/07/2016 18:29, Brian E Carpenter wrote:
> Is the attached drawing correct? It's supposed to be an Autonomic Function
> implemented across three Autonomic Nodes X, Y and Z containing a total of
> four ASAs managing two different technical objectives A and B.
>
> (If anyone wants to fire back a corrected version I have attached the PPT
> as well as the PDF.)
>
> Regards
>     Brian
>
> On 12/07/2016 02:45, Laurent Ciavaglia wrote:
>> Hello,
>>
>> There is some text in draft-peloso-anima-autonomic-function-01
>> (https://tools.ietf.org/html/draft-peloso-anima-autonomic-function-01) detailing what should be considered when installing,
>> instantiating and operating AF/ASA.
>> Please see sections 3+.
>>
>> Feedback on the text is most welcome as this will be presented at IETF96/Berlin.
>>
>> Best regards, Laurent.
>>
>>
>> On 11/07/2016 14:55, Joel M. Halpern wrote:
>>> I believe your description, and that of others as to what we "intend", does not line up with the definition you quote.
>>>
>>> The text says that an ASA "implements an autonomic function." That seems to say that I sould expect an autonomic function to
>>> be implemented by an ASA, thus implying a 1-1 relationship.
>>>
>>> yet, your example states an AF of "bootstrapping", but the funcitonality of the ASA being a much smaller piece.
>>>
>>> Net: No, the words do not clearly state what we intend.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/11/16 8:39 AM, Michael Behringer (mbehring) wrote:
>>> ...
>>>>>>> Also, how is the relevance for each ASA known?
>>>>>> My proposal: Intent comes in sections; those sections are
>>>>>> labelled with the
>>>>> name of the ASA / autonomic function they belong to. Also here,
>>>>> there are many ways to do this, it's a simple proposal which could
>>>>> be optimised in many ways.
>>>>>>> And is that the correct granularity of the section? Maybe the
>>>>>>> granularity should be individual objectives, or certain groups
>>>>>>> of objectives? I think this needs more discussion.
>>>>>> On this one I agree!! We should have more discussions on that.
>>>>>> Your point
>>>>> from the other mail, that we should try implementing some ASAs
>>>>> would help understand this better.
>>>>>
>>>>> Yes. There's been an assumption, I think, that one "autonomic
>>>>> function" == one ASA. We need to be clear if that is an axiom, and
>>>>> we need to think about how ASAs are named, and if those names need
>>>>> to be registered somehow.
>>>> Yes, that misunderstanding keeps popping up all the time.  I think
>>>> RFC7575 is quite clear:
>>>>
>>>> Autonomic Function: A feature or function that requires no
>>>> configuration and can derive all required information through self-
>>>> knowledge, discovery, or Intent.
>>>>
>>>> Autonomic Service Agent: An agent implemented on an autonomic node
>>>> that implements an autonomic function, either in part (in the case
>>>> of a distributed function) or whole.
>>>>
>>>> Example: There is the "autonomic function" "bootstrapping of new
>>>> nodes". It consists of 3 different ASAs: The new_device ASA, the
>>>> proxy ASA and the registrar ASA.
>>>>
>>>> How can we make that clearer? (I thought RFC7575 *is* clear).
>>> ...
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/anima
>>>

-- 

Laurent Ciavaglia

Nokia, Bell Labs

[phone]

route de Villejust - Nozay, France

linkedin.com/in/laurent.ciavaglia