Re: [Anima] Self-Managed Networks
"Michael Behringer (mbehring)" <mbehring@cisco.com> Fri, 16 October 2015 08:44 UTC
Return-Path: <mbehring@cisco.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895A91B30BB for <anima@ietfa.amsl.com>; Fri, 16 Oct 2015 01:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjzkFp8dwOig for <anima@ietfa.amsl.com>; Fri, 16 Oct 2015 01:44:35 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFB51B305E for <anima@ietf.org>; Fri, 16 Oct 2015 01:44:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24694; q=dns/txt; s=iport; t=1444985075; x=1446194675; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2bJYhZjHSTL+I8E62wgEW65fWE0NfywRng2nOzVkT3c=; b=EM9yqM3JbkywM8XbFAIk0RojVFITcU8toxQ7LAmPLtWPmudArqh0LJRY CX6+5Av1rt8wrAL2zdp9vcQWj6SLgc6YQSka3UyEz0jGxeZPc3pPcLOn2 /AVoJuA/xax4G/41YRUBjcE8EJS7eb/vXaVhLtU/jl2dGzFrQ7wlEf8Ul g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AnAgBpuCBW/4wNJK1dgyZUbga9YQENgVkXCoIzEIM6AhyBFzgUAQEBAQEBAYEKhCYBAQEEAQEBIBE6FwQCAQgRBAEBAQICIwMCAgIfBgsUAQgIAgQBEgiIEQMSDbAIjhkNhREBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKFVIN4gQaBT4EBghIQIgICAoJjgUUFhzqHBYdeAYUYhg6BbYFfSINygySLEYNag24BHwEBQoQDcQGEHSQfgQYBAQE
X-IronPort-AV: E=Sophos;i="5.17,688,1437436800"; d="scan'208";a="41991205"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2015 08:44:33 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t9G8iWKi023747 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2015 08:44:32 GMT
Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 16 Oct 2015 03:44:17 -0500
Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Fri, 16 Oct 2015 03:44:17 -0500
From: "Michael Behringer (mbehring)" <mbehring@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Toy, Mehmet" <Mehmet_Toy@cable.comcast.com>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: Self-Managed Networks
Thread-Index: AdD/kRO6wwWTW9ATTCGfmWDsg6vmTgCHv4OwAAPvjp8AS70lMACaxAYgAB4NjsAAAQB6wAAvzJMAAAG8O7AAALH+8AAUcfOAAAqCjoAAApCmQAAyKgSAAAUYTAAABPI0cA==
Date: Fri, 16 Oct 2015 08:44:17 +0000
Message-ID: <fcc70f9268c746c786f49a7dd547cb7a@XCH-RCD-006.cisco.com>
References: <5D36713D8A4E7348A7E10DF7437A4B927BBB558B@nkgeml512-mbx.china.huawei.com> <7145ab65268b4fb3b279e2ce9da1fdaa@VAADCEX36.cable.comcast.com> <cbc6f29eda114b848f3dac35609b2da8@VAADCEX36.cable.comcast.com> <9c8b64c962c443f19f6fd784cb9927a7@VAADCEX36.cable.comcast.com> <7512f6b600904c49838fcf729e3000a5@XCH-RCD-006.cisco.com> <334e22acb30e487eb7f5a2d41fb54499@VAADCEX36.cable.comcast.com> <ff7789800a574fcb901e096a0a11f5bb@XCH-RCD-006.cisco.com> <dd5a46abd24c49d2a9acd31a608ef7e8@VAADCEX37.cable.comcast.com> <14fdc79570b54d0e9562382c5d53a3ef@XCH-RCD-006.cisco.com> <561EC845.9020505@gmail.com> <c1e45907707f42d3ae1e9beb0647a760@VAADCEX37.cable.comcast.com> <03347fe65bce48e9ba28827f5c4c0624@XCH-RCD-006.cisco.com> <c44ededa670e43588987bd30b2f68e88@VAADCEX37.cable.comcast.com> <562092DA.3070800@gmail.com>
In-Reply-To: <562092DA.3070800@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.238.132]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/Ie4nqa6rSeaf-pqUDgHF0_-iS7A>
Subject: Re: [Anima] Self-Managed Networks
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 08:44:38 -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 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: 16 October 2015 08:02 > To: Toy, Mehmet <Mehmet_Toy@cable.comcast.com>; Michael Behringer > (mbehring) <mbehring@cisco.com>; anima@ietf.org > 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:mbehring@cisco.com] > > Sent: Thursday, October 15, 2015 4:57 AM > > To: Toy, Mehmet; Brian E Carpenter; anima@ietf.org > > 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:anima-bounces@ietf.org] On Behalf Of Toy, > Mehmet > >> Sent: 15 October 2015 04:26 > >> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; Michael > >> Behringer > >> (mbehring) <mbehring@cisco.com>; anima@ietf.org > >> 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:brian.e.carpenter@gmail.com] > >> Sent: Wednesday, October 14, 2015 5:25 PM > >> To: Michael Behringer (mbehring); Toy, Mehmet > >> Cc: 'dromasca@avaya.com'; 'jiangsheng@huawei.com'; 'anima- > >> chairs@tools.ietf.org' > >> 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:Mehmet_Toy@cable.comcast.com] > >>> Sent: 14 October 2015 18:30 > >>> To: Michael Behringer (mbehring) <mbehring@cisco.com> > >>> Cc: 'dromasca@avaya.com' <dromasca@avaya.com>; > >> 'jiangsheng@huawei.com' > >>> <jiangsheng@huawei.com>; 'anima-chairs@tools.ietf.org' > >>> <anima-chairs@tools.ietf.org>; 'brian.e.carpenter@gmail.com' > >>> <brian.e.carpenter@gmail.com> > >>> 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:mbehring@cisco.com] > >>> Sent: Wednesday, October 14, 2015 11:34 AM > >>> To: Toy, Mehmet > >>> Cc: 'dromasca@avaya.com'; 'jiangsheng@huawei.com'; 'anima- > >> chairs@tools.ietf.org'; 'brian.e.carpenter@gmail.com' > >>> 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:Mehmet_Toy@cable.comcast.com] > >>> Sent: 13 October 2015 23:46 > >>> To: Michael Behringer (mbehring) > >>> <mbehring@cisco.com<mailto:mbehring@cisco.com>> > >>> Cc: 'dromasca@avaya.com' > >>> <dromasca@avaya.com<mailto:dromasca@avaya.com>>; > >>> 'jiangsheng@huawei.com' > >>> <jiangsheng@huawei.com<mailto:jiangsheng@huawei.com>>; > >>> 'anima-chairs@tools.ietf.org' > >>> <anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org>>; > >>> 'brian.e.carpenter@gmail.com' > >>> <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> > >>> 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:mbehring@cisco.com] > >>> Sent: Tuesday, October 13, 2015 12:27 PM > >>> To: Toy, Mehmet > >>> Cc: 'dromasca@avaya.com'; 'jiangsheng@huawei.com'; 'anima- > >> chairs@tools.ietf.org'; 'brian.e.carpenter@gmail.com' > >>> 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:Mehmet_Toy@cable.comcast.com] > >>> Sent: 13 October 2015 03:53 > >>> To: Michael Behringer (mbehring) > >>> <mbehring@cisco.com<mailto:mbehring@cisco.com>> > >>> Cc: 'dromasca@avaya.com' > >>> <dromasca@avaya.com<mailto:dromasca@avaya.com>>; > >>> 'jiangsheng@huawei.com' > >>> <jiangsheng@huawei.com<mailto:jiangsheng@huawei.com>>; > >>> 'anima-chairs@tools.ietf.org' > >>> <anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org>>; > >>> 'brian.e.carpenter@gmail.com' > >>> <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> > >>> 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: 'mbehring@cisco.com' > >>> Cc: 'dromasca@avaya.com'; 'jiangsheng@huawei.com'; 'anima- > >> chairs@tools.ietf.org'; 'brian.e.carpenter@gmail.com' > >>> 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: 'jiangsheng@huawei.com'; 'anima-chairs@tools.ietf.org'; > >> 'brian.e.carpenter@gmail.com'; 'mbehring@cisco.com' > >>> Cc: 'dromasca@avaya.com' > >>> Subject: Re: Self-Managed Networks > >>> > >>> Sheng, > >>> Appreciate a quick response. > >>> I will work on your suggestion. > >>> Mehmet > >>> > >>> > >>> From: Sheng Jiang [mailto:jiangsheng@huawei.com] > >>> Sent: Thursday, October 08, 2015 06:08 AM Eastern Standard Time > >>> To: Toy, Mehmet; > >>> anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org> > >>> <anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org>>; > >>> brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com> > >>> <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>; > >>> mbehring@cisco.com<mailto:mbehring@cisco.com> > >>> <mbehring@cisco.com<mailto:mbehring@cisco.com>> > >>> Cc: Romascanu, Dan (Dan) > >>> (dromasca@avaya.com<mailto:dromasca@avaya.com>) > >>> <dromasca@avaya.com<mailto:dromasca@avaya.com>> > >>> 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:Mehmet_Toy@cable.comcast.com] > >>> Sent: Tuesday, October 06, 2015 1:14 AM > >>> To: anima-chairs@tools.ietf.org<mailto:anima-chairs@tools.ietf.org>; > >>> brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>; > >>> mbehring@cisco.com<mailto:mbehring@cisco.com> > >>> Cc: Romascanu, Dan (Dan) > >>> (dromasca@avaya.com<mailto:dromasca@avaya.com>) > >>> 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 > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Michael Behringer (mbehring)
- Re: [Anima] Self-Managed Networks Reddy Pallavali
- Re: [Anima] Self-Managed Networks Michael Behringer (mbehring)
- Re: [Anima] Self-Managed Networks Reddy Pallavali
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Toerless Eckert (eckert)
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Michael Behringer (mbehring)
- Re: [Anima] Self-Managed Networks Laurent Ciavaglia
- Re: [Anima] Self-Managed Networks Laurent Ciavaglia
- Re: [Anima] Self-Managed Networks Duzongpeng
- Re: [Anima] Self-Managed Networks Reddy Pallavali
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Michael Behringer (mbehring)
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks John Strassner
- Re: [Anima] Self-Managed Networks John Strassner
- Re: [Anima] [ANIMA] Self-Managed Networks John Strassner
- Re: [Anima] Self-Managed Networks Toerless Eckert (eckert)
- Re: [Anima] Self-Managed Networks Joel M. Halpern
- Re: [Anima] Self-Managed Networks John Strassner
- Re: [Anima] Self-Managed Networks Michael Behringer (mbehring)
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Behringer (mbehring)
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Toy, Mehmet
- Re: [Anima] Self-Managed Networks Reddy Pallavali
- Re: [Anima] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks Joel M. Halpern
- Re: [Anima] Self-Managed Networks John Strassner
- Re: [Anima] Self-Managed Networks John Strassner
- Re: [Anima] Self-Managed Networks John Strassner
- Re: [Anima] Self-Managed Networks Jason Coleman (colemaj)
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Richardson
- Re: [Anima] [ANIMA] Self-Managed Networks Reddy Pallavali
- Re: [Anima] [ANIMA] Self-Managed Networks Joel M. Halpern
- Re: [Anima] [ANIMA] Self-Managed Networks Brian E Carpenter
- Re: [Anima] [ANIMA] Self-Managed Networks Brian E Carpenter
- Re: [Anima] [ANIMA] Self-Managed Networks Joel M. Halpern
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Richardson
- Re: [Anima] [ANIMA] Self-Managed Networks Brian E Carpenter
- Re: [Anima] Self-Managed Networks John Strassner
- Re: [Anima] [ANIMA] Self-Managed Networks John Strassner
- Re: [Anima] [ANIMA] Self-Managed Networks Duzongpeng
- Re: [Anima] [ANIMA] Self-Managed Networks John Strassner
- Re: [Anima] [ANIMA] Self-Managed Networks Toerless Eckert
- Re: [Anima] [ANIMA] Self-Managed Networks Toerless Eckert
- Re: [Anima] [ANIMA] Self-Managed Networks Joel M. Halpern
- Re: [Anima] [ANIMA] Self-Managed Networks Jason Coleman (colemaj)
- Re: [Anima] [ANIMA] Self-Managed Networks Brian E Carpenter
- Re: [Anima] [ANIMA] Self-Managed Networks Brian E Carpenter
- Re: [Anima] [ANIMA] Self-Managed Networks Jason Coleman (colemaj)
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Richardson
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Richardson
- Re: [Anima] [ANIMA] Self-Managed Networks Brian E Carpenter
- Re: [Anima] [ANIMA] Self-Managed Networks Joel M. Halpern
- Re: [Anima] [ANIMA] Self-Managed Networks John Strassner
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Behringer (mbehring)
- Re: [Anima] [ANIMA] Self-Managed Networks Joel M. Halpern
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Behringer (mbehring)
- Re: [Anima] [ANIMA] Self-Managed Networks John Strassner
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Richardson
- Re: [Anima] [ANIMA] Self-Managed Networks Laurent Ciavaglia
- Re: [Anima] [ANIMA] Self-Managed Networks John Strassner
- Re: [Anima] [ANIMA] Self-Managed Networks Laurent Ciavaglia
- Re: [Anima] [ANIMA] Self-Managed Networks Michael Richardson
- Re: [Anima] [ANIMA] Self-Managed Networks PELOSO, PIERRE (PIERRE)
- Re: [Anima] [ANIMA] Self-Managed Networks Brian E Carpenter