Hi Laurent,
On 12/07/2016 09:21, Laurent Ciavaglia wrote:
> Hi Brian,
>
> The drawing is interesting...
It was intended to provoke questions and I see that it succeeded ;-)
>
> Some questions/remarks come to mind:
> -Could an ASA handle both objectives (A,B)?
Yes, I see no reasons why not.
> -Could ASAs be of different implementations, or from different vendors?
I think so, if the Objectives have open specifications.
> -What are the possible options
> . for intra-AF-inter-node-ASAs communication? (developer's/operator's
> choice, GRASP, other options?)
I hope we would RECOMMEND to use GRASP, but is clearly not the only option.
> . for intra-AF-intra-node-ASAs communication? (developer's/operator's
> choice, GRASP, node OS bus/protocols, other options?)
Again GRASP would work, and if the ASAs are independently developed, it would
seem to be the natural choice.
> -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?
I tend to agree that a single ASA would be more natural, but IMHO we should
allow
flexibility.
> -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)?
I think the answer to that is hidden in the definition of the Objectives. If I
take the
prefix management use case, there is a local pool of IPv6 prefixes which
definitely
belong to the node and can be allocated to users by the node. But if the node
runs
short of prefixes, the ASA will have to negotiate with its peer in another node
to increase its pool. So two fundamentally identical ASAs in two nodes, but each
with its own resource pool.
> -Could ASAs have a hierarchy?
I think the answer to that is in the semantics of the AF, not a question of
principle.
> -A case to add is one ASA managing a remote node (the ASA is installed on an
> "installation host").
Right, but then the remote node is *not* an autonomic node; it's a slave.
> -A case to add is one ASA managing multiple nodes.
...multiple slaves.
> -Do we have examples of AFs that can illustrate the (variations in the)
> diagram? (secure bootstrap seems like a workable case...)
I think bootstrap is one, and for some aspects, prefix management.
> -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.
Yes. It was only an illustration that I started for my own understanding.
Thanks
Brian
>
> 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
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
