Subject: Re: [Anima] Self-Managed Networks

From: "Toy, Mehmet" <[email-masked]>
Date: Thu, 15 Oct 2015 02:26:21 +0000

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:[email-masked]] 
Sent: Wednesday, October 14, 2015 5:25 PM
To: Michael Behringer (mbehring); Toy, Mehmet
Cc: [email-masked]'; [email-masked]'; [email-masked]'
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:[email-masked]]
> Sent: 14 October 2015 18:30
> To: Michael Behringer (mbehring) <[email-masked]>
> Cc: [email-masked]' <[email-masked]>; [email-masked]' 
> <[email-masked]>; [email-masked]' 
> <[email-masked]>; [email-masked]' 
> <[email-masked]>
> 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:[email-masked]]
> Sent: Wednesday, October 14, 2015 11:34 AM
> To: Toy, Mehmet
> Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
> 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:[email-masked]]
> Sent: 13 October 2015 23:46
> To: Michael Behringer (mbehring) 
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>
> 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:[email-masked]]
> Sent: Tuesday, October 13, 2015 12:27 PM
> To: Toy, Mehmet
> Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
> 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:[email-masked]]
> Sent: 13 October 2015 03:53
> To: Michael Behringer (mbehring) 
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>
> 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: [email-masked]'
> Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
> 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: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> Subject: Re: Self-Managed Networks
> 
> Sheng,
> Appreciate a quick response.
> I will work on your suggestion.
> Mehmet
> 
> 
> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Thursday, October 08, 2015 06:08 AM Eastern Standard Time
> To: Toy, Mehmet; 
> [email-masked]<mailto:[email-masked]> 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]<mailto:[email-masked]> 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]<mailto:[email-masked]> 
> <[email-masked]<mailto:[email-masked]>>
> Cc: Romascanu, Dan (Dan) 
> ([email-masked]<mailto:[email-masked]>) 
> <[email-masked]<mailto:[email-masked]>>
> 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:[email-masked]]
> Sent: Tuesday, October 06, 2015 1:14 AM
> To: [email-masked]<mailto:[email-masked]>; 
> [email-masked]<mailto:[email-masked]>; 
> [email-masked]<mailto:[email-masked]>
> Cc: Romascanu, Dan (Dan) 
> ([email-masked]<mailto:[email-masked]>)
> 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
> 
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 15 Oct 2015 08:57:12 +0000

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

> From: Anima [mailto:[email-masked]] On Behalf Of Toy, Mehmet
> Sent: 15 October 2015 04:26
> To: Brian E Carpenter <[email-masked]>; Michael Behringer
> (mbehring) <[email-masked]>; [email-masked]
> Subject: Re: [Anima] Self-Managed Networks
> 
> Michael and Brian,
> 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."
> 
> 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."
> > -          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
> > 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.
> > Cc: [email-masked]'; [email-masked]'; 'anima-
> [email-masked]'; [email-masked]'
> > 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
> >
> > 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
> > Cc: [email-masked]'; [email-masked]'; 'anima-
> [email-masked]'; [email-masked]'
> > 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
> >
> >
> > Cc: [email-masked]'; [email-masked]'; 'anima-
> [email-masked]'; [email-masked]'
> > 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
> > To: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> > Cc: [email-masked]'
> > 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
> >
> > 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.
> >
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Reddy Pallavali <[email-masked]>
Date: Thu, 15 Oct 2015 10:08:11 +0100

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) <
[email-masked]> 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.
>
> * 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.
>
> 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.
>
> > [email-masked]'
> > (The ACP needs to be self-repairing, of course.) The signaling protocol
> is also
> > common infrastructure.
> >
> >    Brian
> > > 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:
> > >
> > > ANIMA charter in “M. Behringer, et. al., A Reference Model for
> Autonomic
> > Networking

-- 
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: +351923095671
www.prkreddy.webs.com
http://pt.linkedin.com/in/reddypallavali/

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 15 Oct 2015 09:27:42 +0000

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:[email-masked]]
Sent: 15 October 2015 11:08
To: Michael Behringer (mbehring) <[email-masked]>
Cc: Toy, Mehmet <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> 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.

Michael

