Re: [Anima] Self-Managed Networks

[Duzongpeng <[e-mail]>]

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:[e-mail]] On Behalf Of Laurent Ciavaglia
Sent: Friday, October 16, 2015 6:53 PM
To: Michael Behringer (mbehring); Brian E Carpenter; Toy, Mehmet; [e-mail]
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).

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.

On 16/10/2015 10:44, Michael Behringer (mbehring) wrote:

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



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

From: Brian E Carpenter [mailto:[e-mail]]

Sent: 16 October 2015 08:02

To: Toy, Mehmet <[e-mail]><mailto:[e-mail]>; Michael Behringer

(mbehring) <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Subject: Re: Self-Managed Networks



On 16/10/2015 16:36, Toy, Mehmet wrote:

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?



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





Thanks

Mehmet



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

From: Michael Behringer (mbehring) [mailto:[e-mail]]

Sent: Thursday, October 15, 2015 4:57 AM

To: Toy, Mehmet; Brian E Carpenter; [e-mail]<mailto:[e-mail]>

Subject: RE: Self-Managed Networks



Toy, thanks for raising those questions. Obviously, we're not doing a good

job yet in describing what the ACP is, and that needs to be fixed. And

obviously, we all need the same view to progress further. So this is a very

important discussion, and I really welcome it.



Before formalising better text, let me see whether we get agreement on

the fundamental idea.



In my head, there are two layers: The ACP, and on top of that the

Autonomic Functions:



* The ACP is the "tool kit". It comprises various "mechanics", such as

negotiation, synchronisation, discovery of various sorts, messaging, etc.

Those are all based on a common addressing and naming concept.



* Autonomic Functions use that tool kit to do something clever. In other

words, the true autonomic "intelligence" sits on that level.



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



One way to decide to which layer something belongs is to ask: "is this (1) a

generic functionality which many functions require, or is this (2) one specific

function?". If the answer is (1), it belongs into the ACP, if (2) it belongs into

an autonomic function.



So, in this light, my understanding (!) of fault management is that

this is an autonomic function, and would use common blocks of the

underlying ACP. Conversely, it would not offer services to other

autonomic functions on top. This is my way of thinking when I write

"this is an autonomic function".  And I'm not 100% certain I

understand what you're suggesting, so please chime in here! (And I

haven't read your draft fully yet, sorry)



Look at

http://tools.ietf.org/id/draft-jiang-anima-prefix-management-01.txt

This draft describes "intelligence". In that case, a way to automatically

manage address space. Sections 2.2 and 2.3 explain which parameters and

information exchanges such a function would require. Sheng wrote this

document to explain how an autonomic function would use a common ACP.



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

small team?



Michael





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

From: Anima [mailto:[e-mail]] On Behalf Of Toy,

Mehmet

Sent: 15 October 2015 04:26

To: Brian E Carpenter <[e-mail]><mailto:[e-mail]>; Michael

Behringer

(mbehring) <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Subject: Re: [Anima] Self-Managed Networks



Michael and Brian,

Per Toerless suggestion, I am including ANIMA group into the discussion.



I re-read the "A Reference Model for Autonomic Networking" document

and I am not clear about the definitions.



a)  In the "A Reference Model for Autonomic Networking", ACP is

defined as "The Autonomic Control Plane is the summary of all

interactions of the Autonomic Networking Infrastructure with other

nodes and services.".



b) Brian, you write as " The ACP is common infrastructure for all

autonomic functions.(The ACP needs to be self-repairing, of course.)

The signaling protocol is also common infrastructure."



Question: What is ACP? a or b or combination?



c) Section 4 in the reference model document , "The Autonomic

Networking Infrastructure provides a layer of common  functionality

across an Autonomic Network.  It comprises "must implement" functions

and services, as well as extensions."

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

define "must implement" functionalities?



Thanks

Mehmet

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

From: Brian E Carpenter [mailto:[e-mail]]

Sent: Wednesday, October 14, 2015 5:25 PM

To: Michael Behringer (mbehring); Toy, Mehmet

Cc: '[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'; 'anima-

[e-mail]<mailto:[e-mail]>'

