Re: [Anima] Self-Managed Networks

[Laurent Ciavaglia <[e-mail]>]

Dear Reddy,

The issue you raise is inline with the coordination functionality that 
has been introduced at Dallas.
You may take a look at: 
https://datatracker.ietf.org/doc/draft-ciavaglia-anima-coordination/ (an 
update is under progress)
The draft tries to define what should (must?) be designed so that the 
autonomic entities can (co-)operate harmoniously, can arbitrate 
conflicts/interactions...
Consensus-based approaches are surely in scope, although we have chosen 
to leave the actual algorithms/methods outside of the initial document.

Best regards, Laurent.


On 15/10/2015 12: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] <mailto:[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]
>     <mailto:[e-mail]>]
>     *Sent:* 15 October 2015 11:08
>     *To:* Michael Behringer (mbehring) <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Toy, Mehmet <[e-mail]
>     <mailto:[e-mail]>>; Brian E Carpenter
>     <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[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] <mailto:[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]
>         <mailto:[e-mail]>] On Behalf Of Toy, Mehmet
>         > Sent: 15 October 2015 04:26
>         > To: Brian E Carpenter <[e-mail]
>         <mailto:[e-mail]>>; Michael Behringer
>         > (mbehring) <[e-mail] <mailto:[e-mail]>>;
>         [e-mail] <mailto:[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]
>         <mailto:[e-mail]>]
>         > Sent: Wednesday, October 14, 2015 5:25 PM
>         > To: Michael Behringer (mbehring); Toy, Mehmet
>         > Cc: '[e-mail] <mailto:[e-mail]>';
>         '[e-mail] <mailto:[e-mail]>'; 'anima-
>         > [e-mail] <mailto:[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]
>         <mailto:[e-mail]>]
>         > > Sent: 14 October 2015 18:30
>         > > To: Michael Behringer (mbehring) <[e-mail]
>         <mailto:[e-mail]>>
>         > > Cc: '[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]>>;
>         '[e-mail] <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[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] <mailto:[e-mail]>]
>         > > Sent: Wednesday, October 14, 2015 11:34 AM
>         > > To: Toy, Mehmet
>         > > Cc: '[e-mail] <mailto:[e-mail]>';
>         '[e-mail] <mailto:[e-mail]>'; 'anima-
>         > [e-mail] <mailto:[e-mail]>';
>         '[e-mail] <mailto:[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]
>         <mailto:[e-mail]>]
>         > > Sent: 13 October 2015 23:46
>         > > To: Michael Behringer (mbehring)
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>
>         > > Cc: '[e-mail] <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;
>         > > '[e-mail] <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;
>         > > '[e-mail]
>         <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;
>         > > '[e-mail]
>         <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[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] <mailto:[e-mail]>]
>         > > Sent: Tuesday, October 13, 2015 12:27 PM
>         > > To: Toy, Mehmet
>         > > Cc: '[e-mail] <mailto:[e-mail]>';
>         '[e-mail] <mailto:[e-mail]>'; 'anima-
>         > [e-mail] <mailto:[e-mail]>';
>         '[e-mail] <mailto:[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]
>         <mailto:[e-mail]>]
>         > > Sent: 13 October 2015 03:53
>         > > To: Michael Behringer (mbehring)
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>
>         > > Cc: '[e-mail] <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;
>         > > '[e-mail] <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;
>         > > '[e-mail]
>         <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;
>         > > '[e-mail]
>         <mailto:[e-mail]>'
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[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] <mailto:[e-mail]>'
>         > > Cc: '[e-mail] <mailto:[e-mail]>';
>         '[e-mail] <mailto:[e-mail]>'; 'anima-
>         > [e-mail] <mailto:[e-mail]>';
>         '[e-mail] <mailto:[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]
>         <mailto:[e-mail]>'; '[e-mail]
>         <mailto:[e-mail]>';
>         > '[e-mail]
>         <mailto:[e-mail]>'; '[e-mail]
>         <mailto:[e-mail]>'
>         > > Cc: '[e-mail] <mailto:[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]
>         <mailto:[e-mail]>]
>         > > Sent: Thursday, October 08, 2015 06:08 AM Eastern Standard
>         Time
>         > > To: Toy, Mehmet;
>         > > [e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;
>         > > [e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;
>         > > [e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>
>         > > Cc: Romascanu, Dan (Dan)
>         > > ([e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>)
>         > > <[e-mail]
>         <mailto:[e-mail]><mailto:[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]
>         <mailto:[e-mail]>]
>         > > Sent: Tuesday, October 06, 2015 1:14 AM
>         > > To: [e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>;
>         > > [e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>;
>         > > [e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         > > Cc: Romascanu, Dan (Dan)
>         > > ([e-mail]
>         <mailto:[e-mail]><mailto:[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] <mailto:[e-mail]>
>         > https://www.ietf.org/mailman/listinfo/anima
>         _______________________________________________
>         Anima mailing list
>         [e-mail] <mailto:[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] <tel:%2B351923095671>
>     www.prkreddy.webs.com <http://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/
>
>
> _______________________________________________
> 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