Re: [Anima] Self-Managed Networks
John Strassner <strazpdj@gmail.com> Sun, 18 October 2015 02:07 UTC
Return-Path: <strazpdj@gmail.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 D450E1A871E for <anima@ietfa.amsl.com>; Sat, 17 Oct 2015 19:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 W_X0nR1Cf3M1 for <anima@ietfa.amsl.com>; Sat, 17 Oct 2015 19:07:33 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E231A871B for <anima@ietf.org>; Sat, 17 Oct 2015 19:07:32 -0700 (PDT)
Received: by vkat63 with SMTP id t63so87730771vka.1 for <anima@ietf.org>; Sat, 17 Oct 2015 19:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B7/MpBPz8VicdZcjnNoyuoYJJd5YcAbgWb32pCD2Z8w=; b=hJMDZbkPOUbOuM4u4l6gXe7XHmey2V+vlHnjhcHi5u2uu6G9Bd6HWwGQk4esFmQFUB 3vWqvw2joeDbuyNQkYgGEQs8kBLlIzhikMJ66YMSOva1pjr6gmHKWb0epv3Wr+LNG+WJ n2yoBA7QMYw1gKrZDee8D63BtoIbZqgbhNyCp5Jx6tCw6th9SykeR7QRdfyDKltD7a8u kQn+XzpKMIXpFAfC20IJEzFXr/7AnP828BALNjQPYTjycb5/zkSQLFDZPNVttD1w1/5N fU/cWdihtefkTCs5VlOuLfri7NtOlmOZ8v9oMZ1GRB1GSitGUFHilp9uohDJAgFh868f Sgjw==
MIME-Version: 1.0
X-Received: by 10.31.178.136 with SMTP id b130mr15377965vkf.109.1445134051902; Sat, 17 Oct 2015 19:07:31 -0700 (PDT)
Received: by 10.103.32.199 with HTTP; Sat, 17 Oct 2015 19:07:31 -0700 (PDT)
In-Reply-To: <c44ededa670e43588987bd30b2f68e88@VAADCEX37.cable.comcast.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>
Date: Sat, 17 Oct 2015 19:07:31 -0700
Message-ID: <CAJwYUrH+DswOjmNrDUVQHDh6nUtcuO0bPPGK-OKFzxj6XPBWTA@mail.gmail.com>
From: John Strassner <strazpdj@gmail.com>
To: "Toy, Mehmet" <Mehmet_Toy@cable.comcast.com>, John Strassner <strazpdj@gmail.com>
Content-Type: multipart/alternative; boundary="001a1143e074d10f020522577d98"
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima/1TbWL3gZ7ov9rTtAmrjCkSuWRmo>
Cc: "anima@ietf.org" <anima@ietf.org>, "Michael Behringer (mbehring)" <mbehring@cisco.com>
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: Sun, 18 Oct 2015 02:07:39 -0000
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. > Furthermore, I suggest you to think about ETSI NFV model, > "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 <Mehmet_Toy@cable.comcast.com> 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? 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: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 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John
- 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