Subject: Re: Self-Managed Networks



I agree with Michael. The ACP is common infrastructure for all

autonomic functions.

(The ACP needs to be self-repairing, of course.) The signaling

protocol is also common infrastructure.



   Brian

On 15/10/2015 05:43, Michael Behringer (mbehring) wrote:

I would argue they are part of an autonomic function, which runs on

top of

the ACP.

There are really two different pieces here, and this is I think the

confusion

here:



-          The ACP is self-managing. It needs to do self-healing, and

automatically adapt to new situations. But to me, this isn’t fault

management or performance management as an operator understands

it.



-          The network has FM and PM function. Those could be (and should

be, imo) autonomic functions. Those run on top of the ACP.

Bottom line: I’d like to keep the ACP itself as minimalistic and

simple as we

possibly can. Functions like FM / PM belong into an autonomic function,

IMO.

What do you think?

Michael

From: Toy, Mehmet [mailto:[e-mail]]

Sent: 14 October 2015 18:30

To: Michael Behringer (mbehring) <[e-mail]><mailto:[e-mail]>

Cc: '[e-mail]<mailto:[e-mail]>' <[e-mail]><mailto:[e-mail]>;

'[e-mail]<mailto:[e-mail]>'

<[e-mail]><mailto:[e-mail]>; '[e-mail]<mailto:[e-mail]>'

<[e-mail]><mailto:[e-mail]>; '[e-mail]<mailto:[e-mail]>'

<[e-mail]><mailto:[e-mail]>

Subject: RE: Self-Managed Networks



Michael,

Instead of answering the question as Yes or No, let me give examples

to

see what makes sense.

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

generates an AIS

(Alarm Indication Signal) and the receiving  end generates RDI

(remote Defect Indicator).  Both messages are generated by the

hardware, not by a

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

The

hardware counts these losses, an ACP does not.

For the FM and PM functions above, can we say they are part of an ACP?

Thanks

Mehmet

From: Michael Behringer (mbehring) [mailto:[e-mail]]

Sent: Wednesday, October 14, 2015 11:34 AM

To: Toy, Mehmet

Cc: '[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'; 'anima-

