Re: [Anima] Self-Managed Networks

[Laurent Ciavaglia <[e-mail]>]

Dear Michael, all,

I am not sure to fully understand what you mean by "The ACP is a control 
plane for *device* management."
In the abstract of the ACP draft, it is written that the ACP is the 
control plane for autonomic functions. Statement which I agree with.
If I try to interpret (please correct if I am wrong) "ACP for device" as 
stated above, it means that the ACP runs between devices (dubbed 
autonomic nodes) hosting autonomic functions (e.g. one or more ASAs).

To stress what Toerless mentioned in a previous message:
"1) easily, ideally autonomous downloadable agent/application infra.

Eg: I don't see any way that either vendors or operators could 
realistically build this framework if these components are tied into the 
classical router OS software delivery model where it takes months to 
validate a software update and more months to deploy it. If this can be 
downloaded, as separate apps then its so much easier to incrementally 
build/deploy it on a totally different deployment process."

I think it is important to support such flexibility for the deployment, 
and therefore:
     -to stress that the ACP runs between devices (dubbed autonomic 
nodes) hosting autonomic functions (e.g. one or more ASAs).
     -to allow ASAs to be deployed (and execute) on hosts different from 
the hosts/resources they are supposed to manage. of course, this model 
does not preclude ASAs to be directly hosted/integrated with the device.

HTH, best regards, Laurent.


