Re: [Anima] Self-Managed Networks

[Reddy Pallavali <[e-mail]>]

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/