Re: [Anima] Self-Managed Networks

[Reddy Pallavali <[e-mail]>]

Hello Toy,

As of my PhD thesis area is Consensus problem, i went through
synchronization as well. The time synchronization is a centralized
approach, that forces all objects to change their system timings to reach
their goal; while consensus is a fully distributed approach, all objects
have to agree on certain state: where the importance of convergence takes
place. Here, we can use SI or AI approaches to improve the convergence.

On Fri, Oct 16, 2015 at 5:04 AM, Toy, Mehmet <[e-mail]>
wrote:

> Reddy,
>
> I believe “synchronization” and “consensus” words are applicable to
> different situations. You gave a good AI example for consensus.
>
> On the other hand  if we are talking timing relationship between two ends
> of  a  circuit emulation, we have to use “synchronization”.
>
>
>
> In autonomous networks, we might be able to use both words depending on
> the situation.
>
> Thanks
>
> Mehmet
>
>
>
> *From:* Reddy Pallavali [mailto:[e-mail]]
> *Sent:* Thursday, October 15, 2015 6:03 AM
> *To:* Michael Behringer (mbehring)
> *Cc:* Toy, Mehmet; Brian E Carpenter; [e-mail]
>
> *Subject:* Re: [Anima] Self-Managed Networks
>
>
>
> 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/
>



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