On 16/10/2015 10:44, Michael Behringer (mbehring) wrote:
> Adding to Brian's response (which I agree with), and up-levelling the discussion a bit:
>
> Mehmet, I think there is a simple misunderstanding here. The ACP is a control plane for *device* management. A device can hold many contexts, as in NFV, but they are all managed in a single way. My feeling is we have a disconnect somewhere on this level, right?
>
> Michael
>
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: 16 October 2015 08:02
>> To: Toy, Mehmet <[e-mail]>; Michael Behringer
>> (mbehring) <[e-mail]>; [e-mail]
>> Subject: Re: Self-Managed Networks
>>
>> On 16/10/2015 16:36, Toy, Mehmet wrote:
>>> Michael,
>>>
>>> Before I pick each of your statement and express my thoughts, I would like
>> to ask more questions by picking your  statement " There is *one* ACP,
>> there are *many* autonomic functions on top.".   Assume we  start building
>> on this to see how far we can go, whether this holds for all cases or not, I
>> don't know.
>>> If we have two or more ACPs, what could go wrong?
>> Why would a domain need more than one ACP? (Certainly there might be a
>> transient situation after a temporary network partition where two ACPs
>> would "meet" and then need to merge; indeed the ACP needs to be self-
>> repairing in such cases.)
>>
>>> What is it that you are trying to do here? What is the purpose behind this
>> model?
>>
>> Provide a secure L3 between all autonomic nodes that is strictly independent
>> of the operational data plane. The purpose is to allow autonomic operations
>> to work regardless of anything else.
>>
>>> Furthermore, I suggest you to think about ETSI NFV model,
>>> "infrastructure" and "VNF" division of networks.  What is wrong in
>>> using that kind of model here which is a reasonable breakdown,
>> We aren't reinventing NFV, as far as I can tell. If there is a recent technical
>> overview of NFV, that would be interesting to see. But I don't believe that
>> Autonomic Service Agents are at all the same thing as VNFs.
>>
>>> instead of sticking with ACP  that is becoming very difficult to define?
>> Huh? draft-ietf-anima-autonomic-control-plane is still work in progress but it
>> seems very clearly defined to me. In sketching out how GRASP will be
>> implemented, I haven't hit any conceptual problems with the ACP, and its
>> main API will just be socket calls. The only complication I found is that it will
>> need to support the Advanced Socket API because of some special
>> requirements for link-local multicasts. Otherwise, it's just another virtual
>> (loopback) network interface.
>>
>> Regards
>>     Brian
>>
>>> Thanks
>>> Mehmet
>>>
>>> -----Original Message-----
>>> From: Michael Behringer (mbehring) [mailto:[e-mail]]
>>> Sent: Thursday, October 15, 2015 4:57 AM
>>> To: Toy, Mehmet; Brian E Carpenter; [e-mail]
>>> Subject: RE: Self-Managed Networks
>>>
>>> Toy, thanks for raising those questions. Obviously, we're not doing a good
>> job yet in describing what the ACP is, and that needs to be fixed. And
>> obviously, we all need the same view to progress further. So this is a very
>> important discussion, and I really welcome it.
>>> Before formalising better text, let me see whether we get agreement on
>> the fundamental idea.
>>> In my head, there are two layers: The ACP, and on top of that the
>> Autonomic Functions:
>>> * The ACP is the "tool kit". It comprises various "mechanics", such as
>> negotiation, synchronisation, discovery of various sorts, messaging, etc.
>> Those are all based on a common addressing and naming concept.
>>> * Autonomic Functions use that tool kit to do something clever. In other
>> words, the true autonomic "intelligence" sits on that level.
>>> There is *one* ACP, there are *many* autonomic functions on top.
>>>
>>> One way to decide to which layer something belongs is to ask: "is this (1) a
>> generic functionality which many functions require, or is this (2) one specific
>> function?". If the answer is (1), it belongs into the ACP, if (2) it belongs into
>> an autonomic function.
>>> So, in this light, my understanding (!) of fault management is that
>>> this is an autonomic function, and would use common blocks of the
>>> underlying ACP. Conversely, it would not offer services to other
>>> autonomic functions on top. This is my way of thinking when I write
>>> "this is an autonomic function".  And I'm not 100% certain I
>>> understand what you're suggesting, so please chime in here! (And I
>>> haven't read your draft fully yet, sorry)
>>>
>>> Look at
>>> http://tools.ietf.org/id/draft-jiang-anima-prefix-management-01.txt
>>> This draft describes "intelligence". In that case, a way to automatically
>> manage address space. Sections 2.2 and 2.3 explain which parameters and
>> information exchanges such a function would require. Sheng wrote this
>> document to explain how an autonomic function would use a common ACP.
>>> Probably we should take some off-line time in Yokohama to discuss this in a
>> small team?
>>> Michael
>>>
>>>
>>>> -----Original Message-----
>>>> From: Anima [mailto:[e-mail]] On Behalf Of Toy,
>> Mehmet
>>>> Sent: 15 October 2015 04:26
>>>> To: Brian E Carpenter <[e-mail]>; Michael
>>>> Behringer
>>>> (mbehring) <[e-mail]>; [e-mail]
>>>> Subject: Re: [Anima] Self-Managed Networks
>>>>
>>>> Michael and Brian,
>>>> Per Toerless suggestion, I am including ANIMA group into the discussion.
>>>>
>>>> I re-read the "A Reference Model for Autonomic Networking" document
>>>> and I am not clear about the definitions.
>>>>
>>>> a)  In the "A Reference Model for Autonomic Networking", ACP is
>>>> defined as "The Autonomic Control Plane is the summary of all
>>>> interactions of the Autonomic Networking Infrastructure with other
>> nodes and services.".
>>>> b) Brian, you write as " The ACP is common infrastructure for all
>>>> autonomic functions.(The ACP needs to be self-repairing, of course.)
>>>> The signaling protocol is also common infrastructure."
>>>>
>>>> Question: What is ACP? a or b or combination?
>>>>
>>>> c) Section 4 in the reference model document , "The Autonomic
>>>> Networking Infrastructure provides a layer of common  functionality
>>>> across an Autonomic Network.  It comprises "must implement" functions
>>>> and services, as well as extensions."
>>>> Question: What are the "must implement" functionalities?  How do you
>>>> define "must implement" functionalities?
>>>>
>>>> Thanks
>>>> Mehmet
>>>> -----Original Message-----
>>>> From: Brian E Carpenter [mailto:[e-mail]]
>>>> Sent: Wednesday, October 14, 2015 5:25 PM
>>>> To: Michael Behringer (mbehring); Toy, Mehmet
>>>> Cc: '[e-mail]'; '[e-mail]'; 'anima-
>>>> [e-mail]'
>>>> Subject: Re: Self-Managed Networks
>>>>
>>>> I agree with Michael. The ACP is common infrastructure for all
>>>> autonomic functions.
>>>> (The ACP needs to be self-repairing, of course.) The signaling
>>>> protocol is also common infrastructure.
>>>>
>>>>     Brian
>>>> On 15/10/2015 05:43, Michael Behringer (mbehring) wrote:
>>>>> I would argue they are part of an autonomic function, which runs on
>>>>> top of
>>>> the ACP.
>>>>> There are really two different pieces here, and this is I think the
>>>>> confusion
>>>> here:
>>>>> -          The ACP is self-managing. It needs to do self-healing, and
>>>> automatically adapt to new situations. But to me, this isn’t fault
>>>> management or performance management as an operator understands
>> it.
>>>>> -          The network has FM and PM function. Those could be (and should
>>>> be, imo) autonomic functions. Those run on top of the ACP.
>>>>> Bottom line: I’d like to keep the ACP itself as minimalistic and
>>>>> simple as we
>>>> possibly can. Functions like FM / PM belong into an autonomic function,
>> IMO.
>>>>> What do you think?
>>>>> Michael
>>>>> From: Toy, Mehmet [mailto:[e-mail]]
>>>>> Sent: 14 October 2015 18:30
>>>>> To: Michael Behringer (mbehring) <[e-mail]>
>>>>> Cc: '[e-mail]' <[e-mail]>;
>>>> '[e-mail]'
>>>>> <[e-mail]>; '[e-mail]'
>>>>> <[e-mail]>; '[e-mail]'
>>>>> <[e-mail]>
>>>>> Subject: RE: Self-Managed Networks
>>>>>
>>>>> Michael,
>>>>> Instead of answering the question as Yes or No, let me give examples
>>>>> to
>>>> see what makes sense.
>>>>> Let’s say in a data path, a router port is failed.  The router
>>>>> generates an AIS
>>>> (Alarm Indication Signal) and the receiving  end generates RDI
>>>> (remote Defect Indicator).  Both messages are generated by the
>> hardware, not by a
>>>> software or ACP.   As a result of this failure,  there would be packet loss.
>> The
>>>> hardware counts these losses, an ACP does not.
>>>>> For the FM and PM functions above, can we say they are part of an ACP?
>>>>> Thanks
>>>>> Mehmet
>>>>> From: Michael Behringer (mbehring) [mailto:[e-mail]]
>>>>> Sent: Wednesday, October 14, 2015 11:34 AM
>>>>> To: Toy, Mehmet
>>>>> Cc: '[e-mail]'; '[e-mail]'; 'anima-
>>>> [e-mail]'; '[e-mail]'
>>>>> Subject: RE: Self-Managed Networks
>>>>>
>>>>> Hi Toy,
>>>>> To understand better: To me, fault management *uses* the functions
>>>>> of
>>>> the AN infrastructure. It uses the ACP to communicate, maybe GRASP
>>>> for some signalling, might be influenced by Intent, etc. Right?  So
>>>> to me, this is a logical component of an autonomic network that sits
>>>> on top of the AN infrastructure.
>>>>> Do we agree?
>>>>> Michael
>>>>>
>>>>> From: Toy, Mehmet [mailto:[e-mail]]
>>>>> Sent: 13 October 2015 23:46
>>>>> To: Michael Behringer (mbehring)
>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>> Cc: '[e-mail]'
>>>>> <[e-mail]<mailto:[e-mail]>>;
>>>>> '[e-mail]'
>>>>> <[e-mail]<mailto:[e-mail]>>;
>>>>> '[e-mail]'
>>>>> <[e-mail]<mailto:[e-mail]>>;
>>>>> '[e-mail]'
>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>> Subject: RE: Self-Managed Networks
>>>>>
>>>>> Michael,
>>>>> Appreciate the reply.
>>>>> FM is part of data plane and control plane (i.e. ANI in your diagram).
>>>>> My plan is to add a short paragraph for now either to section 2 to
>>>>> expand
>>>> the description  of ANI or to section 4 to add a sub-section for
>>>> Fault Management.
>>>>> It is also possible too add a Performance Management section to
>>>>> describe
>>>> what types of measurements and where and how are used.  Although
>>>> there is a control feedback related measurement in the document, I
>>>> don’t know if it is adequate.
>>>>> Regards,
>>>>> Mehmet
>>>>> From: Michael Behringer (mbehring) [mailto:[e-mail]]
>>>>> Sent: Tuesday, October 13, 2015 12:27 PM
>>>>> To: Toy, Mehmet
>>>>> Cc: '[e-mail]'; '[e-mail]'; 'anima-
>>>> [e-mail]'; '[e-mail]'
>>>>> Subject: RE: Self-Managed Networks
>>>>>
>>>>> Sorry for the delay, it’s very busy at the moment here.
>>>>> To me, fault management refers generally to faults on the data
>>>>> plane, ie for
>>>> user traffic. I see that happening at some point as an autonomic
>>>> function (or several, for different aspects). Would you agree? Or do
>>>> you see that as a function inside the AN infrastructure?
>>>>> So my feeling is that function would reside on top of the
>>>>> infrastructure that
>>>> we’re currently defining. So, please have a look whether your
>>>> thoughts can be described as an autonomic function. I think they probably
>> can.
>>>>> Then I suggest we do the same that we’re planning to do with the NMS
>>>> section, the model discussion, etc: Have a short paragraph describe
>>>> the overall topic briefly, and point to an external doc for now,
>>>> i.e., probably your draft.
>>>>> If you agree, can you suggest where in the reference model you would
>>>>> add
>>>> a short paragraph about fault management, and I suppose we’d point to
>>>> your draft, right?
>>>>> Michael
>>>>>
>>>>>
>>>>> From: Toy, Mehmet [mailto:[e-mail]]
>>>>> Sent: 13 October 2015 03:53
>>>>> To: Michael Behringer (mbehring)
>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>> Cc: '[e-mail]'
>>>>> <[e-mail]<mailto:[e-mail]>>;
>>>>> '[e-mail]'
>>>>> <[e-mail]<mailto:[e-mail]>>;
>>>>> '[e-mail]'
>>>>> <[e-mail]<mailto:[e-mail]>>;
>>>>> '[e-mail]'
>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>> Subject: RE: Self-Managed Networks
>>>>>
>>>>> Mike,
>>>>> I am waiting for your response.
>>>>> Thanks
>>>>> Mehmet
>>>>>
>>>>> From: Toy, Mehmet
>>>>> Sent: Friday, October 09, 2015 8:13 PM
>>>>> To: '[e-mail]'
>>>>> Cc: '[e-mail]'; '[e-mail]'; 'anima-
>>>> [e-mail]'; '[e-mail]'
>>>>> Subject: RE: Self-Managed Networks
>>>>>
>>>>> Mike,
>>>>> I can send you some text to include in section 2 and 4 of  “A
>>>>> Reference
>>>> Model for Autonomic Networking,   draft-behringer-anima-reference-
>>>> model-03”,  per Sheng’s suggestion.
>>>>> Should I just do that?
>>>>> Thanks
>>>>> Mehmet
>>>>>
>>>>>
>>>>> From: Toy, Mehmet
>>>>> Sent: Thursday, October 08, 2015 7:53 AM
>>>>> To: '[e-mail]'; '[e-mail]';
>>>> '[e-mail]'; '[e-mail]'
>>>>> Cc: '[e-mail]'
>>>>> Subject: Re: Self-Managed Networks
>>>>>
>>>>> Sheng,
>>>>> Appreciate a quick response.
>>>>> I will work on your suggestion.
>>>>> Mehmet
>>>>>
>>>>>
>>>>> From: Sheng Jiang [mailto:[e-mail]]
>>>>> Sent: Thursday, October 08, 2015 06:08 AM Eastern Standard Time
>>>>> To: Toy, Mehmet;
>>>>> [e-mail]<mailto:[e-mail]>
>>>>> <[e-mail]<mailto:[e-mail]>>;
>>>>> [e-mail]<mailto:[e-mail]>
>>>>> <[e-mail]<mailto:[e-mail]>>;
>>>>> [e-mail]<mailto:[e-mail]>
>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>> Cc: Romascanu, Dan (Dan)
>>>>> ([e-mail]<mailto:[e-mail]>)
>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>> Subject: RE: Self-Managed Networks
>>>>>
>>>>> Hi, Toy,
>>>>> First of all, for my understanding, your work is in the scope of the
>>>>> WG
>>>> charter. However, we do not have work item or milestone for it. It
>>>> looks like an upper-layer autonomic service agent for me. In our
>>>> plan, autonomic service agents are mainly for the next period, which
>>>> is after re-charter (this is the same with your suggestion of
>>>> modifying the charter, but it cannot happen until we deliver the
>>>> current milestones). For now, the best may be try to add some
>>>> description, maybe mainly abstracted functionality, into the reference
>> model document.
>>>>> Best regards,
>>>>> Sheng
>>>>>
>>>>> From: Toy, Mehmet [mailto:[e-mail]]
>>>>> Sent: Tuesday, October 06, 2015 1:14 AM
>>>>> To: [e-mail]<mailto:[e-mail]>;
>>>>> [e-mail]<mailto:[e-mail]>;
>>>>> [e-mail]<mailto:[e-mail]>
>>>>> Cc: Romascanu, Dan (Dan)
>>>>> ([e-mail]<mailto:[e-mail]>)
>>>>> Subject: Self-Managed Networks
>>>>>
>>>>> Dear All:
>>>>> I couldn’t attend the Prague meeting, but luckily Dan was able to
>>>>> present
>>>> my slides on “Self-Managed Networks with Fault Management
>> Hierarchy”.
>>>> The feedback was to position the work in the ANIMA WG scope and
>>>> framework.
>>>>> ANIMA charter in “M. Behringer, et. al., A Reference Model for
>>>>> Autonomic
>>>> Networking
>>>>> draft-behringer-anima-reference-model-03” refers to “self-healing”.
>>>> RFC7575,  “M. Behringer, et al.,   Autonomic Networking: Definitions and
>>>> Design Goals”,  refers to “self-management”. However, both documents
>>>> do not  articulate fault management aspect of the self-management.
>>>> It is possible to interpret the fault management aspect of autonomic
>>>> networks as part of “self-healing” and therefore as part of the ANIMA
>>>> charter.  In that case, the “Architectural Framework for Self-Managed
>>>> Networks with Fault Management Hierarchy,
>>>> draft-mtoy-anima-self-faultmang-framework-
>>>> 00.txt” contribution can target to fill that gap.  The control plane
>>>> aspect of self-healing is addressed by “M. Behringer, et al., An
>>>> Autonomic Control Plane,
>>>> draft-behringer-anima-autonomic-control-plane-03”.  I believe these
>>>> contributions are complementary to each other. I can try to address that
>> in the contribution.
>>>>> Please let me know if you agree with me. If not, I suggest to modify
>>>>> the
>>>> charter since without covering fault management aspect of the
>>>> autonomic networks, the concept of autonomic network will be
>> incomplete.
>>>>> Regards,
>>>>> Mehmet
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: [phone]

email: [e-mail] 
<mailto:[e-mail]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France