[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'

Subject: RE: Self-Managed Networks



Hi Toy,

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

of

the AN infrastructure. It uses the ACP to communicate, maybe GRASP

for some signalling, might be influenced by Intent, etc. Right?  So

to me, this is a logical component of an autonomic network that sits

on top of the AN infrastructure.

Do we agree?

Michael



From: Toy, Mehmet [mailto:[e-mail]]

Sent: 13 October 2015 23:46

To: Michael Behringer (mbehring)

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>

Cc: '[e-mail]<mailto:[e-mail]>'

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>;

'[e-mail]<mailto:[e-mail]>'

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>;

'[e-mail]<mailto:[e-mail]>'

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>;

'[e-mail]<mailto:[e-mail]>'

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>

Subject: RE: Self-Managed Networks



Michael,

Appreciate the reply.

FM is part of data plane and control plane (i.e. ANI in your diagram).

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

expand

the description  of ANI or to section 4 to add a sub-section for

Fault Management.



It is also possible too add a Performance Management section to

describe

what types of measurements and where and how are used.  Although

there is a control feedback related measurement in the document, I

don’t know if it is adequate.



Regards,

Mehmet

From: Michael Behringer (mbehring) [mailto:[e-mail]]

Sent: Tuesday, October 13, 2015 12:27 PM

To: Toy, Mehmet

Cc: '[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'; 'anima-

[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'

Subject: RE: Self-Managed Networks



Sorry for the delay, it’s very busy at the moment here.

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

plane, ie for

user traffic. I see that happening at some point as an autonomic

function (or several, for different aspects). Would you agree? Or do

you see that as a function inside the AN infrastructure?

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

infrastructure that

we’re currently defining. So, please have a look whether your

thoughts can be described as an autonomic function. I think they probably

can.

Then I suggest we do the same that we’re planning to do with the NMS

section, the model discussion, etc: Have a short paragraph describe

the overall topic briefly, and point to an external doc for now,

i.e., probably your draft.

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

add

a short paragraph about fault management, and I suppose we’d point to

your draft, right?

Michael





From: Toy, Mehmet [mailto:[e-mail]]

Sent: 13 October 2015 03:53

To: Michael Behringer (mbehring)

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>

Cc: '[e-mail]<mailto:[e-mail]>'

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>;

'[e-mail]<mailto:[e-mail]>'

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>;

'[e-mail]<mailto:[e-mail]>'

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>;

'[e-mail]<mailto:[e-mail]>'

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>

Subject: RE: Self-Managed Networks



Mike,

I am waiting for your response.

Thanks

Mehmet



From: Toy, Mehmet

Sent: Friday, October 09, 2015 8:13 PM

To: '[e-mail]<mailto:[e-mail]>'

Cc: '[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'; 'anima-

[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'

Subject: RE: Self-Managed Networks



Mike,

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

Reference

Model for Autonomic Networking,   draft-behringer-anima-reference-

model-03”,  per Sheng’s suggestion.

Should I just do that?

Thanks

Mehmet





From: Toy, Mehmet

Sent: Thursday, October 08, 2015 7:53 AM

To: '[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>';

'[e-mail]<mailto:[e-mail]>'; '[e-mail]<mailto:[e-mail]>'

Cc: '[e-mail]<mailto:[e-mail]>'

Subject: Re: Self-Managed Networks



Sheng,

Appreciate a quick response.

I will work on your suggestion.

Mehmet





From: Sheng Jiang [mailto:[e-mail]]

Sent: Thursday, October 08, 2015 06:08 AM Eastern Standard Time

To: Toy, Mehmet;

[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>;

[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>;

[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>

Cc: Romascanu, Dan (Dan)

([e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>)

<[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>>

Subject: RE: Self-Managed Networks



Hi, Toy,

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

WG

charter. However, we do not have work item or milestone for it. It

looks like an upper-layer autonomic service agent for me. In our

plan, autonomic service agents are mainly for the next period, which

is after re-charter (this is the same with your suggestion of

modifying the charter, but it cannot happen until we deliver the

current milestones). For now, the best may be try to add some

description, maybe mainly abstracted functionality, into the reference

model document.

Best regards,

Sheng



From: Toy, Mehmet [mailto:[e-mail]]

Sent: Tuesday, October 06, 2015 1:14 AM

To: [e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>;

[e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>

Cc: Romascanu, Dan (Dan)

([e-mail]<mailto:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>)

Subject: Self-Managed Networks



Dear All:

I couldn’t attend the Prague meeting, but luckily Dan was able to

present

my slides on “Self-Managed Networks with Fault Management

Hierarchy”.

The feedback was to position the work in the ANIMA WG scope and

framework.



ANIMA charter in “M. Behringer, et. al., A Reference Model for

Autonomic

Networking

draft-behringer-anima-reference-model-03” refers to “self-healing”.

RFC7575,  “M. Behringer, et al.,   Autonomic Networking: Definitions and

Design Goals”,  refers to “self-management”. However, both documents

do not  articulate fault management aspect of the self-management.

It is possible to interpret the fault management aspect of autonomic

networks as part of “self-healing” and therefore as part of the ANIMA

charter.  In that case, the “Architectural Framework for Self-Managed

Networks with Fault Management Hierarchy,

draft-mtoy-anima-self-faultmang-framework-

00.txt” contribution can target to fill that gap.  The control plane

aspect of self-healing is addressed by “M. Behringer, et al., An

Autonomic Control Plane,

draft-behringer-anima-autonomic-control-plane-03”.  I believe these

contributions are complementary to each other. I can try to address that

in the contribution.



Please let me know if you agree with me. If not, I suggest to modify

the

charter since without covering fault management aspect of the

autonomic networks, the concept of autonomic network will be

incomplete.



Regards,

Mehmet









_______________________________________________

Anima mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/anima



_______________________________________________

Anima mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/anima

--

Bien cordialement, Best regards,

Laurent Ciavaglia
Secure Cloud Networking
Bell Labs | Alcatel Lucent

phone: [phone]
email: [e-mail]<mailto:[e-mail]>
linkedin: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 Nozay | France