> From: Anima [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Toy, Mehmet
> To: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; Michael Behringer
> (mbehring) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> From: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; 'anima-
> [email-masked]<mailto:[email-masked]>'
> > From: Toy, Mehmet [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>>
> > Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>'
> > From: Michael Behringer (mbehring) [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; 'anima-
> [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
> > From: Toy, Mehmet [mailto:[email-masked]<mailto:[email-masked]>]
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > Cc: [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > From: Michael Behringer (mbehring) [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; 'anima-
> [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
> > From: Toy, Mehmet [mailto:[email-masked]<mailto:[email-masked]>]
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > Cc: [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > [email-masked]<mailto:[email-masked]>'
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > To: [email-masked]<mailto:[email-masked]>'
> > Cc: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; 'anima-
> [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
> > To: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>';
> [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
> > Cc: [email-masked]<mailto:[email-masked]>'
> > From: Sheng Jiang [mailto:[email-masked]<mailto:[email-masked]>]
> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > Cc: Romascanu, Dan (Dan)
> > ([email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>)
> > <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > From: Toy, Mehmet [mailto:[email-masked]<mailto:[email-masked]>]
> > To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>;
> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>;
> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > Cc: Romascanu, Dan (Dan)
> > ([email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>)
> [email-masked]<mailto:[email-masked]>
_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

Yours sincerely,

COPE LABS, Universidade Lusofona, Lisboa - Portugal.
Author of: Security Issues of Cloud Computing over General & IT Sector
Mobile: +351923095671
www.prkreddy.webs.com<http://www.prkreddy.webs.com>
http://pt.linkedin.com/in/reddypallavali/

---

From: Reddy Pallavali <[email-masked]>
Date: Thu, 15 Oct 2015 11:03:12 +0100

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) <
[email-masked]> wrote:

> 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.
>
>
>
> *From:* Reddy Pallavali [mailto:[email-masked]]
> *Sent:* 15 October 2015 11:08
> *To:* Michael Behringer (mbehring) <[email-masked]>
> *Cc:* Toy, Mehmet <[email-masked]>; Brian E Carpenter <
> [email-masked]>; [email-masked]
>
> *Subject:* Re: [Anima] Self-Managed Networks
>
>
>
> Hi,
>
> Since, synchronization is more towards centralized "Coordinator initiate
> to agree on something (towards centralized), and others have to adjust
> their state".
>

Yours sincerely,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Oct 2015 11:48:52 +1300

> * 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 namin…

Well, hold on. The ACP is the substrate for GRASP, but GRASP is defined so that in theory
it could run without the ACP (e.g. running over TLS). ACP+GRASP+etc = ANI (AN infrastructure).

> There is *one* ACP, there are *many* autonomic functions on top. 

Indeed, and fault management mechanisms are certainly important ones.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Oct 2015 12:00:19 +1300

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

---

From: "Toy, Mehmet" <[email-masked]>
Date: Fri, 16 Oct 2015 03:36:09 +0000

Michael,

Before I pick each of your statement and express my thoughts, I would like to ask more questions by picking your  statement " There is *one* ACP, there are *many* autonomic functions on top.".   Assume we  start building on this to see how far we can go, whether this holds for all cases or not, I don't know.  

If we have two or more ACPs, what could go wrong? What is it that you are trying to do here? What is the purpose behind this model?

Furthermore, I suggest you to think about ETSI NFV model, "infrastructure" and "VNF" division of networks.  What is wrong in using that kind of model here which is a reasonable breakdown, instead of sticking with ACP  that is becoming very difficult to define?

Thanks
Mehmet
  
-----Original Message-----
From: Michael Behringer (mbehring) [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 4:57 AM
To: Toy, Mehmet; Brian E Carpenter; [email-masked]
Subject: RE: Self-Managed Networks

Michael

> 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."
> 
> 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."
> automatically adapt to new situations. But to me, this isn’t fault 
> management or performance management as an operator understands it.
> >
> > Instead of answering the question as Yes or No, let me give examples 
> > to
> see what makes sense.
> 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
> >
> is a control feedback related measurement in the document, I don’t 
> know if it is adequate.
> >
> > Regards,
> > Mehmet
> 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?
> we’re currently defining. So, please have a look whether your thoughts 
> can be described as an autonomic function. I think they probably can.
> 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.
> a short paragraph about fault management, and I suppose we’d point to 
> your draft, right?
> > Michael
> >
> >
> 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
> >
> 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.
> >
> charter since without covering fault management aspect of the 
> autonomic networks, the concept of autonomic network will be incomplete.
> >
> > Regards,
> > Mehmet
> >
> >
> 
>

---

From: "Toy, Mehmet" <[email-masked]>
Date: Fri, 16 Oct 2015 04:04:58 +0000

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:[email-masked]]
Sent: Thursday, October 15, 2015 6:03 AM
To: Michael Behringer (mbehring)
Cc: Toy, Mehmet; Brian E Carpenter; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Reddy,

Michael

From: Reddy Pallavali [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 15 October 2015 11:08
To: Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>>
Cc: Toy, Mehmet <[email-masked]<mailto:[email-masked]>>; Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi,

Michael

Yours sincerely,

Mobile: +351923095671<tel:%2B351923095671>

Yours sincerely,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Oct 2015 18:28:46 +1300

> On the other hand  if we are talking timing relationship between two ends of  a  circuit emulation, we have to use “synchronization”.

We are not using the word "synchronization" to refer to time synch, only to synching
data state between nodes.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Oct 2015 19:02:02 +1300

On 16/10/2015 16:36, Toy, Mehmet wrote:
> If we have two or more ACPs, what could go wrong?

Why would a domain need more than one ACP? (Certainly there might be a transient
situation after a temporary network partition where two ACPs would "meet" and
then need to merge; indeed the ACP needs to be self-repairing in such cases.)

> What is it that you are trying to do here? What is the purpose behind this model?

Provide a secure L3 between all autonomic nodes that is strictly independent of
the operational data plane. The purpose is to allow autonomic operations to work
regardless of anything else.

> 
> Furthermore, I suggest you to think about ETSI NFV model, "infrastructure" and "VNF" division of networks.  What is wrong in using that kind of model here which is a reasonable breakdown, 

We aren't reinventing NFV, as far as I can tell. If there is a recent technical overview of
NFV, that would be interesting to see. But I don't believe that Autonomic Service Agents
are at all the same thing as VNFs.

> instead of sticking with ACP  that is becoming very difficult to define?

Huh? draft-ietf-anima-autonomic-control-plane is still work in progress but
it seems very clearly defined to me. In sketching out how GRASP will be implemented,
I haven't hit any conceptual problems with the ACP, and its main API will
just be socket calls. The only complication I found is that it will need to
support the Advanced Socket API because of some special requirements for
link-local multicasts. Otherwise, it's just another virtual (loopback) network
interface.

Regards
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 16 Oct 2015 08:44:17 +0000

Adding to Brian's response (which I agree with), and up-levelling the discussion a bit: 

Mehmet, I think there is a simple misunderstanding here. The ACP is a control plane for *device* management. A device can hold many contexts, as in NFV, but they are all managed in a single way. My feeling is we have a disconnect somewhere on this level, right? 

Michael

> Sent: 16 October 2015 08:02
> To: Toy, Mehmet <[email-masked]>; Michael Behringer
> > Before I pick each of your statement and express my thoughts, I would like
> to ask more questions by picking your  statement " There is *one* ACP,
> there are *many* autonomic functions on top.".   Assume we  start building
> on this to see how far we can go, whether this holds for all cases or not, I
> don't know.
> >
> Why would a domain need more than one ACP? (Certainly there might be a
> transient situation after a temporary network partition where two ACPs
> would "meet" and then need to merge; indeed the ACP needs to be self-
> repairing in such cases.)
> 
> Provide a secure L3 between all autonomic nodes that is strictly independent
> of the operational data plane. The purpose is to allow autonomic operations
> to work regardless of anything else.
> 
> >
> > Furthermore, I suggest you to think about ETSI NFV model,
> > "infrastructure" and "VNF" division of networks.  What is wrong in
> > using that kind of model here which is a reasonable breakdown,
> 
> We aren't reinventing NFV, as far as I can tell. If there is a recent technical
> overview of NFV, that would be interesting to see. But I don't believe that
> Autonomic Service Agents are at all the same thing as VNFs.
> 
> Huh? draft-ietf-anima-autonomic-control-plane is still work in progress but it
> seems very clearly defined to me. In sketching out how GRASP will be
> implemented, I haven't hit any conceptual problems with the ACP, and its
> main API will just be socket calls. The only complication I found is that it will
> need to support the Advanced Socket API because of some special
> requirements for link-local multicasts. Otherwise, it's just another virtual
> (loopback) network interface.
> 
> Regards
>    Brian
> 
> >
> > Thanks
> > Mehmet
> >
> > 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
> >> (Alarm Indication Signal) and the receiving  end generates RDI
> >> (remote Defect Indicator).  Both messages are generated by the
> hardware, not by a
> >> 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
> >>>
> >> the description  of ANI or to section 4 to add a sub-section for
> >> Fault Management.
> >>>
> >> 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
> >> we’re currently defining. So, please have a look whether your
> >> thoughts can be described as an autonomic function. I think they probably
> can.
> >> the overall topic briefly, and point to an external doc for now,
> >> i.e., probably your draft.
> >> 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
> >>>
> >> do not  articulate fault management aspect of the self-management.
> >> It is possible to interpret the fault management aspect of autonomic

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 16 Oct 2015 12:52:58 +0200

Dear Michael, all,

I am not sure to fully understand what you mean by "The ACP is a control 
plane for *device* management."
In the abstract of the ACP draft, it is written that the ACP is the 
control plane for autonomic functions. Statement which I agree with.
If I try to interpret (please correct if I am wrong) "ACP for device" as 
stated above, it means that the ACP runs between devices (dubbed 
autonomic nodes) hosting autonomic functions (e.g. one or more ASAs).

To stress what Toerless mentioned in a previous message:
"1) easily, ideally autonomous downloadable agent/application infra.

Eg: I don't see any way that either vendors or operators could 
realistically build this framework if these components are tied into the 
classical router OS software delivery model where it takes months to 
validate a software update and more months to deploy it. If this can be 
downloaded, as separate apps then its so much easier to incrementally 
build/deploy it on a totally different deployment process."

I think it is important to support such flexibility for the deployment, 
and therefore:
     -to stress that the ACP runs between devices (dubbed autonomic 
nodes) hosting autonomic functions (e.g. one or more ASAs).
     -to allow ASAs to be deployed (and execute) on hosts different from 
the hosts/resources they are supposed to manage. of course, this model 
does not preclude ASAs to be directly hosted/integrated with the device.

HTH, best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 16 Oct 2015 12:58:56 +0200

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:
> Consensus relay convergence time, robustness, and fault-tolerance 
> against failures (e.g. termination, validation, integrity and agreement).
>
> 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.
>
> On Thu, Oct 15, 2015 at 10:27 AM, Michael Behringer (mbehring) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Reddy,
>
>     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.
>
>     *From:*Reddy Pallavali [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Michael Behringer (mbehring) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Toy, Mehmet <[email-masked]
>     <mailto:[email-masked]>>; Brian E Carpenter
>     <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>
>
>     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".
>
>     intelligence by simple communication rules (fully distributed),
>     and majority opinion is valid".
>
>     On Thu, Oct 15, 2015 at 9:57 AM, Michael Behringer (mbehring)
>     <[email-masked] <mailto:[email-masked]>> 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.
>
>         * 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.
>
>         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
>         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.
>
>         > From: Anima [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of Toy, Mehmet
>         > To: Brian E Carpenter <[email-masked]
>         <mailto:[email-masked]>>; Michael Behringer
>         > (mbehring) <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>
>         > I re-read the "A Reference Model for Autonomic Networking"
>         document and
>         > I am not clear about the definitions.
>         >
>         > Question: What are the "must implement" functionalities? 
>         How do you
>         > define "must implement" functionalities?
>         >
>         > Thanks
>         > Mehmet
>         > Cc: [email-masked] <mailto:[email-masked]>';
>         [email-masked] <mailto:[email-masked]>'; 'anima-
>         > [email-masked] <mailto:[email-masked]>'
>         > 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
>         > > 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:
>         > >
>         > > Cc: [email-masked] <mailto:[email-masked]>'
>         <[email-masked] <mailto:[email-masked]>>;
>         > [email-masked] <mailto:[email-masked]>'
>         > > <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>'
>         [email-masked] <mailto:[email-masked]>'
>         > > Instead of answering the question as Yes or No, let me
>         give examples to
>         > see what makes sense.
>         > > From: Michael Behringer (mbehring)
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         > > Cc: [email-masked] <mailto:[email-masked]>';
>         [email-masked] <mailto:[email-masked]>'; 'anima-
>         > [email-masked] <mailto:[email-masked]>';
>         [email-masked] <mailto:[email-masked]>'
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         > > Cc: [email-masked] <mailto:[email-masked]>'
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>;
>         > > [email-masked] <mailto:[email-masked]>'
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>;
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>;
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         > > From: Michael Behringer (mbehring)
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         > > Cc: [email-masked] <mailto:[email-masked]>';
>         [email-masked] <mailto:[email-masked]>'; 'anima-
>         > [email-masked] <mailto:[email-masked]>';
>         [email-masked] <mailto:[email-masked]>'
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         > > Cc: [email-masked] <mailto:[email-masked]>'
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>;
>         > > [email-masked] <mailto:[email-masked]>'
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>;
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>;
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         > > To: [email-masked] <mailto:[email-masked]>'
>         > > Cc: [email-masked] <mailto:[email-masked]>';
>         [email-masked] <mailto:[email-masked]>'; 'anima-
>         > [email-masked] <mailto:[email-masked]>';
>         [email-masked] <mailto:[email-masked]>'
>         > > To: [email-masked]
>         <mailto:[email-masked]>'; [email-masked]
>         <mailto:[email-masked]>';
>         > [email-masked]
>         <mailto:[email-masked]>'; [email-masked]
>         <mailto:[email-masked]>'
>         > > Cc: [email-masked] <mailto:[email-masked]>'
>         > > [email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>;
>         > > [email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>;
>         > > [email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         > > Cc: Romascanu, Dan (Dan)
>         > > ([email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>)
>         > > <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         > > To: [email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>;
>         > > [email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>;
>         > > [email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>
>         > > Cc: Romascanu, Dan (Dan)
>         > > ([email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>)
>         > > ANIMA charter in “M. Behringer, et. al., A Reference Model
>         for Autonomic
>         > Networking
>         > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     Mobile: +351923095671 <tel:%2B351923095671>
>     www.prkreddy.webs.com <http://www.prkreddy.webs.com>

-- 

*Laurent Ciavaglia*

Secure Cloud Networking

phone: +33 160 402 636

---

From: Duzongpeng <[email-masked]>
Date: Fri, 16 Oct 2015 11:47:03 +0000

Hi Laurent,
         I agree that a downloadable agent infra is attractive, but I am a little confused with your statement.
“-to allow ASAs to be deployed (and execute) on hosts different from the hosts/resources they are supposed to manage.”
         Can you give an example for this situation? Or explain under what situation, a different host is involved, and what is the benefit? Thanks.

Best Regards
Zongpeng Du
From: Anima [mailto:[email-masked]] On Behalf Of Laurent Ciavaglia
Sent: Friday, October 16, 2015 6:53 PM
To: Michael Behringer (mbehring); Brian E Carpenter; Toy, Mehmet; [email-masked]
Subject: Re: [Anima] Self-Managed Networks

Dear Michael, all,

I am not sure to fully understand what you mean by "The ACP is a control plane for *device* management."
In the abstract of the ACP draft, it is written that the ACP is the control plane for autonomic functions. Statement which I agree with.
If I try to interpret (please correct if I am wrong) "ACP for device" as stated above, it means that the ACP runs between devices (dubbed autonomic nodes) hosting autonomic functions (e.g. one or more ASAs).

Eg: I don't see any way that either vendors or operators could realistically build this framework if these components are tied into the classical router OS software delivery model where it takes months to validate a software update and more months to deploy it. If this can be downloaded, as separate apps then its so much easier to incrementally build/deploy it on a totally different deployment process."

I think it is important to support such flexibility for the deployment, and therefore:
    -to stress that the ACP runs between devices (dubbed autonomic nodes) hosting autonomic functions (e.g. one or more ASAs).
    -to allow ASAs to be deployed (and execute) on hosts different from the hosts/resources they are supposed to manage. of course, this model does not preclude ASAs to be directly hosted/integrated with the device.

Michael

-----Original Message-----

To: Toy, Mehmet <[email-masked]><mailto:[email-masked]>; Michael Behringer

(mbehring) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Michael,

don't know.

What is it that you are trying to do here? What is the purpose behind this

model?

Regards

   Brian

Thanks

Mehmet

-----Original Message-----

To: Toy, Mehmet; Brian E Carpenter; [email-masked]<mailto:[email-masked]>

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:

an autonomic function.

Look at

Probably we should take some off-line time in Yokohama to discuss this in a

small team?

Michael

-----Original Message-----

From: Anima [mailto:[email-masked]] On Behalf Of Toy,

Mehmet

To: Brian E Carpenter <[email-masked]><mailto:[email-masked]>; Michael

Behringer

(mbehring) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Michael and Brian,

interactions of the Autonomic Networking Infrastructure with other

nodes and services.".

Question: What are the "must implement" functionalities?  How do you

Thanks

Mehmet

-----Original Message-----

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

top of

the ACP.

confusion

here:

management or performance management as an operator understands

it.

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

To: Michael Behringer (mbehring) <[email-masked]><mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>' <[email-masked]><mailto:[email-masked]>;

<[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>'

<[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>'

<[email-masked]><mailto:[email-masked]>

Michael,

to

see what makes sense.

Let’s say in a data path, a router port is failed.  The router

generates an AIS

hardware, not by a

software or ACP.   As a result of this failure,  there would be packet loss.

The

Thanks

Mehmet

To: Toy, Mehmet

Hi Toy,

To understand better: To me, fault management *uses* the functions

of

Do we agree?

Michael

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>;

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>;

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>;

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>

Michael,

Appreciate the reply.

My plan is to add a short paragraph for now either to section 2 to

expand

Fault Management.

It is also possible too add a Performance Management section to

describe

Regards,

Mehmet

To: Toy, Mehmet

To me, fault management refers generally to faults on the data

plane, ie for

So my feeling is that function would reside on top of the

infrastructure that

can.

If you agree, can you suggest where in the reference model you would

add

your draft, right?

Michael

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>;

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>;

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>;

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>

Mike,

Thanks

Mehmet

From: Toy, Mehmet

Mike,

I can send you some text to include in section 2 and 4 of  “A

Reference

Should I just do that?

Thanks

Mehmet

From: Toy, Mehmet

Sheng,

Mehmet

To: Toy, Mehmet;

[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>;

[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>;

[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>

Cc: Romascanu, Dan (Dan)

([email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>)

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>>

Hi, Toy,

First of all, for my understanding, your work is in the scope of the

WG

model document.

Best regards,

Sheng

To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>;

[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>;

[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>

Cc: Romascanu, Dan (Dan)

([email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>)

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”.

framework.

Autonomic

Networking

Autonomic Control Plane,

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

autonomic networks, the concept of autonomic network will be

incomplete.

Regards,

Mehmet

Anima mailing list

Anima mailing list

--

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636
email: [email-masked]<mailto:[email-masked]>
linkedin: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 Nozay | France

---

From: Reddy Pallavali <[email-masked]>
Date: Fri, 16 Oct 2015 12:52:46 +0100

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 <[email-masked]>
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”.
>
>
>
> *Sent:* Thursday, October 15, 2015 6:03 AM
> *To:* Michael Behringer (mbehring)
> *Cc:* Toy, Mehmet; Brian E Carpenter; [email-masked]
>
> autonomic
> management
> this is a
> function (or
> can
> your
> aspect of
> in

Yours sincerely,

---

From: "Toy, Mehmet" <[email-masked]>
Date: Fri, 16 Oct 2015 15:35:51 +0000

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Friday, October 16, 2015 2:02 AM
To: Toy, Mehmet; Michael Behringer (mbehring); [email-masked]
Subject: Re: Self-Managed Networks

> If we have two or more ACPs, what could go wrong?

Why would a domain need more than one ACP? (Certainly there might be a transient situation after a temporary network partition where two ACPs would "meet" and then need to merge; indeed the ACP needs to be self-repairing in such cases.)
MT:  Does that mean that ACP is for one AS? If it is, how do we deal with a network of multiple ASs?

> What is it that you are trying to do here? What is the purpose behind this model?

Provide a secure L3 between all autonomic nodes that is strictly independent of the operational data plane. The purpose is to allow autonomic operations to work regardless of anything else.
MT:  Does this mean Autonomous nodes are part of a layer above "infrastructure (i.e. operational data plane)"?  If it is what is that layer? Is it part of a control plane?
> using that kind of model here which is a reasonable breakdown,

We aren't reinventing NFV, as far as I can tell. If there is a recent technical overview of NFV, that would be interesting to see. But I don't believe that Autonomic Service Agents are at all the same thing as VNFs.
MT: OK, then why are not we using "infrastructure" terminology? Is ACP above the infrastructure? 

> instead of sticking with ACP  that is becoming very difficult to define?

Huh? draft-ietf-anima-autonomic-control-plane is still work in progress but it seems very clearly defined to me. In sketching out how GRASP will be implemented, I haven't hit any conceptual problems with the ACP, and its main API will just be socket calls. The only complication I found is that it will need to support the Advanced Socket API because of some special requirements for link-local multicasts. Otherwise, it's just another virtual (loopback) network interface.
MT: I will talk to Toerless this afternoon to make sure I fully understand the approach.  However, it could be useful to pick a network of 4 nodes (2 PEs and 2Ps) and clearly  indicate what functions constitute an ACP and what functions constitute ASs,

Regards
   Brian

>> (remote Defect Indicator).  Both messages are generated by the hardware, not by a
>> thoughts can be described as an autonomic function. I think they probably can.
>> description, maybe mainly abstracted functionality, into the reference model document.
>>> Best regards,
>>> Sheng
>>>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 16 Oct 2015 17:10:37 +0000

Hi Laurent,
From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 16 October 2015 12:53
To: Michael Behringer (mbehring) <[email-masked]>; Brian E Carpenter <[email-masked]>; Toy, Mehmet <[email-masked]>; [email-masked]
Subject: Re: [Anima] Self-Managed Networks

Dear Michael, all,

I am not sure to fully understand what you mean by "The ACP is a control plane for *device* management."
MB: This was in the context of NFV, and the point I’m trying to make was that the ANI is not in one of the virtual contexts, but on the data plane of the device itself. It’s essentially a management function, albeit an automated one.

MB: I think we probably think the same thing. It’s probably just a question of phrasing. However, the “just” may be too optimistic, clearly the wording isn’t quite right yet. :-/

I think it is important to support such flexibility for the deployment, and therefore:
    -to stress that the ACP runs between devices (dubbed autonomic nodes) hosting autonomic functions (e.g. one or more ASAs).
MB: Isn’t that just what I said? To me it sounds you’re saying the same thing that I did earlier?!? ;-)

MB: Agree.

Michael

-----Original Message-----

Michael,

don't know.

model?

Regards

   Brian

Thanks

Mehmet

-----Original Message-----

the fundamental idea.

Autonomic Functions:

an autonomic function.

Look at

small team?

Michael

-----Original Message-----

Mehmet

Behringer

Michael and Brian,

nodes and services.".

Thanks

Mehmet

-----Original Message-----

autonomic functions.

   Brian

top of

the ACP.

confusion

here:

it.

simple as we

IMO.

What do you think?

Michael

Michael,

to

see what makes sense.

generates an AIS

hardware, not by a

The

Thanks

Mehmet

To: Toy, Mehmet

Hi Toy,

of

Do we agree?

Michael

Michael,

Appreciate the reply.

expand

Fault Management.

describe

Regards,

Mehmet

To: Toy, Mehmet

plane, ie for

infrastructure that

can.

add

your draft, right?

Michael

Mike,

Thanks

Mehmet

From: Toy, Mehmet

Mike,

Reference

Should I just do that?

Thanks

Mehmet

From: Toy, Mehmet

Sheng,

Mehmet

To: Toy, Mehmet;

Cc: Romascanu, Dan (Dan)

Hi, Toy,

WG

model document.

Best regards,

Sheng

Cc: Romascanu, Dan (Dan)

Dear All:

present

Hierarchy”.

framework.

Autonomic

Networking

Autonomic Control Plane,

in the contribution.

the

incomplete.

Regards,

Mehmet

Anima mailing list

Anima mailing list

--

Laurent Ciavaglia
Secure Cloud Networking

phone: +33 160 402 636

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Oct 2015 10:28:36 +1300

Hello all,
>          Can you give an example for this situation? Or explain under what situation, a different host is involved, and what is the benefit? Thanks.

Well, if you consider the prefix management use case, the various ASAs that negotiate
allocations of prefixes with each other might also be running standard prefix
delegation to a group of traditional routers which are not autonomic nodes.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Oct 2015 10:36:24 +1300

> MT:  Does that mean that ACP is for one AS? If it is, how do we deal with a network of multiple ASs?

An ACP is for one autonomic domain. If that isn't clear in the ACP draft, I'm sure
Michael will fix it.

> MT:  Does this mean Autonomous nodes are part of a layer above "infrastructure (i.e. operational data plane)"?  If it is what is that layer? Is it part of a control plane?

AutonomIC Nodes form a control plane, indeed. We expect that it will co-exist with
traditional control planes in the real world.

> MT: OK, then why are not we using "infrastructure" terminology? Is ACP above the infrastructure? 

Does it matter? It's a virtual layer that happens to run over link-local
packets, so doesn't depened on the data plane layer 3.

    Brian

---

From: John Strassner <[email-masked]>
Date: Sat, 17 Oct 2015 11:08:20 -0700

Hi,

sorry for the late reply, I've been buried in writing I-Ds.

In response to the original train of emails (not the latest from
Mehmet), Michael made a key point:

> 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 last phrase ("as an operator understands it) is what is so
important. We need to differentiate between functions that
the Autonomic System provides and functions that are visible
to the operator.

When an autonomic system self-heals, why would the operator
need to know? This is comparable to routing doing its job and
changing the path. There is no reason that the operator has to
be alerted on every change in the system - there are already
WAY TOO MANY of these for the operator to handle.

IMHO, there are core functions provided by the ACP, and functions
that sit on top of the ACP and use these core functions. FM and PM
should sit on top of the ACP. Otherwise, the ACP doesn't scale,
because why is FM or PM more important than config mgmt.,
security, accounting, analytics, ...?

Finally, I don't see any difference between a) and b). You have an
ACP, and you have a set of Autonomic Functions that use the ACP.
(You probably have different layers of Autonomic Functions, where
a core set of Autonomic Functions are reused by other Autonomic
Functions to provide more powerful Autonomic Functions, but this
hasn't been discussed yet (I think)). The point is that you must start
with a small set of Autonomic Functions. Otherwise, the ACP becomes
a big, bloated, Ball of Mud and will end up useless.

regards,
John

---

From: John Strassner <[email-masked]>
Date: Sat, 17 Oct 2015 19:07:31 -0700

Hi,

> If we have two or more ACPs, what could go wrong?

An ACP is just like a domain. So, of course you will have multiple
ACPs. The open question is whether we want simple inter-domain
communication and/or federated domains. FOCALE did both.

> "infrastructure" and "VNF" division of networks.

Yuck (that was the technical answer); see below

> What is wrong in using that kind of model here which is a
> reasonable breakdown

I could go on for 20 pages, since I participed in SWA, MANO, and
INF in Phase 1 and have looked at IFA and EVE in phase 2. A
small summary:

   - VNFs are not ASAs; please explain why you think they are
   - The reference points defined in NFV are vague at best;
      certainly one could not write software against them
   - The APIs are ill-formed
   - The model is horrible. There isn't even a decent set of model
     requirements (e.g., how on earth could someone say you have
     an information model (thankfully changed after 6 months of
     arguing to an "information element") that does not even define
     a data type for the entity?
   - There is no relation to any business concepts
   - There is no policy element

> instead of sticking with ACP  that is becoming very difficult to define?

I fail to see what is so confusing about the ACP definition, sorry.

regards,
John

On Thu, Oct 15, 2015 at 8:36 PM, Toy, Mehmet <[email-masked]>
wrote:

> on this to see how far we can go, whether this holds for all cases or not,
> I don't know.
>
> If we have two or more ACPs, what could go wrong? What is it that you are
> trying to do here? What is the purpose behind this model?
>
> Furthermore, I suggest you to think about ETSI NFV model, "infrastructure"
> and "VNF" division of networks.  What is wrong in using that kind of model
> here which is a reasonable breakdown, instead of sticking with ACP  that is
> becoming very difficult to define?
>
> Thanks
> Mehmet
>

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Sun, 18 Oct 2015 07:48:50 +0000

> An ACP is for one autonomic domain. If that isn't clear in the ACP draft, I'm
> sure Michael will fix it.

Yes, Brian is right. Note that domain isn't the same thing as "AS" (if you mean "autonomous system" in the BGP sense). A "domain" in our definition is defined simply by the certifiates. Devices with the same domain in the certificate belong together. 

Those certificates are allocated when an autonomic device registers. The operator can control precisely which devices end up in which domain. And this has nothing to do BGP ASs. An autonomic domain can contain several BGP ASs, and a  BGP AS could be separated in several domains. In fact you could even combine parts of the devices in AS1 with parts of devices in another AS into one autonomic domain. 

Michael

---

From: "Toy, Mehmet" <[email-masked]>
Date: Sun, 18 Oct 2015 15:13:17 +0000

Michael,
Yes there was.
Discussion with Toerless made it clear to me that the model is for "auto routing and auto discovery".
Mehmet

-----Original Message-----
From: Michael Behringer (mbehring) [mailto:[email-masked]] 
Sent: Friday, October 16, 2015 4:44 AM
To: Brian E Carpenter; Toy, Mehmet; [email-masked]
Subject: RE: Self-Managed Networks

Michael

> on this to see how far we can go, whether this holds for all cases or 
> not, I don't know.
> >
> Provide a secure L3 between all autonomic nodes that is strictly 
> independent of the operational data plane. The purpose is to allow 
> autonomic operations to work regardless of anything else.
> 
> >
> We aren't reinventing NFV, as far as I can tell. If there is a recent 
> technical overview of NFV, that would be interesting to see. But I 
> don't believe that Autonomic Service Agents are at all the same thing as VNFs.
> 
> Huh? draft-ietf-anima-autonomic-control-plane is still work in 
> progress but it seems very clearly defined to me. In sketching out how 
> GRASP will be implemented, I haven't hit any conceptual problems with 
> the ACP, and its main API will just be socket calls. The only 
> complication I found is that it will need to support the Advanced 
> Socket API because of some special requirements for link-local 
> multicasts. Otherwise, it's just another virtual
> obviously, we all need the same view to progress further. So this is a 
> very important discussion, and I really welcome it.
> >
> 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.
> >
> > 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.
> >
> >> autonomic functions.(The ACP needs to be self-repairing, of 
> >> course.) The signaling protocol is also common infrastructure."
> >>
> >> 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
> >>> 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:
> >>>
> >>> Instead of answering the question as Yes or No, let me give 
> >>> examples to
> >> see what makes sense.
> >> to me, this is a logical component of an autonomic network that 
> >> sits on top of the AN infrastructure.
> >>> Do we agree?
> >>> Michael
> >>>
> >> function (or several, for different aspects). Would you agree? Or 
> >> do you see that as a function inside the AN infrastructure?
> >> a short paragraph about fault management, and I suppose we’d point 
> >> to your draft, right?
> >>> Michael
> >>>
> >>>
> >> plan, autonomic service agents are mainly for the next period, 
> >> which is after re-charter (this is the same with your suggestion of 
> >>> To: 
> >>> [email-masked]<mailto:[email-masked]>;
> >> 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,
> >> 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,

---

From: "Toy, Mehmet" <[email-masked]>
Date: Sun, 18 Oct 2015 15:13:17 +0000

Reddy,
I believe SyncE can be implemented in distributed fashion. Nevertheless, it looks like we agree on the definitions of consensus and synchronization.
Regards,
Mehmet

From: Reddy Pallavali [mailto:[email-masked]]
Sent: Friday, October 16, 2015 7:53 AM
To: Toy, Mehmet
Cc: Michael Behringer (mbehring); Brian E Carpenter; [email-masked]; Paulo Mendes
Subject: Re: [Anima] Self-Managed Networks

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 <[email-masked]<mailto:[email-masked]>> 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”.

From: Reddy Pallavali [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 15, 2015 6:03 AM
To: Michael Behringer (mbehring)
Cc: Toy, Mehmet; Brian E Carpenter; [email-masked]<mailto:[email-masked]>

Michael

Hi,

Michael

Yours sincerely,

Yours sincerely,

Yours sincerely,

---

From: "Toy, Mehmet" <[email-masked]>
Date: Sun, 18 Oct 2015 15:13:18 +0000

From: John Strassner [mailto:[email-masked]]
Sent: Saturday, October 17, 2015 10:08 PM
To: Toy, Mehmet; John Strassner
Cc: Michael Behringer (mbehring); Brian E Carpenter; [email-masked]
Subject: Re: [Anima] Self-Managed Networks

Hi,

MT: That is what I was trying to understand.  As Brian said, ACP is a single domain.  If it is, how will multiple domains work together?
Again, it is OK to keep the current scope small, but we really need a comprehensive reference model.

MT: I don’t think I know well what ASA includes to compare them.  After talking to Toerless, I realized that “infrastructure and virtualize  network” division does not apply here.
MT: “Vague” is a kind word!

I fail to see what is so confusing about the ACP definition, sorry.
MT:  Discussion with Toerless was helpful. I need to re-read the reference model to see if I have any more issues.

regards,
John

On Thu, Oct 15, 2015 at 8:36 PM, Toy, Mehmet <[email-masked]<mailto:[email-masked]>> wrote:
Michael,

Thanks
Mehmet

-----Original Message-----
From: Michael Behringer (mbehring) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, October 15, 2015 4:57 AM
To: Toy, Mehmet; Brian E Carpenter; [email-masked]<mailto:[email-masked]>
Subject: RE: Self-Managed Networks

Michael

--
regards,
John

---

From: Reddy Pallavali <[email-masked]>
Date: Sun, 18 Oct 2015 16:37:36 +0100

Mehmet,

Of course SyncE can be implemented in a distributed fashion.
But, the main issue hear is that, in synchronization Source node has to
force to change the Sink nodes time (have to force all the nodes to change
their timings). I think isnt an efficient enough since, in geographic area,
cannot force all objects to change their timings (the global time conflicts
with the local time). So, i am arguing  that the need of consensus.

In consensus no object forces no object to change something, however they
will reach global intelligence by means of simple local communications.
Here we have to think about convergence (can be achieved with suitable SI
algorithm).

On Sun, Oct 18, 2015 at 4:13 PM, Toy, Mehmet <[email-masked]>
wrote:

> Reddy,
>
> I believe SyncE can be implemented in distributed fashion. Nevertheless,
> it looks like we agree on the definitions of consensus and synchronization.
>
> Regards,
>
> Mehmet
>
>
>
>
>
> *Sent:* Friday, October 16, 2015 7:53 AM
> *To:* Toy, Mehmet
> *Cc:* Michael Behringer (mbehring); Brian E Carpenter; [email-masked];
> Paulo Mendes
>

Yours sincerely,

---

From: John Strassner <[email-masked]>
Date: Sun, 18 Oct 2015 16:03:11 -0700

I for one think that these are just examples. It is a **control plane**,
so it should not be **limited** to those functions.

Toerless, can you elaborate?

regards,
John

On Sun, Oct 18, 2015 at 8:13 AM, Toy, Mehmet <[email-masked]>
wrote:

> Mehmet, I think there is a simple misunderstanding here. The ACP is a
> control plane for *device* management. A device can hold many contexts, as
> in NFV, but they are all managed in a single way. My feeling is we have a
> disconnect somewhere on this level, right?
>
> Michael
>

-- 
regards,
John

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Mon, 19 Oct 2015 03:12:15 +0000

From: Anima on behalf of John Strassner
Date: Saturday, October 17, 2015 at 11:08 AM
To: "Toy, Mehmet", John Strassner
Cc: "[email-masked]<mailto:[email-masked]>", "Michael Behringer (mbehring)"
Subject: Re: [Anima] Self-Managed Networks

Hi,

>>JMC>> I think that we need to leave the option up to the operator.  Today there are many messages that go to the operator, but they are left to the operator to determine if they are important or not.  Sometimes, operators will simply store the messages for review at a later time or in a  problem management situation to look back and see if there is a pattern in the messaging that indicates a chronic type of issue.

>>JMC>> As we start to add AN services onto these nodes, then issues with the ACP can become issues that are business/service impacting.  In these cases it is important for the operator to be able to see the messages to know if the issue is with the service, the hardware, or the ACP.

>>JMC>>  I think that I agree here, but want to be sure that I understand properly.  You are stating that the ACP is simply the control plane that builds a foundation.  The functions that are then installed onto a device will have the ability to use that foundation per a defined set of interactions, such as an API or otherwise.  The functions may work alone or they may work together to support the services that they were created to do.  In this way AN provides a  methodology and connectivity model for the AN Functions to communicate with the ACP and possibly with each other.  The ACP does not worry about the AN Functions other than the defined communication in and out.  Much like the layers in the OSI model work together, but ultimately do not care what is happening inside of each layer, but focused on communication between layers.

regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 19 Oct 2015 19:27:49 -0700

Hi Jason,

...

>>JMC>> I think that we need to leave the option up to the operator.  Today
there are many messages that go to the operator, but they are left to the
operator to determine if they are important or not.  Sometimes, operators
will simply store the messages for review at a later time or in a  problem
management situation to look back and see if there is a pattern in the
messaging that indicates a chronic type of issue.

<jcs>
Let me rephrase.
I've spent over 15 years building sophisticated correlation
engines whose sole purpose was to reduce the number of
alarms sent to the operator, because they are overwhelmed.
This does NOT mean that all alarms should be filtered; clearly,
critical alarms should be seen, as long as they are unique.

What I'm worried about is the typical alarm storm of informational
alarms that we've seen way too many times.

That being said, in my startup (Intelliden), we ran up against
exactly the problem that Jason is mentioning. Autonomics is
**scary**. People don't want to trust **software**, they think of the
HAL-9000 scenario. That's why I've always tried to build in the
ability to let the operator choose what gets throttled and what
gets shown.

Basically, autonomics MUST (in the IETF sense) start out as a
**partnership** between software and operator. The role of
autonomics should be to make the job of the operator easier.
So if the operator wants to see everything, fine, but at least
present it in a readable and usable way.
</jcs>

>>JMC>> As we start to add AN services onto these nodes, then issues with
the ACP can become issues that are business/service impacting.  In these
cases it is important for the operator to be able to see the messages to
know if the issue is with the service, the hardware, or the ACP.

<jcs>
Agreed. But the real issue is more serious - the business is
currently disconnected from the infrastructure. There is no
"enable gold sla" command in any CLI or YANG or foobar
script I've seen. So, while communications is of course
important, there are bigger fish to fry.
</jcs>

...

>>JMC>>  I think that I agree here, but want to be sure that I understand
properly.  You are stating that the ACP is simply the control plane that
builds a foundation.  The functions that are then installed onto a device
will have the ability to use that foundation per a defined set of
interactions, such as an API or otherwise.  The functions may work alone or
they may work together to support the services that they were created to
do.  In this way AN provides a  methodology and connectivity model for the
AN Functions to communicate with the ACP and possibly with each other.  The
ACP does not worry about the AN Functions other than the defined
communication in and out.  Much like the layers in the OSI model work
together, but ultimately do not care what is happening inside of each
layer, but focused on communication between layers.

<jcs>
Yes, with one small point

On Sun, Oct 18, 2015 at 8:12 PM, Jason Coleman (colemaj) <[email-masked]>
wrote:

> Cc: "[email-masked]", "Michael Behringer (mbehring)"
> >>JMC>> I think that we need to leave the option up to the operator.
> Today there are many messages that go to the operator, but they are left to
> the operator to determine if they are important or not.  Sometimes,
> operators will simply store the messages for review at a later time or in a
>  problem management situation to look back and see if there is a pattern in
> the messaging that indicates a chronic type of issue.
>
> >>JMC>> As we start to add AN services onto these nodes, then issues with
> the ACP can become issues that are business/service impacting.  In these
> cases it is important for the operator to be able to see the messages to
> know if the issue is with the service, the hardware, or the ACP.
>
> ...
>
> >>JMC>>  I think that I agree here, but want to be sure that I understand
> properly.  You are stating that the ACP is simply the control plane that
> builds a foundation.  The functions that are then installed onto a device
> will have the ability to use that foundation per a defined set of
> interactions, such as an API or otherwise.  The functions may work alone or
> they may work together to support the services that they were created to
> do.  In this way AN provides a  methodology and connectivity model for the
> AN Functions to communicate with the ACP and possibly with each other.  The
> ACP does not worry about the AN Functions other than the defined
> communication in and out.  Much like the layers in the OSI model work
> together, but ultimately do not care what is happening inside of each
> layer, but focused on communication between layers.
>

<jcs>
Yes. If we start demanding that the communications layer does
other things outside of communication, that spreads complexity
throughout the foundation, which is a Bad Idea.
</jcs>

-- 
regards,
John