Re: [Anima] Self-Managed Networks

[Brian E Carpenter <[e-mail]>]

Reddy,

We decided to limit negotiation in GRASP to the bilateral case, since
multilateral negotiation and consensus seemed to us to be a research problem
still. Please look at the protocol design, your comments will be most
welcome.

https://tools.ietf.org/html/draft-ietf-anima-grasp-01

Regards
   Brian Carpenter

On 15/10/2015 23:03, Reddy Pallavali wrote:
> Many thanks for your kind reply,
> 
> Recently i joined in IETF - ANIMA group, so i do not know about IETF -
> Yokohama; I will look into that.
> 
> Since, the networks are fully distributed, asynchronous, heterogeneous and
> dynamic, as i understood.
> 
> Consensus relay convergence time, robustness, and fault-tolerance against
> failures (e.g. termination, validation, integrity and agreement).
> 
> For instance, in ACP, the autonomic functions have to fulfill their
> individual goals and also must cooperate their behaviour towards global
> goal of the entire network. Meaning that autonomic functions such as,
> energy efficiency, load balancing, scalability, availability conflicts with
> each other based on users mobility. The energy efficiency function
> conflicts with availability and mobility; also with load balancing; since
> adaptively micro, macro, and pico cells have to adjust their
> functionalities in the mean time have to serve all its objects under their
> signals. So, there is a need of coordinated function (consensus state),
> that maximizes individual and global goals by reducing conflicts between
> them.
> 
> We have Swarm and Artificial Intelligence techniques to reach consensus
> state in a dynamic situation, since they will learn the past and anticipate
> the future by prediction.
> 
> I hope it works better for bottom-up approach, as you mentioned this groups
> focus is also bottom-up.
> 
> 
> 
> 
> 
> On Thu, Oct 15, 2015 at 10:27 AM, Michael Behringer (mbehring) <
> [e-mail]> wrote:
> 
>> Hi Reddy,
>>
>>
>>
>> Thanks for chiming in!  Nice to get some fresh view on our work.
>>
>>
>>
>> I’m not sure consensus is “instead” of synchronisation, I think those are
>> two different things. Synchronisation just keeps the state on some devices
>> in sync, consensus is to me a specific form of negotiation.
>>
>>
>>
>> In this working group we’re very focused on a bottom-up approach, i.e.,
>> first understand small building blocks and how we can use them, later plug
>> them together in a wider framework. The approach is use-case driven, in
>> other words, for everything we do we’d like a clear example on how this
>> would be used in a running network.
>>
>>
>>
>> Can you give us an example on how consensus could be used in today’s
>> networks? The simpler the example, the better. We are looking to understand
>> how a network function would use consensus in a concrete situation.
>>
>>
>>
>> Once we understand the use case, we can see how and where to bring it in.
>>
>>
>>
>> Will you be at the IETF in Yokohama? If so, we should meet and discuss.
>>
>>
>>
>> Michael
>>
>>
>>
>>
>>
>> *From:* Reddy Pallavali [mailto:[e-mail]]
>> *Sent:* 15 October 2015 11:08
>> *To:* Michael Behringer (mbehring) <[e-mail]>
>> *Cc:* Toy, Mehmet <[e-mail]>; Brian E Carpenter <
>> [e-mail]>; [e-mail]
>>
>> *Subject:* Re: [Anima] Self-Managed Networks
>>
>>
>>
>> Hi,
>>
>> I am new to this mailing list, and junior researcher from COPELABS, Lisbon.
>>
>> I have one suggestion when it comes to ACP toolkit - instead of using
>> synchronization, can use consensus?
>>
>> Since, synchronization is more towards centralized "Coordinator initiate
>> to agree on something (towards centralized), and others have to adjust
>> their state".
>>
>> When it comes to consensus "individual neighbors come to global
>> intelligence by simple communication rules (fully distributed), and
>> majority opinion is valid".
>>
>> My PhD thesis area is on Consensus so, i can contribute this section.
>>
>>
>>
>> On Thu, Oct 15, 2015 at 9:57 AM, Michael Behringer (mbehring) <
>> [e-mail]> wrote:
>>
>> 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
>>
>>
>>
>>
>> --
>>
>> Thank you very much for your time and consideration.
>>
>>
>>
>> Yours sincerely,
>>
>> P Radha Krishna Reddy, M.Sc, M.Tech,
>>
>> Junior Researcher/Ph.D Student,
>>
>> COPE LABS, Universidade Lusofona, Lisboa - Portugal.
>>
>> Author of: Security Issues of Cloud Computing over General & IT Sector
>> Mobile: [phone]
>> www.prkreddy.webs.com
>> http://pt.linkedin.com/in/reddypallavali/
>>
> 
> 
>