Re: [Anima] Self-Managed Networks

[Reddy Pallavali <[e-mail]>]

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/
>



-- 
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/